# (번역) 코드 리뷰 피라미드
해당 글은 Gunnar Morling (opens new window)의 The Code Review Pyramid (opens new window)를 번역한 글입니다.
코드 리뷰 하다 보면 코드 포맷이나 스타일 등과 같은 측면을 더 집중하고 더 오랫동안 논의를 하는 경우가 태반입니다. 오히려 정말 중요한, 코드 변경이 본래의 기능을 잘 수행하는지, 잘 실행되는지, 그리고 기존 클라이언트와 역호환성은 잘 지켜지고 있는 지 등은 제대로 주의를 기울이지 못하곤 합니다.
이러한 문제에 대한 인식을 높이고자, 코드 리뷰에서 정말 집중해야 할 것들에 대해 정리한 "코드 리뷰 피라미드"를 트위터 (opens new window)에 올렸습니다. 코드 리뷰에서 (제가 생각하기에) 가장 중요한 부분과, 자동화 가능한 (그리고 꼭 되어야 할) 부분들에 대해 초점을 맞추는데 도움이 되고자 합니다.
계속 볼 수 있고, 인용 가능한 곳, 그리고 고해상도 인쇄 가능한 리소스를 원하시는 분들이 있어서 블로그 (opens new window)에 다시 올려봅니다.
(SVG 파일 (opens new window)로도 다운받을 수 있습니다.)
(위로 갈수록 나중에 고쳐도 쉬운 것 아래로 갈수록 나중에 고치기 어려운 것들입니다. 위 2단계는 자동화하는 것이 좋고, 아래 3단계를 코드 리뷰에서 중점적으로 다루도록 합니다.)
# Code Style (코드 스타일)
- 이 프로젝트에는 포매팅 스타일이 적용되었나요?
- 네이밍 컨벤션은 잘 지켜졌나요?
- 중복은 없나요? DRY(Don't Repeat Yourself) 했나요?
- 코드는 충분히 가독성 있게 썼나요?
# Test (테스트)
- 모든 테스트가 통과했나요?
- 새로 추가된 기능들이 모두 적절하게 테스트 되었나요?
- 코너 케이스(여러 환경과 변수로 인한 복합적인 원인으로 발생하는 문제)도 테스트 되었나요?
- (가능한 한) 유닛 테스트와 (필요한 경우에 대한) 통합 테스트가 되었나요?
- 비기능 요건(NFR, Non-functional requirement)에 대한 테스트도 되었나요?(예. 성능)
# Documentation (문서화)
- 새로 추가된 기능들이 적절히 문서화되었나요?
- 관련 문서 모두 확인되었나요? README, API 문서, 유저 가이드, 레퍼런스 문서 등
- 문서는 모두 이해하기 쉽고, 중요한 오타나 문법 오류는 없나요?
# Implementation Semantics (구현)
- 요구사항을 모두 만족하고 있나요?
- 모든 로직이 올바른 가요?
- 불필요하게 복잡하진 않나요?
- 문제 될 수 있는 상황들에 대해 꼼꼼히 고려했나요? (예. 동시성 이슈나, 에러 핸들링 등)
- 성능이 좋은가요?
- 안전하게 짜였나요? (예. SQL 인섹젼 등)
- 모니터링할 수 있나요? (예. metrics, logging, tracing 등)
- 새로 추가된 의존성이 그들의 역할을 제대로 하고 있나요? 라이센스 문제는 없나요?
# API Semantics (API)
- API는 적절한 크기로 구현되었나요? 필요한 만큼 잘 구현되었나요?
- 일관성을 잘 지키고 있나요? 너무 크게 변경되지는 않았나요?
- API와 내부 로직이 깔끔하게 나누어져 있나요?
- API 사용 부분에서 하위 호환되지 않는 변경점은 없나요? (예. API classes, 설정, metrics, 로그 포맷 등)
- 새로운 API가 전반적으로 사용 가능한가요? 혹시 너무 특정 사용만 가능하진 않나요?