코드 리뷰의 표준 원칙
코드 리뷰의 주요 목적은 구글의 코드 베이스의 전반적인 코드 품질을 시간이 지남에 따라 개선되고 있는지 확인하는 것입니다. 코드 리뷰의 모든 도구와 프로세스는 이를 위해 설계되었고 이를 달성하기 위해서는 작성자와 리뷰어의 일련의 균형이 맞춰져야 합니다.
먼저, 개발자는 자신의 일을 진행할 수 있어야 합니다. 당신이 코드를 개선시키지 않으면 코드는 절대로 나아지지 않습니다. 물론, 코드 리뷰어가 변경사항을 수용하지 않는다면 개발자들은 코드를 개선하려는 의욕을 잃게 됩니다.
반면에 리뷰어는 시간이 지남에 따라 전반적인 코드의 품질이 낮아지지 않게할 의무가 있습니다. 특히 팀이 시간 제약이 있고 그들의 목표를 달성하기 위해 손쉬운 방법을 택할 때, 시간이 지남에 따라 코드의 품질은 낮아지기 때문에 까다로울 수 있습니다.
또한, 리뷰어는 리뷰 중인 코드에 대한 소유권과 책임이 있습니다. 그래서 그들은 코드가 일관성있고, 유지보수 가능하며 코드 리뷰에서 봐야하는 것에서 언급된 것들을 잘 유지해야 합니다. 따라서, 코드 리뷰에 기대하는 표준으로서 아래와 같은 규칙을 세웠습니다.
코드 리뷰어는 코드 변경점(changelist)이 완벽하지 않더라도 코드 품질이 확실히 개선되는 상태가 되었다면, 리뷰어는 해당 변경점을 승인하는 방향으로 고려해야 합니다.
이것이 모든 코드 리뷰 가이드 중 상위 원칙입니다. 물론 제한적인 경우도 있습니다. 예를 들면, 리뷰어가 원하지 않는 변경사항을 시스템에 추가하는 경우에는 코드가 잘 설계되었더라도 거부할 수 있습니다.
여기서의 핵심은 “완벽한” 코드란 것은 없으며 더 나은 코드만 있다는 것입니다. 리뷰어는 리뷰 승인을 하기 전에 코드 작성자에게 변경사항의 모든 작은 부분까지 완벽하게 하도록 요구해서는 안됩니다. 오히려 리뷰어는 변경 사항의 중요점과 앞으로 진행해야 하는 방향을 비교하여 균형을 맞추어야 합니다. 그러니까 완벽을 추구하기보다 지속적인 개선을 리뷰어는 추구해야 합니다. 따라서 완벽하지 않더라도 코드 변경사항이 유지보수, 가독성을 개선시킨다면 며칠 또는 몇 주 동안 지연되어서는 안됩니다.
리뷰어들은 항상 무엇인가 더 나은 방법이 있을 수 있다는 의견을 자유롭게 남길 수 있어야하지만, 그러나 그것이 그다지 중요하지 않다면 "Nit:" 과 같은 접두어를 붙여 코드 작성자가 선택할 수 있도록 해야 합니다.
주의: 이 문서에서 코드의 품질을 악화시키는 코드 변경사항 승인을 정당화하지 않습니다. 이는 오직 긴급상황일 경우에만 가능합니다.
멘토링
코드 리뷰는 개발자에게 언어, 프레임워크 또는 일반적인 소프트웨어 설계 원칙에 대해 새로운 것을 가르치는 중요한 기능을 할 수 있습니다. 개발자가 새로운 것을 배울 수 있도록 돕는 의견을 남기는 것은 항상 좋습니다. 지식을 공유하는 것은 시간이 지남에 따라서 코드 품질을 개선시키는데 도움이 됩니다. 당신의 의견이 순전히 교육적이라면, 반드시 "Nit:" 접두어를 붙이거나 코드 작성자가 반드시 수정해야 하는 것이 아님을 밝혀야 합니다.
원칙
- 기술적인 사실과 데이터는 의견과 개인의 선호보다 우선시되어야 합니다.
- 코딩 스타일에 있어서는, 스타일 가이드를 절대적으로 준수해야 합니다. 스타일 가이드에 없는 공백 등은 개인 취향입니다.
- 소프트웨어 설계에 관해서는 절대 스타일이나 개인적인 선호를 따라서는 안됩니다. 그것들은 기본 원칙을 기반으로 하며 단순하게 개인적인 의견이 아니라 그 원칙에 근거해야 합니다. 때로는 몇 가지 유효한 옵션이 있습니다. 코드 작성자가 (데이터를 통해 또는 SOLID 개발 원칙에 근거하여) 여러가지 접근 방법이 유효한 것을 입증한다면, 리뷰어는 코드 작성자의 선호를 받아들여야 합니다. 그렇지 않으면 소프트웨어 설계의 표준 원칙에 따라서 결정됩니다.
- 정한 규칙이 없다면, 리뷰어는 시스템의 전체 코드 품질을 악화시키지 않는 수준에서 기존 코드와 일관성이 있도록 코드 작성자에게 요구할 수 있습니다.
의견 충돌 해결
코드 리뷰에서 의견 충돌이 발생하는 경우, 첫 번째 단계는 코드 작성자와 리뷰어가 항상 이 문서의 내용을 토대로 합의를 시도해야 합니다. 의견 교환만으로 합의점을 얻기 어려운 경우 대면 회의(오프라인 리뷰) 또는 화상회의(Video Conference)를 갖는 것이 도움이 됩니다. (이런 경우에는 코드 리뷰를 보는 다른 사람을 위해 토론 결과를 댓글로 기록해야 합니다.)
그래도 문제가 해결되지 않는다면, 팀 단위 토론을 진행하거나 TL, 기술 매니저 등에게 도움을 요청합니다. 합의점에 도달하지 않았다고 코드 변경사항을 그대로 두지 말아야 합니다.
