Speed of Code Reviews

본 문서는 google code review guide를 보고 요약한 글 입니다.

1. 왜 코드 리뷰는 빨라야 하는가? (Why Should Code Reviews Be Fast?)

Google은 각각의 개발자가 코드를 작성할 수 있는 속도를 최적화하는 대신, 개발자 팀이 제품을 함께 생산할 수 있는 속도를 최적화합니다. 개별 개발의 속도도 중요하지만, 팀 전체의 속도만큼 중요하지는 않습니다.

코드 리뷰가 느리다면 몇 가지 일이 발생합니다.

1. 팀 전체의 속도가 감소합니다.
2. 리뷰에 빠르게 응답하지 않는 각 개발자들은 다른 작업을 수행할 수 있지만, 나머지 팀의 새로운 기능 추가 및 버그수정이 지연됩니다.
3. 개발자들이 코드 리뷰 프로세스에 항의하기 시작합니다.
4. 리뷰어가 며칠에 한 번씩 응답하면서 CL에 대한 주요 변경을 요청하는 경우 개발자들의 불만이 생길 수 있습니다. 반면에, 리뷰어가 동일한 요청을 하지만 코드 작성자가 업데이트 할 때 마다 신속하게 응답하면 불만이 사라지는 경향이 있습니다. 코드 리뷰 프로세스에 대한 대부분의 불만은 프로세스의 속도를 높이면 해결됩니다.
5. 코드베이스에 영향을 줄 수 있습니다.
6. 리뷰가 느리면, 개발자 가능한 좋지 않은 수준의 CL을 제출해야 한다는 압력이 가중됩니다. 또한 느린 리뷰는 코드 정리, refactoring 및 기존 CL의 추가 개선도 나쁜 영향을 받습니다.

2. 코드 리뷰는 얼마나 빨리 해야하는가? (How Fast Should Code Reviews Be?)

만약 개발자가 중요한 과제를 수행중이 아니라면(not in the middle of a focused task), 리뷰 요청이 들어온 직후에 리뷰를 시작 해야합니다.

영업일 기준 1일은 리뷰 요청에 응답하는데에 걸리는 최대 시간입니다. 즉, 다음날 아침에 가장 먼저 해야합니다.

이 지침을 준수한다는 것은 일반적인 CL이 필요한경우 하루에 여러번 리뷰를 받아야한다는 것을 의미합니다.

3. 속도 vs 중단 (Speed vs. Interruption)

개인의 속도에 대한 고려가 팀 속도보다 우선시되는 경우가 있습니다. 만약 당신이 코드 작성과 같이 집중적인 작업을 하는 중(in the middle of a focused task)이라면, 리뷰를 위해 자기 자신을 방해하지마세요.

한 연구에 따르면 개발자가 개발 흐름을 놓쳤다가, 다시 그 흐름으로 돌아오는데에 시간이 오래걸릴수도 있습니다. 따라서 코딩하고있는 개발자를 방해하는 것은 다른 개발자가 리뷰를 기다리게 만드는 것 보다 비싼 비용이 소모됩니다.

대신 리뷰를 하기 전에 개발자 자신의 업무가 중단되는 시점을 기다립니다. 이 시점은 코딩 작업이 완료될 때, 점심식사 후에, 회의가 끝나고, 차 한잔을 마시고 돌아오는 것 등이 될 수 있습니다.

4. 빠른 응답 (Fast Responses)

코드 리뷰의 속도는 전체 리뷰를 통과하고 CL이 merge되는데 걸리는 시간이 아니라, 응답 시간이 중요합니다. 전체 과정도 빨라야 하지만, 전체 과정이 빠르게 일어나는 것 보다 개별적인 반응이 빨리오는 것이 훨씬 더 중요 합니다.

전체 리뷰 프로세스를 완료하는데 시간이 오래 걸리더라도, 리뷰어의 응답을 빠르게 받으면 코드 작성자가 느린 코드 리뷰로 느낄 수 있는 좌절감을 크게 완화시킵니다.

만약 당신이 너무 바빠서 CL에 대해 완전한 리뷰를 할 수 없다면 다음과 같은 선택을 할 수도 있습니다.

1. 코드 작성자에게 당신이 언제 리뷰할 수 있는지 알려주기.
2. 빠르게 응답할 수 있는 다른 리뷰어를 제안하기.
3. CL에 대해 전체적인 의견을 제공하기. 물론, 이 선택들은 업무가 중단되는 시점에 수행되어야 합니다.

리뷰어들은 “LGTM”이 “이 코드는 우리의 표준에 부합한다”는 것을 확실히 하기 위해 충분한 시간을 소비해야합니다. 하지만 개인의 대응은 여전히 빨라야 합니다.

5. Cross-Time-Zone Reviews

시간대가 다른 경우, 사무실에 있을 때 코드 작성자(author)에게 다시 연락합니다. 이미 코드 작성자가 집으로 돌아간 경우, 다음날 코드 작성자가 사무실로 돌아가기 전에 당신의 리뷰가 완료되었는지 확인힙니다.

6. 의견이 있는 LGTM (LGTM With Comments)

코드 리뷰 속도를 높이기 위해, 리뷰어가 CL에 해결되지 못한 부분의 의견(comment)을 남기면서 승인을 해야하는 상황이 있습니다.

• 코드 작성자가 남긴 의견을 적절히 처리할 것이라고 확신할 수 있을때.
• 사소한 부분이며 코드 작성자가 반드시 수행할 필요가 없을때.

명확하지 않은경우, 리뷰어는 자신이 위의 선택지중 어떤 것을 의도하는지 명시해야합니다.

LGTM With Comments는 코드 작성자와 리뷰어가 서로 다른 시간대에 있을때 고려할 가치가 있습니다. 만약 그렇지 않을 경우 코드 작성자는 “LGTM, Approval”을 얻기 위해 하루 종일 기다릴 것입니다.

7. 큰 CL (Large CLs)

만약 누군가가 당신에게 너무 큰 크기의 코드 리뷰를 요청했는데 그것을 언제 검토할 수 있을지 확신할 수 없다면, CL을 나누어 다시 리뷰를 요청하도록 해야합니다. 이는 코드 작성자에게 추가 작업이 필요하지만 리뷰어에게는 일반적으로 매우 유용한 방법입니다.

CL을 더 작은 크기로 나눌 수 없고 전체 내용을 신속하게 리뷰할 시간이 없다면, 최소한 CL의 전체 설계에 대한 의견을 코드 작성자에게 보내 개선을 요청합니다. 리뷰어의 목표 중 하나는 코드 작성자의 interrupt된 상황을 해결하고(should be always unblock the developer), 코드의 상태를 희생하지 않으면서도 신속하게 추가 조치를 취할 수 있도록 만드는 것입니다.

8. 시간 경과에 따른 코드 리뷰 개선 (Code Review Improvements Over Time)

이 지침을 따르고 코드 리뷰가 엄격한 경우, 전체 코드 리뷰 프로세스가 시간이 경과함에 따라 점점 더 빨라지는 경향이 있습니다. 개발자는 정상적인 코드에 필요한 사항을 배우고 처음부터 훌륭한 CL의 리뷰를 요청함으로 리뷰 시간이 단축됩니다. 리뷰어는 리뷰 프로세스에 불필요한 대기 시간을 쓰지 않고 신속하게 응답하는 방법을 배우게 됩니다.

하지만 리뷰 속도 향상을 위해 코드 리뷰의 기준이나 품질을 타협하면 안됩니다.

9. 긴급상황 (Emergencies)

CL이 전체 리뷰 프로세스를 매우 빠르게 통과해야하는 경우 품질 가이드 라인이 완화되기도 합니다.