Google의 코드 리뷰 가이드

내 생각

코드 리뷰의 목적: 코드를 팀에 공유하는 것

코드 리뷰의 목적은 코드를 동료와 공유하는 것이다.

  • 작업자는 자신의 작업을 리뷰어에게 공유하는 방식으로 작업 결과를 팀에 전파한다.
  • 리뷰어는 작업자의 코드를 읽으며 새로운 것을 배우거나 변경사항을 파악하게 된다.
  • 바람직한 변화는 축하하거나 칭찬한다.
  • 바람직하지 않은 변화는 수정 제안을 하거나 같이 대책을 생각하는 시간을 갖는다.

따라서 작업자는 리뷰어가(팀이) 이해하기 용이하도록 PR이나 문서에 설명을 잘 적어줘야 한다.

  • 리뷰어가 PR을 이해하지 못하거나 대충 파악하게 되면,
    • 사소한 트집을 일일이 잡는 방식으로 리뷰하게 될 수 있다.
    • 이건 리뷰어만의 잘못이 아니다.
    • 작업자는 리뷰어가 완전히 다른 일을 하다가 컨텍스트 스위칭을 해서 리뷰한다는 걸 고려해야 한다.

코드 리뷰는 실수를 찾아 지적하는 게임이 아니다

한편, 코드 리뷰의 목적을 "다른 사람의 작업에서 실수를 찾아내는 게임"으로만 생각하면 곤란하다.

리뷰어들이 코드 리뷰를 실수 찾기로 생각한다면, 다음과 같은 일들이 벌어지곤 했다.

  • 코드 리뷰를 할 때 리뷰어가 작업자의 작은 실수들에 집중하게 되는 문제.
    • 작업의 핵심이 아니라 오타, 인덴트 등 사소한 것을 트집잡으며 작업자에게 스트레스를 주면서 코드 리뷰를 하고 있다고 착각할 수 있다.
      • 작업의 핵심 영역을 리뷰하지 않고 슬쩍 지나치기도 한다.
      • 코드 리뷰에 지적사항이 너무 많으면 작업자가 부담을 느끼게 된다.
        • 자잘한 실수가 많다면 코멘트를 100개 남기는 것보다 그냥 옆자리로 가서 부드럽게 대화하면서 조금씩 같이 고치는 것도 선택 가능한 방법.
      • 차라리 리뷰 대상 PR(1)에 작은 문제들을 수정한 브랜치를 만들고 PR(2)로 보내는 것도 괜찮은 방법.
        • 작업자가 리뷰어의 PR(2)를 작업 브랜치에 머지한 다음 갱신된 PR(1)에서 리뷰를 이어가면 된다.
  • 리뷰어가 칭찬거리보다 지적거리를 찾으려 노력하게 되는 문제.
    • 칭찬할만한 좋은 코드를 발견해도 칭찬하지 않고 아무런 코멘트를 남기지 않고 넘어간다.
    • 괜찮은 선택에는 칭찬하는 코멘트를 남기는 것도 좋다.
  • 작업자가 시간이 흐르면서 코드 리뷰 요청을 점점 더 어려워하게 되는 문제.
    • 어렵게 만든 코드 리뷰 문화가 점점 위축되다가 결국 사라지게 되기도 한다.

코드 리뷰는 친절하게, 협조적으로

  • 코드 리뷰를 받는 게 고통스러운 절차가 된다면 지속할 수 있을까?

종종 작업자에게 칭찬도 해준다. 그리고 평가는 조심스럽게 하되, 건설적인 관점에서 하도록 한다. 마음에 안 드는 점이 있다면 협력하겠다고 제안하는 것도 괜찮은 방법.

  • "이 부분 너무 좋은 것 같습니다. 버그가 해결됐는데 가독성도 좋아졌어요."
  • "다들 미뤄두기만 했던 걸 작업해주셔서 감사합니다. 테스트 코드를 좀 보완할 수 있을 것 같은데 제가 작업해서 PR로 보내볼게요."

리뷰어 역할이 특정한 사람에게 집중되지 않도록 한다

코드 리뷰가 특정 사람들에게만 요청되면 곤란할 수 있다.

  • 특정한 사람에게만 코드 리뷰가 집중된다면,
    • 암묵적으로 서열관계가 생길 수 있다.
    • 코드 리뷰를 많이 하는 사람의 작업물은 상대적으로 허술한 리뷰를 받게 될 수 있다.
    • 코드 리뷰를 많이 하는 사람의 멘탈이 자신도 모르는 사이에 지적을 견디기 어렵게 변해갈 수도 있다.

적당히 리뷰어를 회전시키며 코드 리뷰를 진행하는 것도 고려할 수 있다.