코드 리뷰 속도

코드 리뷰는 왜 빨라야 하나?

구글에서는 개개인의 개발 속도보다는 팀의 개발 속도를 최적화한다. 코드 리뷰가 오래 걸리면 다음과 같은 일이 연쇄적으로 일어난다.

그러면 얼마나 빨라야 할까?

당신이 현재 몰입 중인 상태가 아니라면 리뷰 요청을 받자마자 한다. 업무일 기준 하루를 넘지 않는다. 다음날 출근해서 제일 먼저 처리해야할 일로 여겨라. 우리의 가이드라인을 따르면 하나의 CL은 하루에 수 차례 리뷰를 받을 수 있다.

속도 vs 방해

팀의 속도보다 개인의 속도를 우선시 할 때도 있다. 당신이 몰입하여 개발을 하고 있다면 코드 리뷰를 하기 위해 도중에 일을 멈추지 않는다. 개발자가 방해를 받으면 다시 몰입하기까지 소요되는 비용이 더 크다. 업무를 완료했거나 이미 몰입이 끝난 후인 점심시간이나 미팅 후, 혹은 휴게실에 다녀온 후에 리뷰를 한다.

신속한 답변

코드 리뷰의 속도를 결정 짓는 요인은 리뷰가 통과하기까지 걸린 총 시간이 아니라 응답 시간 이다. 물론 통과가 빠르면 이상적이긴 하지만 리뷰 메시지가 빨리 오고 가는 것이 더 중요하다. 응답이 빠르면 작성자의 불만이 줄고 프로세스가 덜 느리다고 느낀다.

지금 너무 바쁘면 언제쯤 리뷰를 시작할 예정인지 간략히 응답을 보내거나 다른 리뷰어를 추천해준다. 다시 한번 강조하지만 당신이 몰입해서 개발하고 있다면 이런 응답을 보내기 위해서도 일을 멈추지 않는다. 응답이 빠르면 좋지만 리뷰 자체는 충분한 시간을 써서 언제나 코드 품질을 보장한다.

시차 코드 리뷰

작성자가 다른 시간대에 있다면 가급적 그가 업무 중일 때 응답을 해준다. 그러지 못했다면 다음날 출근하기 전까지 응답하도록 한다.

불완전 LGTM (LGTM with Comments)

코드 리뷰 속도를 높이기 위해서 몇 개의 이슈를 남겨두고 리뷰를 통과시킬 때도 있다. 이럴때는 (1)추후 CL에는 반영을 해야하는지, 아니면 (2)필수는 아니라서 굳이 수정하지 않아도 되는지 댓글로 남겨둔다. 다른 시간대에 있는 개발자끼리 코드 리뷰를 할 때도 유용하다. 요구사항이 반영되기까지 최소 하루가 넘게 걸리기 때문이다.

거대한 CL

CL이 너무 커서 리뷰를 하기가 어렵다면 작은 CL로 분리 해달라고 요청한다. 작성자가 추가적인 일을 해야하지만 리뷰어에게 큰 도움이 되고 대부분은 분리가 가능하다. 만약에 분리하는게 불가능하거나 리뷰가 오래 걸릴 것 같으면 설계에 대한 의견이라도 빠르게 보낸다. 작성자가 최대한 빨리 코드 개선 작업을 시작하게 해주는 것이 중요하다.

점점 나아지는 코드 리뷰

가이드를 엄격하게 잘 지키면 코드 리뷰가 점점 빨라지는 걸 느낄 수 있다. 작성자들도 좀 더 기준에 부합하는 초안을 올리게 되고 리뷰어들도 신속하게 응답하기 시작한다. 하지만 어떤 상황에서도 코드 리뷰의 대원칙을 반드시 준수하고, 일시적인 속도 향상을 위해 품질을 포기하면 안된다.

긴급 상황

코드 리뷰 기준을 완화하고 신속하게 통과시켜야 하는 CL도 있다. 긴급 상황 가이드를 참고하여 어떤 경우가 해당되는지 확인 한다.

다음: 코드 리뷰에 의견 작성하는 법