코드리뷰 개론

구글에 처음 코드 리뷰를 도입한 직원의 인터뷰

• 이해할 수 있는 코드를 작성하도록 강요하기 위해서였다.
• 여러 사람이 코드에 익숙해지도록 보장하므로 지식이 회사에 유지될 가능성을 높인다.
• 버그 발견도 좋지만 가장 큰 이유는 코드 이해도와 유지보수성을 개선하기 위한 것이었다.
  (defect를 찾는것이 중점이 아니다!)

시간소요가 있지만,
개인의 개발속도도 중요하지만 팀 전체의 속도만큼은 중요하지 않다.

Speed of code reviews

코드리뷰가 느리면

• 팀 전체의 속도가 감소한다.
• 개발자들이 코드리뷰 프로세스에 대해 부정적으로 생각한다.
• 코드 품질에 영향을 줄 수 있다.

How fast should code reviews be?

• 만약 집중해서 어떤 업무를 하고 있지 않다면, 코드리뷰 요청을 받자마자 진행해야 한다.
• 업무일 기준으로 하루를 넘어서는 안된다. (즉, 다음날 아침의 첫번째 업무가 되어야 한다)

Why write small changes?

• 리뷰를 빠르게 할 수 있다.
• 더 철저하게 리뷰받을 수 있다.
• 버그가 발생할 가능성이 작다.
• 리뷰가 반려되었을때 낭비되는 시간이 적다.
• 코드를 Merge하기 쉽다.
• 더 잘 설계할 수 있다.
• 리뷰로 인한 업무 진행 차단이 적다.
• 더 간단한게 Rollback 할 수 있다.

What is small?

• 한 가지만 해결하는 최소한의 변경. 전체 기능 중 일부분.
• 테스트 코드를 포함해야한다.
• description을 잘 작성하는 것도 중요하다.
• 반영한 후에도 시스템이 잘 작동해야한다.
• 의미를 이해하기 어려울 정도로 작지는 않아야 한다.
• 파일 수가 적어야 좋다.
• 리뷰어는 너무 작은 변경점에 대해서는 거의 불평하지 않는다.

Google에서는,

• 변경사항 중 35% 이상은 단일 파일 수정
• 90%는 10개 미만 파일
• 10%는 코드 1라인 수정
• 평균 24라인 수정

Social interactions

• Tone : 부정적 톤의 코멘트는 도움이 되지 않는다.
  • 주장의 내용보다는 의견을 작성하는 방식이 정중하지 않을 때 기분이 상한다.
  • 소프트웨어 설계에 관해선 절대 개인적인 선호를 따라서는 안된다.
• Power - 리뷰를 질질 끌거나 승인을 미루며 권력과시
• 소통방식의 문제는 개발자가 리뷰 프로세스를 불편하게 느끼도록 한다.

The standard of code review

코드 리뷰어는 코드 변경점이 완벽하지 않더라도 코드품질이 확실하게 개선되는 상태가 되었다면, 해당 변경점을 승인하는 방향으로 고려해야한다. 이것이 모든 코드리뷰 가이드 중 상위원칙이다.

• 완벽한 코드란 없으며 더 나은 코드만 있다.
• 보이스카웃 원칙

코드리뷰 Q&A

• 도메인지식이 없어서 리뷰가 어려워요.
• 가독성이나 유지보수성을 위해 수정을 하라고 코멘트하기 부담스러워요

코드리뷰의 가장 큰 목적은 가독성과 유지보수성을 높히기 위한 것입니다.

• 내가 리뷰한 코드에 다른 부분에 영향을 주는 버그가 있지 않을까 걱정됩니다.

Defact를 발견하는것도 좋지만 거기에 집중하지 안해도 됩니다. 테스트 코드가 잘 되어있는지 봐주는 것만으로도 도움이 됩니다.

• 리뷰 시간이 부족해요. 리뷰 코드양이 너무 많아서 파악이 어려워요.

코드 작성자는 최대한 수정사항을 작게, 리뷰어는 최대한 요청받자마자

• 디스크립션이 부실합니다.

자세하게 써주세요.

• 지적으로 느끼지 않을까 걱정됩니다.

최대한 정중하게. 의견보다 의견 방식에 상처를 받는다.

애티튜드와 관련한 방법론

• SBI(N) 코드리뷰

상황 Situation
결과 Behavior
영향 Influence
다음에는 Next

• 두괄식 리뷰
  앞말이길면 부담스럽고 심리적 저항감이 생긴다
  (ex) 잠깐 이야기 괜찮아? 이거봤는데 저걸보니까 말이지 어쩌고 저쩌고

• 오레오맵 방법

Opinion
Reason
Example
Offer