왜 코드 리뷰를 빠르게 해야하나?
구글에서는 개인이 코드를 작성할 수 있는 속도를 최적화기보다 팀이 제품을 함께 생산할 수 있는 속도를 최적화합니다. 개인의 개발 속도도 중요하지만 팀 전체의 속도만큼은 중요하지 않습니다. 코드 리뷰가 느리면 다음과 같은 몇가지 일이 발생합니다.
- 팀 전체의 속도가 감소합니다. 리뷰를 빠르게 해주지 않은 팀원은 자기 일은 끝냈겠지만, 코드 변경사항은 반영되지 못하고 리뷰를 기다림에 따라 새로운 기능 추가나 버그 수정은 며칠, 몇 주 또는 몇 달씩 지연됩니다.
- 개발자들이 코드 리뷰 프로세스에 항의하기 시작합니다. 리뷰어가 며칠에 한 번씩만 의견을 주면서 매번 큰 수정사항을 요구하면, 개발자에게 좌절감을 주거나 리뷰가 너무 까다롭다고 생각할 수 있습니다. 종종 이것은 리뷰어가 얼마나 “엄격한” 지에 대한 불평으로 표현됩니다. 개발자가 코드를 수정할 때마다 리뷰어가 의견을 준다면 불평사항은 사라지는 경향이 있습니다. 실제로 리뷰 속도를 빠르게 하면 코드 리뷰 프로세스에 대한 불평은 해결됩니다.
- 코드 품질에 영향을 줄 수 있습니다. 리뷰가 느리면 개발자가 할 수 있는 것보다 낮은 품질의 코드가 작성될 수 있고 코드 정리, 리팩토링 및 기존 변경사항에 대한 추가적인 개선 의욕을 저해합니다.
얼마나 빨라야 할까?
만약 당신이 집중된 업무를 하고 있지 않다면, 코드 리뷰 요청을 받자마자 진행해야 합니다. 업무일 기준으로 하루를 넘어서는 안됩니다.(즉, 다음날 아침의 첫 번째 업무) 가이드라인을 따르면 코드 변경사항은 하루에 여러 번(필요한 경우) 리뷰를 받아야 한다는 것을 의미합니다.
속도 vs 방해
개인의 속도가 팀의 속도보다 더 고려되는 경우도 있습니다. 만약 당신이 코드 작성과 같이 집중된 작업을 하고 있다면, 코드 리뷰를 위해 일을 멈추지 말아야 합니다. 개발자가 도중에 일을 중단하고 개발을 다시 하려면 오랜 시간이 걸릴 수 있습니다. 그래서 리뷰를 위해 자신의 코드 작성을 멈추는 것이 다른 개발자에게 리뷰를 기다리게 하는 것보다 팀에게 더 큰 비용이 듭니다. 현재 코드 작업이 끝났거나, 점심식사 후, 회의가 끝난 후, 또는 휴게공간을 다녀온 후에 리뷰를 합니다.
빠른 응답
코드 변경사항이 리뷰를 통과할 때까지의 소요된 전체 시간이 아니라 응답 시간이 코드 리뷰의 속도에 중요합니다. 전체 과정이 빠르게 진행되는 것보다 리뷰에 대한 개별 응답 시간이 빨리 오는 것이 더 중요합니다. 때때로 전체 코드 리뷰 과정이 오래 걸리더라도, 리뷰어의 응답이 빠르면 코드 작성자가 “느린” 코드 리뷰로 느끼는 불만은 줄어듭니다.
만약 당신이 너무 바빠서 리뷰하기 어렵다면, 언제쯤 리뷰를 시작할 것인지 또는 다른 리뷰어를 제안하거나 초기에 광범위한 의견을 제공할 수 있습니다. (주의: 이와 같은 응답을 보내기 위해 자신이 개발하고 있는 작업을 멈추지 않음) 응답은 빠르면 좋지만, 리뷰는 “LGTM”이란 뜻이 “이 코드는 우리의 표준 원칙을 충족한다.” 라는 것을 확실히 하기 위해서 리뷰에 충분한 시간을 소비하는 것이 중요하다.
시차가 있는 코드 리뷰
시차가 있다면(다른 시간대에 있다면), 코드 작성자가 업무 중일 때 코드 리뷰에 응답할 수 있도록 합니다. 이미 퇴근했다면, 다음 날 출근하기 전까지 리뷰가 완료되도록 합니다.
의견이 있는 LGTM
코드 리뷰의 속도를 높이기 위해 리뷰어가 몇 개의 미해결 의견을 남기더라도 리뷰를 승인할 때가 있습니다. 이 작업은 다음 중 하나일 때 해당됩니다.
- 리뷰어는 코드 작성자가 모든 리뷰어의 나머지 의견을 적절하게 처리할 이라고 확신하는 경우
- 남은 변경은 우선 순위가 낮기 때문에 필수적이지 않은 경우
코드 리뷰어는 명확하지 않은 경우 이러한 옵션 중 어느 것을 의도하는지 댓글로 남겨야 합니다. 리뷰어와 코드 작성자가 다른 시간대에 있는 경우 특히 고려할 가치가 있습니다. 그렇지 않은 경우 코드 작성자는 리뷰 승인을 얻기 위해 하루 종일 기다려야 합니다.
거대한 코드 변경사항
코드 작성자가 너무 큰 코드 변경사항에 대해 리뷰를 요청하면, 여러 개의 작은 코드 변경 사항으로 나누도록 요청해야 합니다. 이는 코드 작성자에게 추가적인 작업이 필요하지만 일반적으로 가능하며 리뷰어에게 매우 유용합니다.
만약에 작은 단위로 분리할 수 없거나 전체 내용을 빠르게 리뷰할 수 없다면, 최소한 설계에 대한 개선 의견이라도 개발자에게 빠르게 전달해야 합니다. 리뷰어로서 목표 중 하나는 코드 품질을 떨어뜨리지 않으면서 코드 작성자가 추가 개선 작업을 빠르게 수행할 수 있도록 하는 것입니다.
시간이 지날수록 개선되는 코드 리뷰
당신이 이러한 가이드를 따르고 코드 리뷰가 엄격한 경우, 시간이 지날수록 코드 리뷰 프로세스가 점점 더 빠르게 진행되는 경향이 있음을 알 수 있습니다. 개발자는 좋은 품질의 코드에 필요한 사항을 학습하고, 처음부터 훌륭하고 리뷰 시간이 적게 걸리는 코드 리뷰를 요청하게 됩니다. 리뷰어는 빠르게 응답하는 방법을 배우고 리뷰 프로세스에 불필요한 대기 시간을 만들지 않습니다. 그러나 리뷰 속도 개선을 위해 코드 리뷰의 표준 원칙을 어기거나 코드의 품질을 저하시켜서는 안됩니다.
긴급상황
전체 리뷰 프로세스를 빠르게 통과시키거나 코드 품질 규칙을 완화시켜야 하는 경우도 있습니다. 긴급상황에 대한 설명을 참고하고 어떤 상황이 실제로 긴급상황에 해당되는지 확인합니다.
