https://fujiharuka.github.io/google-eng-practices-ja/ja/review/reviewer/speed.html 번역

코드 리뷰 속도

왜 코드 리뷰는 빠르게 실시해야 하는가?

Google에서는 개발자의 팀이 협력하여 프로덕트를 빠르게 개발하기 위해 최적화하고 있으며 개발자 개인이 코드를 빠르게 쓰기 위한 최적화는 하지 않습니다. 개발자 개인의 스피드는 확실히 중요하지만 팀 전체의 스피드와 비교하면 동등한 중요성이 있는 것은 아닙니다.

코드 리뷰가 지체되면 여러 가지 일이 일어납니다.

1. 팀 전체의 개발 속도가 감소합니다. 물론 리뷰에 빨리 반응하지 않아도 개인적으로는 다른 일을 끝낼 수 있어요. 그러나 팀의 다른 멤버가 쓴 새로운 기능이나 오류 수정은 CL이 리뷰 대기, 재리뷰 대기 시 며칠이고 몇 주이고 지연됩니다.

2. 개발자가 코드 검토의 프로세스에 불만을 갖기 시작합니다. 리뷰어가 며칠 간격으로 밖에 회신하지 않는데 매번 CL로 큰 변경이 요구되면 개발자는 스트레스를 쌓고 개발이 어려워집니다. 흔히 있는 일인데요, 이럴 때 표현되는 불만은 리뷰어가 '너무 까다롭다'라는 것입니다. 본질적으로는 같은 변경(실제로 코드의 건강상태를 좋게 하는 변경)이라도 개발자의 갱신에 따라 리뷰어가 매회 재빠르게 답변하면 이러한 불만은 줄어들게 됩니다. 코드 검토에 관한 불만은 대부분의 경우 프로세스를 템포 좋게 진행하는 것만으로 해소합니다.

3. 코드의 건강상태가 나쁜 영향을 받습니다. 리뷰가 늦으면 최고의 성과라 할 수 없는 CL이라도 무조건 제출해도 좋다는 분위기가 개발자들 사이에 퍼집니다. 또한 리뷰 지연은 코드를 깨끗하게 하거나 리팩터링 하거나 기존 CL을 더 개선하려는 의욕을 꺾습니다.

코드 리뷰는 얼마나 서둘러야 할까?

어떤 작업에 집중적으로 몰두하고 있는 중이 아니라면 코드 리뷰 의뢰가 오면 즉시 착수해 주십시오.

코드 검토 요청에 답신할 때까지의 늦어도 1일입니다(즉 늦어도 다음날 아침 제일 먼저 답신해야 합니다).

이 가이드라인을 따르면 전형적인 CL은 (필요하면) 하루 이내에 여러 라운드에 걸쳐 리뷰가 이루어지게 됩니다.

스피드 vs 인터럽트

팀의 속도보다 개인의 속도를 존중하는 편이 효율이 좋은 경우가 있습니다. 코드를 쓰는 것과 같이 집중적으로 임해야 할 일(task) 중에는 자신의 일를 중단하고 코드를 검토해서는 안 됩니다. 연구 결과에 따르면 개발자가 인터럽트 작업 후에 원활한 개발 흐름으로 돌아가려면 오랜 시간이 걸릴 수 있습니다. 그렇기 때문에 코딩 도중에 중단이 되면 다른 개발자가 코드 검토를 다소 기다리는 것보다 결과적으로 더 많은 비용이 소요됩니다.

그보다는 일의 브레이크 포인트를 기다렸다가 리뷰 요청에 회신합시다. 예를 들어 지금 코딩이 완료되었을 때나 점심 식사 후나 미팅을 마치고 돌아왔을 때 등입니다.

재빠른 응답

코드 검토의 속도에 대해 이야기할 때, 우리의 관심은 응답 시간의 길이지 리뷰 전체가 완료되어 제출되기까지 시간이 길지는 않습니다. 이상적으로는 프로세스 전체도 단시간에 해야하지만 개개인의 응답을 빠르게 하는 것이 프로세스 전체를 단시간에 끝내는 것보다 훨씬 중요합니다.

리뷰 전체의 프로세스에 오랜 시간이 걸려도 리뷰어로부터 빠르게 응답을 받고 있으면 개발자가 '느린' 코드 리뷰에 느끼는 불만을 크게 줄일 수 있습니다.

당신이 매우 바빠서 CL의 리뷰 의뢰를 하셔도 충분한 시간을 낼 수 없는 경우, 그래도 빠르게 응답할 수 있습니다. 언제 착수할 수 있는지를 개발자에게 전달하거나 더 단시간에 응답할 수 있는 다른 리뷰어를 소개하거나 넓은 관점에서 본 초기 단계의 코멘트를 남길 수 있습니다. (주: 그러한 회신을 한다고 해도 코딩을 중단해서는 안됩니다. 일하다가 딱 좋은 브레이크 포인트 찾아서 답장주세요. )

리뷰어가 충분한 시간을 갖고 LGTM이 개인의 소감이 아니라 이 코드는 우리의 기준을 충족한다는 의미라고 할 수 있을 정도로 리뷰하는 것은 중요합니다. 동시에, 이상적으로는 개개인의 응답은 재빠르게 회신해야 합니다.

타임존에 걸친 리뷰

타임존의 차이를 다루려면 CL 작성자가 언제 사무실에 확실하게 있는지 확인하도록 하십시오.이미 집에 가버렸을지도 몰라요.그 때에는 다음날 작성자가 사무실로 돌아가기 전에 리뷰를 완료하도록 유의해 주십시오.

댓글 달린 LGTM

코드 리뷰의 속도를 높이기 위해 리뷰어가 CL에 해결되지 않은 코멘트를 남기면서도 LGTM / 승인을 주는 경우가 있습니다. 이것은 다음 중 하나에 해당하는 경우에 그렇게 해야 합니다.

• 개발자가 리뷰어가 남긴 코멘트를 나중에 착실히 대응해 준다면 리뷰어를 신뢰할 수 있을 때
• 미룬 변경이 그다지 중요하지 않고 개발자 본인이 반드시 실시할 필요가 없을 때

이들 중 어느 것이 리뷰어의 의도인지를 분명히 해두지 않으면 애매모호한 태도는 개발자를 혼란스럽게 만들 수 있습니다.

코멘트가 있는 LGTM이 가치를 발휘하는 것은 특히 개발자와 리뷰어가 다른 타임존에서 일할 때입니다. 이런 식으로 리뷰를 진행하지 않으면 개발자는 LGTM/승인을 받기 위해서는 하루 종일 기다려야 합니다.

큰 CL

보내져 온 코드 리뷰가 너무 거대해서 차분히 리뷰할 시간을 가질 수 있을지 불안할 때는 개발자에게 그 CL을 작은 CL로 분할하도록 의뢰하는 것이 자주 있는 대응책입니다. 한번에 리뷰하기 힘든 하나의 거대한 CL이 아니라 각자가 관련된 작은 CL로 분할하는 겁니다. 이것은 개발자에게 있어서는 일이 증가하지만 보통 CL로는 불가능한 작업도 아니고 리뷰어에게는 매우 도움이 됩니다.

CL이 작은 CL로 분할할 수 없는 경우, 또한 리뷰어가 곧바로 코드 전체를 리뷰할 시간이 나지 않을 때, 그래도 적어도 CL의 전체적인 설계에 관해 코멘트를 써서 보내 개발자에게 개선을 요구할 수 있습니다. 언제든지 말할 수 있지만 리뷰어로서의 목표 중 하나는 개발자가 작업을 지체하지 않도록 하는 것, 혹은 다음 액션을 즉시 일으킬 수 있는 상태로 두는 것입니다.물론 코드의 건강 상태를 더 이상 희생해서는 안 됩니다만.

코드 리뷰를 장기적으로 개선하다

귀하가 이 가이드라인에 준거하여 코드 검토를 엄밀히 해 나가면 전체적인 코드 검토 과정이 시간을 두고 점점 빨라지는 것을 알 수 있을 것입니다. 개발자들은 건강한 코드를 쓰기 위해 무엇이 필요한지를 배우고 처음부터 질 높은 CL을 보내게 되며 리뷰에 필요한 시간은 점점 줄어듭니다. 리뷰어는 빠르게 응답하는 법을 배우고 리뷰 프로세스에 불필요한 지연이 없어집니다. 그래도 코드 검토 기준에 타협하지 마세요. 스피드를 올려도 코드의 품질의 개선에 타협하지 말아 주세요. 장기적으로 보면 리뷰가 단시간에 끝났다고 해서 그것만으로 한 몫 한 것은 아니니까요.

긴급 사태

비상 사태라는 것도 있습니다. 비상사태 CL은 모든 리뷰 프로세스를 빠르게 끝내야 하며 품질에 대한 가이드라인은 느슨하게 만들 수 있습니다. 하지만 어떤 상황이 긴급사태에 해당하는지, 반대로 어떤 상황이 긴급사태에 해당하지 않는지를 판단하기 위해 무엇이 긴급사태인지 확인하세요.