Code review Pyramid에 대한 글 번역
The Code Review Pyramid
코드리뷰에 대해서 이야기할 때 코드 포매팅이나 스타일에 관한 재미없는 논의들이 길고 지루하게 초점을 맞추는 경향이 있는 반면 중요한 측면(코드의 변경이 의도와 맞는지, 성능저하는 없는지, 기존 클라이언트와 호환은 잘 되는지 등)들은 덜 주목을 받는다.
이 이슈에 대한 인지도를 높이고 초점을 맞춰야하는 측면에 대한 가이드를 제공하기 위해서 트위터에 Code Review Pyrimid라고 내가 부르는 하나의 이미지를 올렸다. 이 트윗의 의도는 코드리뷰를 하는 동안 어떤 중요한 부분에 초점을 맞춰야하는지, 어떤 부분이 자동화가 될 수 있고 되어야하는지에 대해서 알려주기 위함이다.
몇몇 분들이 이 자료에 대해서 영구적이고 참조할 수 있는 포스팅과 고화질 사진을 원해서 여기다가 다시 올려둔다 :)
Code Style (코드 스타일)
- 프로젝트의 포매팅 스타일이 적용되었나요?
- 네이밍 컨벤션을 잘 적용했나요?
- DRY(Don’t Repeat Yourself) 한가요? 중복이 없나요?
- 코드가 충분히 읽을만 한가요? (메서드 길이 등…)
Tests (테스트)
- 모든 테스트를 패스했나요?
- 새로은 기능이 합리적으로 테스트되었나요?
- 코너 케이스들도 테스트되었나요?
- 유닛테스트가 가능한 곳이라면 유닛테스트를, 통합테스트가 필요한 곳이라면 통합테스트를 사용하고 있나요?
- NFR(non-functional requirement, 비기능요구사항) 들에 대한 테스트도 있나요? e.g. 성능
Documentation (문서화)
- 새로운 기능이 합리적으로 문서화되어있나요?
- 관련 문서들 (README, API 문서, 사용자 가이드, 참조문서 등)이 잘 업데이트 되었나요?
- 문서들이 이해가 잘 되고 오타나 문법적인 실수는 없나요?
Implemetaion Semantics
- 기존 요구사항을 잘 만족하나요?
- 논리적으로 정확한가요?
- 불필요한 복잡성이 없나요?
- 견고한가요? (동시성 이슈, 적절한 에러 핸들링 등)
- 성능 저하 문제는 없나요?
- 안전한가요? (SQL 인젝션 등)
- 관측 가능한가요? (메트릭, 로그, 추적 등)
- 덩치를 키우는 의존성이 새롭게 추가되진 않았나요? 라이센스는 적절한가요?
API Semantics
- API가 줄일 수 있는 것은 잘 줄이고 필요한 만큼만의 크기로 잘 짜여졌나요?
- 여러가지 일을 수행하는 것이 아니라 한 가지 일만 잘 수행하고 있나요?
- 일관성이 있나요? 최소한의 원칙을 따르고 있나요?
- API 내부에서 구멍 뚫린 곳 없이 깔끔하게 나누어져 있나요?
- 유저가 직접적으로 겪는 변화는 없나요? (API 클래스들, 설정, 메트릭, 로그 포맷 등)
- 새로운 API가 일반적으로 유용하고 오버스펙이진 않나요?
FAQ
- 왜 피라미드인가요? -> 피라미드의 하위 부분은 코드리뷰의 기초가 되어야하고 대부분을 차지해야 하기 떄문
- 에이, 저거 삼각형이잖아요! -> 그렇게 생각할 수도 있지, 근데 저거는 피라미드의 측면이야
- 저 그림 그리는데 어떤 툴 사용했나요? -> Excalidraw