코드 리뷰 피라미드
코드 리뷰에 관련하여 중요한 측면(코드 변경이 필요한지, 성능이 좋은지, 기존 클라이언트 및 기타 클라이언트와 하위 환 여부)이 관심을 덜 받는 경향이 있음. 이 문제에 대한 중요성을 개발자들에게 인식시키기 위해 코드 리뷰에서 중점적으로 봐야할 부분과 자동화해야 할 부분을 한장의 그림으로 정리.
각 단계별로 물어봐야 할 필수 질문들을 자문해보며 코드를 리뷰해보자. 나중에 변경하기 쉬운 코드스타일/테스트 쪽은 자동화하고, 문서화/구현/API 쪽을 리뷰하는데 집중하자.
1단계 : 코드 스타일 (Code Style)
- 프로젝트 포매팅 스타일이 적용되었나?
- 합의된 네이밍 컨벤션을 준수하는가?
- DRY(Don't Repeat Yourself)인가?
- 코드가 적절하게 "readable" 읽을 수 있는가? (메소드 길이 등)
2단계 : 테스트 (Tests)
- 모든 테스트가 pass하는가?
- 새로운 피쳐들이 적절하게 테스트 되었는가?
- 가능한 곳에서 유닛테스트를 사용하고 꼭 필요한 곳에서 통합테스트를 하는가?
- NFR(Non Functional Requirements)테스트가 있는가? (ex. 성능같은 ?)
3단계 : 문서화 (Documentation)
- 새로운 피쳐들이 적절하게 문서화 되었는가?
- 적절한 문서 유형들이 작성되었는가? README, API 문서, 사용자 가이드, 레퍼런스 문서 등
- 문서들은 이해 가능한가? 중요한 오타나 문법오류가 없는가?
4단계 : 올바른 구현 (Implementation Semantics)
- 오리지널 요구사항을 만족하는가?
- 논리적으로 올바른가?
- 쓸데없는 복잡도가 있지는 않은가?
- Robust한가? (동시성 이슈 처리, 적절한 에러 처리 등)
- 성능이 괜찮은가?
- 안전한가? (ex. SQL Injection 가능한가 등)
- Observable한가? (ex. metrics, logging, tracing 등)
- 새로 추가된 종속성이 그만한 가치를 하는가? 그들의 라이센스는 수용가능한가?
5단계 : 올바른 API 설계 (API Semantics)
- API는 가능한 만큼 작고 필요한 만큼 큰가?
- 한 개의 작업을 하는데 여러가지 방법 대신 단 한 개의 방법만 있는가?
- 일관성이 있거나, 적어도 놀람 최소화(PLS) 법칙을 따르는가?
- API와 내부함수가 명확히 분리되어있고, 내부가 API에 노출되지 않는가? (not public)
- 사용자 대면(user-facing) 부분에 호환성을 깨는 변경이 있는가? (API 클래스, 설정, 메트릭, 로그 포맷 등)
- 새 API가 일반적으로 널리 사용가능하고, 쓸데 없이 구체적이지는 않은가?
참고
'Dot . > 개인 공부 기록용' 카테고리의 다른 글
| GIT 사용할 때 협업시 미리 알고 있으면 좋은 명령어 (0) | 2022.07.24 |
|---|---|
| nGrinder vs Jmeter 성능 테스트 툴 비교해보기 (0) | 2022.04.29 |
| 배포한 프로젝트 서버 성능 올리기 (처리량, 응답시간) (0) | 2022.04.03 |
| [우아한테크세미나] Entity 클래스의 설계와 퍼시스턴스 프레임워크의 활용 (0) | 2022.02.20 |
| [Eclipse/ IntelliJ] Java 프로젝트에 JSON 라이브러리 설치하기 (org.json) (0) | 2021.09.21 |
