코드 리뷰의 포인트
| 작성자 | 리뷰어 |
|---|---|
| 빠르게 개발해서 배포하는게 목적… | 코드 꼼꼼히 리뷰 해서 회사의 팀의 리스크를 줄이는 목적… |
| 1차 리뷰어: 코드 담당자에게 할당 2차 리뷰어: 신입 개발자에게 할당 |
- |
[작성자 Tip]
- 리뷰어의 좋은 의도를 생각해야 하며, 코드를 감정적으로 받아들면 안된다.
a. 동료, 후임에게 지적 받는 것 같은 불편함과 자존심 상하는 마인드의 개발자는 성장하기 힘들다.. - 동일한 코멘트를 받지 않도록 숙지하고 개선해서 앞으로 코드를 만들어 나간다.
- 경력에 상관없이 배울 점이 있다면 수긍하고 받아 들이는 마인드를 가져라.
- PR 사이즈를 최대한 작게해서 요청 (코드 변경을 작게…)
a. 코드 크기가 크면 코드 리뷰도 느리고 피드백 반영도 느려진다.
b. 가급적 PR에 400줄 이하로 요청하는것이 좋다.
c. 버그 하나당 하나의 PR 요청 권장.
d. 버전 업데이트 및 리팩토링은 별도의 PR 요청 권장.
e. 규모가 큰 변경 사항은 의미 있는 작은 단위로 요청 권장. - 리뷰어가 빠르게 이해할 수 있도록 맥락(Context)를 이해할 수 있도록 정보 제공한다.
- 즉, PR 설명란에 코드가 뭘 하는지 설명하기 보다는 왜 이런 선택을 했는지에 대한 내용을 기재하는 것이 좋다.
a. (Why > What)
[맥락(Context)를 이해할 수 있도록 정보 제공 - PR 요청 시 설명란 샘플]
- What? - 이 PR 이 무엇인지?
- Why? - 어떤 티켓을 배수를 하는지? 왜 필요한지?
- How? - 어떻게 구현 했는지?
- Testing? - 어떻게 테스트 할 수 있는지?
- Screenshots (optional) - 이해하기 위한 스크린샷…
- Anything Else? - 어떻게 재현할 수 있는지?
- 빠른 시일 내에 리뷰를 받을 수 있도록 최선을 다한다.
a. 리뷰어가 휴가가 있는지 일정이 바쁜지 체크 후 리뷰 요청을 언제까지 해달라고 요청… - 리뷰어의 코멘트에 대한 부분에 확실한 답변을 기재한다.
a. ex) 네, 반영 햇습니다.
| 접두사 축약어 | 의미 | 설명 |
|---|---|---|
ACK |
Acknowledge | 인정한다. 반영 완료 했다 |
[리뷰어 Tip]
- 꼼꼼하게 확인 (팀의 리스크를 줄이기)
a. 누락된 기능 (케이스) 조기 발견
b. 버그 및 실수 조기 발견
c. 테스트 코드의 작성 여부
d. 코드 컨벤션이 잘 지켜졌는지 확인
e. 가독성과 확장성 및 유지보수 편의성
f. 팀원들의 이해도 향상
g. 코드 퀄리티 향상 - 컨벤션에 관한 리뷰는 자동화 한다.
a. (테스트 커버리지, ESLint, Formatter, Team’s Convension)
b. 기본적인 것들은 자동화 하고 리뷰어는 근본적인 코드 코어에 집중한다. - 좋은 의도를 전제로, 친절하게 설명한다.
a. 비판보다는 호기심을 가지고 작성자의 코드 의도를 파악 - 명확하고 구체적인 피드백 주기
a. 이유와 다른 대안 / 추천하는 방법을 제안 - 중요성에 따라 명확한 행동을 촉구
| 접두사 축약어 | 의미 | 설명 |
|---|---|---|
QQ |
Quick Question | 질문 요청 |
NIT |
Nitpicking | 마이너 요청 (옵션 사항) |
RC |
Request For Change | 필수 수정 요청 |
- 리뷰 완료를 명확하게 작성자에게 알려라.
a. 승인 | 반려 | 질문 등등…
b. 리뷰 처리를 하면 자동으로 메일로 가겠지만 확실하게 메신저로 한번 더 정확히 알려주는게 좋다.