How to do a code review

https://google.github.io/eng-practices/review/reviewer/

How to do a code review

 

the best way to do code reviews, based on long experience of Google.

 

 

The Standard of Code Review

구글에서 사용되는 코드를 오랜시간 건강하게 보장하는 것이 Code Review의 가장 큰 목적이다. Code Review에 사용되는 모든 tools와 processes  정리되어있다. 

 

첫째, 개발자는 "테스크를 진행할 수 있어야한다.". 만약 당신이 코드단에서의 개선을 제공하지 않으면 코드는 절대 개선되지 않는다. 또한, 만일 리뷰어가 변경이 적용되는걸 힘들게 한다면 개발자는 미래에 개선에 대한 의욕을 잃게된다. 

 

반면에 리뷰어의 의무는 각각의 CL(change list)들이 시간이 지남에 따른 코드의 퀄리티가 낮아지지 않도록 보장하여야한다. 이건 굉장히 tricky한데 특히나 팀이 중요하고 시간 제약에 의하여 빠르게 팀의 목표를 달성하여야할때 코드는 시간에 걸쳐 퀄리티를 조금씩 잃게 된다. 

 

또한 리뷰어는 그들이 리뷰하는 코드에대한 책임감과 소유권을 가지고 있어. 그들은 코드가 지속적이고, 유지 관리가 되는 등  “What to look for in a code review.” 에 언급된 내용들을 보장할 수 있어야한다. 

그러므로, 우리는 코드 리뷰를 할 경우 아래의 규칙을 표준으로 따라야한다:

 

In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect.

 

이것에 대한 제약이 당연히 존재해. 예를들어, review가 그들의 시스템에 원하지 않던 기능이  CL에 있을 경우, 코드가 잘 짜여있어도 리뷰어는 거부할 수 있어.

 

핵심은 "perfect-code"라는 것은 존재하지 않는다는 것이다. - 오직 더 나은 코드가 있을 뿐. 리뷰어는 approve를 위해  코드 작성자가 모든 작은 CL에 대하여 다듬도록하면 안된다. 그 보다는, 리뷰어는 그들의 제안한 변경의 중요성과 앞으로의 진행 방향을 바탕으로 균형을 맞추어야합니다. 완벽함을 추구하는 것 보다는 리뷰어가 추구해야하는건 지속적인 개선입니다. CL은 시스템의 유지성,  가독성 그리고 이해성을 완벽하지 않다는 이유로 미루면 안됩니다. 

리뷰어는 항상 더 나은 방향을 위한 표현에 대해서 자유로워야한다. 그러나 그것이 중요하지 않다면 "Nit:" 라는 prefix를 통하여 작성자가 ignore 할 수 있다는 것을 말해주어야합니다.