코드 리뷰의 대원칙
코드 리뷰를 하는 주된 목적은 전체적인 코드 품질을 꾸준히 개선하기 위해서다. 그러려면 상충하는 두 가지 입장의 균형을 잘 맞춰야 한다.
첫째로 개발자는 자신이 맡은 일을 완수하면서 코드를 발전시켜야한다. 당신이 코드를 개선하지 않으면 코드는 절대 나아지지 않는다. 반면, 리뷰어가 너무 까다롭게 기존 코드를 방어하고 아무런 변화를 받아들이지 않으면 다른 개발자들은 코드를 개선해나갈 의지를 잃는다.
그럼에도 리뷰어는 코드 품질이 점차 낮아지지 않게 할 책임이 있다. 시간이 촉박한 상황에서 임시방편으로 문제를 해결하는 일들이 조금씩 쌓이다보면 코드의 품질이 낮아지기 마련이다. 따라서 리뷰어는 주인 의식과 책임감을 가지고 코드의 일관성, 유지 보수성, 코드 리뷰에서 중점적으로 볼 점에서 언급된 것들을 잘 챙겨야 한다.
그리하여 우리는 코드 리뷰의 대원칙을 아래와 같이 세우게 되었다.
CL이 완벽하지 않더라도 전체적인 코드 품질을 증가시키는 상태에 도달했다면 리뷰어는 해당 CL을 승인하는 방향으로 생각한다.
물론 예외도 있다. 리뷰어가 추가 하고 싶지 않은 기능이라면 코드의 구조가 아무리 좋아도 거부할 수 있다. 기억해야할 점은 완벽한 코드를 만들려고 하지 말고 더 나은 코드를 추구해야 한다는 것이다. 완벽함 대신 지속적인 개선(continuous improvement)을 목표로 한다. 따라서 완벽하지 않더라도 CL이 코드의 유지 보수성과 가독성을 개선한다면 승인이 몇날 몇일 지연돼서는 안된다.
주의: 코드 품질을 악화시키는 CL을 승인하는 행위는 어떤 경우에도 정당화 될 수 없다. 오직 긴급 상황 일 때만 허용된다.
멘토링
개발자들은 코드 리뷰를 통해서 언어나 프레임워크, 소프트웨어 디자인에 대한 새로운 지식을 배운다. 지식과 경험을 나누면 코드 품질이 점점 좋아진다. 당신의 의견이 교육적인 내용이라면 반드시 “Nit: “(역주: nitpick의 줄임. 사소한 것) 접두사를 써서 필수적으로 코드를 수정할 필요는 없다고 밝혀둔다.
소원칙
- 언제나 기술적인 사실을 개인적인 견해나 선호도보다 우선시 한다.
- 코드 스타일에 관해서는 스타일 가이드를 절대적으로 따른다. 정해진 가이드가 없으면 작성자를 따른다.
- 소프트웨어 설계에 관한 사안에서는 절대 스타일이나 개인 선호를 기준으로 결정하지 않는다.
- 정해둔 규칙이 없을 때는 기존 코드와 일관성을 유지하도록 한다.
의견 충돌 해결하기
리뷰어와 작성자의 의견이 다를 경우 이 문서에 나와 있는 방법과 원칙을 토대로 최대한 합의를 이루도록 노력한다. 댓글 교환만으로 합의가 어려우면 직접 만나거나 화상으로 얘기를 나눈다. 대화 내용은 미래 개발자들을 위해 반드시 댓글로 남긴다. 그래도 합의가 안되면 팀 단위 토론을 하거나, TL 혹은 원 저자의 의견을 듣거나, 엔지니어링 매니저한테 도움을 청한다. 합의가 안된다고 절대 CL을 방치해두지 말아라.