코드리뷰

[leejaeseung]

바람직한 코드리뷰 문화를 만들려면?!
https://soojin.ro/review/reviewer
위 글을 요약/정리한 팀 내 글을 공유합니다.
아래 요약글 외에도 좋은 내용이 많은 것 같아 위 블로그 글을 정독해보면 좋을 것 같네요

용어

• CL (Change List): (PR에 포함되어있는) 변경 사항
• 작성자 (Author): PR을 요청한 사람
• 리뷰어 (Reviewer): PR을 리뷰하는 사람
• 원작자 (Original Author): CL에 해당하는 이전 코드를 작성했던 사람

코드 리뷰의 대원칙

완벽한 코드를 만들려고 하지 말고 더 나은 코드를 추구해야 한다.

• CL이 본인 기준으로 완벽하지 않더라도 전체적인 코드 품질을 증가시키는 상태에 도달했다면 리뷰어는 해당 CL을 승인하는 방향으로 검토한다.
• 유지보수성과 가독성에 중점을 두도록 한다.

언제나 기술적인 사실을 개인적인 견해나 선호도보다 우선시 한다.

코드 리뷰를 통과한 이후부터 그 코드는 모두의 코드이다.

• 모두의 코드이므로 작성자 혹은 원작자에 대한 비난은 하지 않는다.

서로 존중하고 배려하는 마음으로 의견을 나눈다.

코드 리뷰 속도

원칙

• 개개인의 개발 속도보다는 팀의 개발 속도를 최적화한다.
• 리뷰가 통과하기까지 걸린 총 시간이 아니라 응답 시간이 중요하다. 리뷰에 관한 메시지가 빨리 오고 가는 것이 중요하다.
  (개인적으로 정말 중요하다고 생각됩니다.)
• 일시적인 속도 향상을 위해 품질을 포기하면 안된다.

언제 해야 할까?

• 현재 몰입 중인 상태가 아니라면 리뷰 요청을 받자마자 한다.
• PR 요청 시간 기준으로 하루(24시간)를 넘기지 않는다 (휴일 제외).
  • 단, 퇴근 시간 30분 전에 PR이 오면 다음날 처리해도 된다.
• 다음 날 출근해서 가장 먼저 처리해야한다. : 실제로 이 글을 보고 실천 중!
• 하나의 PR은 하루에 수 차례 리뷰를 받을 수 있어야 한다.
• 긴급건이거나 코드 리뷰가 지체된다고 판단하면 작업자는 리뷰어에게 리뷰를 재요청할 수 있다.
  • PR 제목 혹은 톡 메시지에서 가장 앞에 [긴급] prefix를 넣어서 요청한다.

속도 vs. 방해

• 몰입하여 개발을 하고 있는 상태라면 코드 리뷰를 하기 위해 도중에 일을 멈추지 않는다.

코드 리뷰에 의견 작성하는 법

상호 존중

• 작성자가 아니라 코드에 대한 의견을 제시한다.

방향 제시하기

• 최종적으로 CL을 수정해야할 책임은 작성자한테 있다.

• ~로 바꿔주세요 (X) → 저는 ~로 바뀌면 좋을 것 같은데 작성자는 어떻게 생각하시나요? (O)

• 관련 링크나 배경을 자세히 설명하여 작성자가 이해하기 쉽도록 한다.

• 리뷰어가 코드를 보고 이해가 안가서 작성자에게 설명을 요청했다면 코드 개선을 고려해본다.

1 PR 1 칭찬

• 칭찬은 고래도 춤추게 한다. 1 PR에 최소 1번 칭찬하자.
• 따봉을 남발하자.

작성자의 반대 의견에 대처하는 방법

친절하게. 친절하게. 친절하게.

"나중에 다듬을게요"

• 나중에 다듬을 시간은 없다. 시간이 너무 오래 걸리는 경우가 아니면 수정하자.

"기준이 너무 까다로워요"

• 느슨한 코드 리뷰는 나중에 비수로 날아와 꽂힌다.
• 기준이 까다로운 것이 아니라 어조가 강했던 것은 아닌지 생각해본다.

의견 충돌 해결하기

• 댓글 교환만으로 합의가 어려우면 직접 만나서 의견을 나눈다. : 코드 리뷰 회의를 열자
• 대화 내용은 미래의 작업자들을 위해 반드시 댓글로 남긴다.
• 그래도 합의가 안되면 팀 단위 토론을 하거나, TL 혹은 원 저자의 의견을 듣도록 한다.

오프라인 코드 리뷰

팀 레벨 리뷰

• 팀원 전체가 회의실에 모여서 진행하는 리뷰

언제 요청하는 것이 좋을까? (예시)

• 설계에 대한 감이 안 잡히는 경우, 코드 작성 전에 요청한다.

1:1 리뷰

• 작성자와 리뷰어 혹은 작성자와 원작자가 나란히 앉아서 진행하는 리뷰

언제 요청하는 것이 좋을까? (예시)

• PR 도중 다른 구현 방향을 추천하고 싶은데 코멘트로 설명하기 어려운 경우에 리뷰어가 요청한다.
• 리뷰어가 이전에 수정 요청한 부분을 작성자가 수정했지만 원하는 방향으로 반영되지 않은 경우에 리뷰어가 요청한다.
• 리뷰자의 의견이 댓글로 전달이 잘 되지 않았을 수 있다. 이럴 때는 구두로 설명하는게 효과적이다.

몇 명의 리뷰를 받는 것이 좋을까?

• 최소 2인 이상 (가능하면 원작자 포함)
• 페어 프로그래밍을 했다면 작성자들은 리뷰어가 될 수 없다.