1. 코드리뷰의 목적
•
기능 정상 동작 여부 검증 (품질 문제 검증)
•
코드 퀄리티 유지
•
학습 및 지식 전달
•
상호간의 성장
•
상호 책임감 증대
2. 코드리뷰의 현주소
•
페어로 과제 진행 시
◦
페어 작업자들 끼리 일반적으로 코드 리뷰
•
단독 과제 진행 시
◦
팀 내부적으로 리뷰 하나, 많은 리뷰가 진행되진 않음
•
일정에 쫓기다보면 리뷰 없이 머지하는 경우도 발생
3. 코드리뷰가 어려운 이유
•
상당한 리소스가 소모됨
◦
현재 할당된 과제 일정 vs 코드리뷰
◦
요구사항, 비즈니스로직 파악
•
생각을 글로 전달되는 것의 어려움 (오해의 소지가 큼)
4. 코드리뷰를 잘하기 위한 방법
4.1. 컨벤션 & 아키텍처 확립
•
코드 리뷰를 잘 하기 위한 근거이자 기준
•
컨벤션 & 아키텍처 확립을 통해 불필요한 논쟁 및 시간 낭비 제거
•
코드리뷰를 쉽게 하기 위한 comfort zone 증가
4.2. PR 작성자
•
PR 내용을 잘 파악할 수 있도록 PR Description 잘 작성하기
◦
컨텍스트 파악을 위한 개발 디자인 문서 등 공유
4.3. 코드리뷰를 위한 리소스 할당
•
코드 리뷰를 위한 시간 본부 단위로 할당
◦
예) 하루에 30분~1시간은 항상 코드리뷰 시간으로 고려
•
아이디어
◦
본인 과제 외 다른 1개의 과제는 필수로 코드 리뷰 할당
◦
리뷰 마스터 도입
▪
스프린트 마다 팀에 2명 정도를 리뷰마스터로 선정
▪
리뷰마스터는 코드리뷰를 위한 리소스를 더 감안하여 작업 분배
4.4. 피드백 방법
•
의견이 아닌 원칙 기반
•
부드러운 톤으로 조심스럽게 표현
◦
ㅏ 다르고 ㅓ 다름
◦
공격적인 표현 제외
•
건설적인 피드백
•
진정한 칭찬
•
피드백은 명령이 아니라 요청으로 표현
◦
단순히 개선 코드만 작성 X
4.5. 교착 상태
•
저자와 리뷰어 상호간에 구두로 논의
•
교착 상태가 해결되지 않는 경우
◦
팀장에게 Escalation
◦
팀원들과 다같이 논의 (예. 데일리 미팅)
4.6. 기타
•
설계 리뷰가 따로 있으면 어떨지?
◦
고수준에서 리뷰 1차적으로 우선 진행
•
코드리뷰 코멘트에 대해 어떠한 형태로든 답변 남기기
◦
리뷰어가 남긴 코멘트가 리뷰 된건지 아닌건지 확인 가능
•
태그 활용
◦
조금은 불필요하다고 판단 될 수 있는 리뷰들을 태그로 남긴다면 어떨지?
▪
취향의 차이 (if vs switch)
▪
바꾸기도 뭐하고 안 바꾸기도 뭐한 애매한 수준의 변수명 제안
▪
아주 미묘한 성능 개선 제안
▪
너무 먼 미래에 대한 방어 코드
