코드 리뷰를 할 때는 어떤 것들을 중점적으로 봐야 할까요? 시니어 스태프 엔지니어 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