코드 리뷰의 주목적은 구조를 개선하고 가독성을 높이는 등 유지보수를 위해 품질을 높이는 것입니다. 팀원끼리 서로 배움을 주고 받으면서 동기부여가 되기도 하고, 개발 현황을 수시로 공유하는 역할을 하기도 합니다.
- 코드 작성자는 변경내역을 요약하여 PR을 올립니다.
- 변경내역이 너무 많지 않도록 분량 조절
- 관련된 이슈는 #(이슈번호) 붙이기
- 리뷰어는 코드를 천천히 읽어봅니다.
- 문제가 없으면 'Approve' 표식 달기
- 의견, 우려되는 부분 등은 'Comment' 또는 'Request Changes' 표식 달기
- 코드 작성자는 리뷰를 읽고 수정 후 Merge합니다.
- 하루 이상 리뷰가 진행되지 않는다면 임의로 Merge 가능
다음은 코드 리뷰의 대상이 될 수 있는 부분입니다. 예시일 뿐이며 자유롭게 편한 방식대로 리뷰하면 됩니다.
- 가독성: 코드는 편하게 읽히는지, 개선할 여지가 있는지
- 복잡성: 같은 기능을 더 간단하게 구현할 수 있는지
- 재사용성: 이미 정의한 메소드나 클래스와 역할이 겹치지 않는지
- 코드 스타일: 네이밍룰 등 큰 틀의 코드 스타일을 잘 지켰는지
- 아키텍처: 레이어 및 디자인 패턴에 따라 관심사를 적절히 분리했는지, 적절한 패키지에 속하는지
- 성능: 메모리 누수, 비효율적 연산 등 개선 여지가 있는지
- 단일책임원칙: 클래스나 메소드가 비대하지는 않은지. 분리가 가능한지
- 질문: 코드에 대해 자유롭게 질문
- I Message: 상대를 지칭하기 보다는 자신의 주관을 설명합니다.
❌ 메소드를 너무 복잡하게 짜두셨네요.
⭕ 메소드가 어떤 일을 하는지 이해하기 힘드네요.
- OIR 규칙: 객관적 관찰 - 영향 - 요청의 세 부분으로 구성하면 좋은 피드백이 됩니다.
| 부분 | 설명 | 예시 |
|---|---|---|
| 관찰(Observation) | 코드의 객관적 사실을 설명 | "메소드 길이가 약 100라인 정도됩니다." |
| 영향(Impact) | 위 관찰이 본인에게 미친 영향 | "그래서 메소드가 어떤 역할을 하는지 파악하기가 조금 힘들었습니다." |
| 요청(Request) | 해결방안 또는 제안 | "10~20줄 부분은 private 메소드로 분리하면 알아보기 더 편할 것이라 생각해요." |
- PR에 대한 요약을 성의있게 작성해야 리뷰하기 편합니다.
- 코드 스타일 리뷰는 리뷰 마지막에 몰아 넣어서 최소한으로 하는 것이 좋습니다.
- 잘 분리된 커밋은 작성자는 물론 리뷰어에게도 큰 도움이 됩니다.
- 무거운 기능 구현은 같은 브랜치에서 중간중간 PR을 올립니다.
=> 변경된 코드의 양은 약 200~400줄이 적당 - 리뷰 대상은 작성자가 아닌 코드 자체임을 항상 인지합니다.