👀 코드 리뷰 시 중점적으로 봐야 할 다섯 가지

코드 리뷰를 할 때는 어떤 것들을 중점적으로 봐야 할까요? 시니어 스태프 엔지니어 Gunnar Morling은 코드 리뷰에서 중점적으로 봐야 할 항목을 다섯 가지로 나눠 코드 리뷰 피라미드를 만들었습니다. 피라미드의 위에 추후에 쉽게 변경 가능한 항목, 밑에 있을수록 변경이 어려운 항목으로 구분했어요. 그렇기 때문에 위에 있는 항목은 가능하면 툴을 이용한 자동화를 하고, 밑에 있는 항목을 더 중점적으로 리뷰할 것을 권합니다. 아래는 코드 리뷰 피라미드의 다섯 항목과 각각의 항목을 리뷰할 때 물어봐야 할 질문입니다. 1️⃣ 코드 스타일 - 프로젝트의 코드 스타일 포맷팅이 적용 되었는가? - 네이밍 규칙을 만족하는가? - DRY(Don't Repeat Yourself) 원칙을 잘 지켰는가? - 충분히 읽기 쉬운 코드인가? (함수 길이 등) 2️⃣ 테스트 - 모든 테스트가 통과되었는가? - 새로운 기능들은 적절하게 테스트되었는가? - 엣지 케이스도 테스트되었는가? - 적절한 경우에 유닛 테스트와 통합 테스트를 사용했는가? - 비기능적 요구사항에 대한 테스트가 있는가? (성능 관련 테스트 등) 3️⃣ 문서화 - 새로운 기능들은 적절하게 문서화되었나? - 필요한 문서가 추가되었는가? (README, API 문서, 사용자 가이드, 참조 문서 등) - 문서는 이해하기 쉽게 쓰였는가? 눈에 띄는 오류는 없는가? 4️⃣ 기능 구현 스타일 및 정확도 - 원래의 요구사항을 만족하는가? - 논리적으로 정확한가? - 불필요한 복잡도는 없는가? - 시스템은 안정적인가? (동시성 문제, 적절한 오류 처리 등) - 보안적인 측면에서 안전한가? (SQL 인젝션 등) - 모니터링은 적절히 추가되었는가? (모니터링 메트릭, 로깅, 트레이싱 등) - 새로 추가된 라이브러리는 적절한 역할을 하고 있는가? 라이선스는 적절한가? 5️⃣ API 구현 스타일 및 정확도 - API는 가능한 작게, 그러나 필요한 만큼 크게 설계되었는가? - API가 한 가지 일만 수행하는가? - 일관성이 있으며 사이드 이펙트는 최소화 되었는가? - API와 내부 구현이 깔끔하게 구분되었는가? - 사용자에게 노출되는 부분에 오류를 일으킬 만한 변경 사항은 없는가? (API 클래스, 컨피그 설정, 메트릭, 로그 형식 등) - 새로운 API가 보편적으로 유용한가? 과도하게 특정 목적으로만 쓰이진 않았는가? 출처: https://www.morling.dev/blog/the-code-review-pyramid 📔 함께 읽어보면 좋은 글 코드 리뷰에서 흔히 보이는 세 가지 실수: https://careerly.co.kr/comments/86864

다음 내용이 궁금하다면?

또는

이미 회원이신가요?

2023년 7월 18일 오후 12:45

 • 

저장 108조회 6,215

댓글 0

    함께 읽은 게시물

    스토리북 9 출시 소식

    ... 더 보기

    Storybook 9

    Storybook Blog

    Storybook 9

    소프트웨어 개발 방법론의 역사

    조회 863


    발이 닿지 않는 바다에서

    ... 더 보기

    발이 닿지 않는 바다에서

    hajoeun.com

    발이 닿지 않는 바다에서

    < 🔔 내가 만나본 빠르게 성장하는 주니어 개발자들의 특징 > 본론에 앞서 이 글은 그동안 제가 만나본 성장이 빠르다고 느낀 주니어 개발자분들의 태도와 습관을 정리해보는 글입니다. 기술이나 학습등을 거론하며 '이런것만 배우면 당신도 빠르게 성장할 수 있습니다!' 류의 글은 아니고 그분들의 이런 태도와 습관이 성장에 영향이 있지 않았을까 정도의 글이라고 생각해주시면 되겠습니다. ✅️ 질문을 잘한다. 빠르게 성장하신 분들의 질문엔 2가지 공통점이 있었다. 1. 질문의 타이밍 대부분의 신입사원이나 주니어 개발자분들은 선배 개발자에게 질문을 하기 부담스러워 한다. 그래서 혼자 몇일을 끙끙거리다가 힘겹게 질문하거나 선배 개발자가 먼저 말을 걸어서 답을 얻는 모습을 많이 본다. 만약 알고싶던 내용이 선배 개발자가 바로 대답해줄 수 있는 것이었다면 오래 끙끙거린만큼 시간을 허비해버린것과 같다. 질문을 잘하는 분들의 경우 자신들의 고민이 자신이 풀수 없는 수준이라는걸 알게 되면 선배 개발자들에게 바로 질문함으로써 그만큼 시간을 아끼고 다음 스텝으로 나아간다. 2. 질문의 깊이 질문할 때 '이게 뭐에요?' 나 'A 부터 Z 까지 알려주세요' 등의 질문을 하지 않는다. 자신이 충분히 찾아보고 자신의 선에서 최대한 알아본 뒤에 풀리지 않는 부분을 질문한다. 그렇기에 질문의 깊이가 깊다. 이런 질문을 받았을 때 바로 답을 주는 경우도 있지만 대부분 이런 깊이 있는 질문은 정확한 확인을 위해 다시 한번 관련 내용을 찾아보게 만든다. 이로 인해 질문 받는 사람도 알고 있던 내용을 복습하거나 놓쳤던 부분을 공부하게 되고 이를 통해 같이 성장하는 느낌을 받는다. 그래서 나는 이런식으로 질문 하는 분들이 좋고 나도 다른 사람들한테 이렇게 질문을 하기 위해 노력한다. ✅️ 가만히 있지 않는다. 간혹 내 업무가 많이 밀리고 바쁘다보면 주니어 분들을 신경쓰지 못해 그분들의 업무에 공백이 생길때가 있다. 업무를 잘하시는 주니어 분들은 이런 공백도 허투루 지나가지 않고 아래와 같은 행동들을 한다. 1. 업무 혹은 과제를 달라고 요청한다. 2. 팀에서 진행하는 프로젝트에 이슈가 없는지 찾아본다. 혹은 발견된 이슈의 원인을 파악해보려고 한다. 3. 팀에서 진행하는 프로젝트 코드를 분석한다. 4. 팀에서 사용하는 오픈소스나 프레임워크, 라이브러리 코드를 분석한다. 5. 프... 더 보기

     • 

    댓글 12 • 저장 839 • 조회 34,284



    개발자 교양 팟캐스트

    A

    ... 더 보기