정보실

웹학교

정보실

기타 코드 검토를 수행하는 방법 - Google의 엔지니어링 사례 문서 4

본문

코드 검토 속도 


왜 코드 리뷰가 빨라야 합니까? 


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


https://google.github.io/eng-practices/review/reviewer/speed.html 


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

  • 팀 전체의 속도가 감소합니다. 예, 검토에 빠르게 응답하지 않는 개인은 다른 작업을 수행합니다. 그러나 각 CL이 검토 및 재검토를 기다리는 동안 나머지 팀의 새로운 기능 및 버그 수정이 며칠, 몇 주 또는 몇 달씩 지연됩니다.
  • 개발자는 코드 검토 프로세스에 항의하기 시작합니다. 검토자가 며칠에 한 번만 응답하지만 매번 CL에 대한 주요 변경을 요청하는 경우 개발자에게는 실망스럽고 어려울 수 있습니다. 종종 이것은 검토자가 얼마나“엄격한”지에 대한 불만으로 표현됩니다. 검토자가 동일한 실질적인 변경 (실제로 코드 상태를 향상 시키는 변경)을 요청하지만 개발자가 업데이트 할 때마다 신속하게 응답하면 불만이 사라지는 경향이 있습니다. 코드 검토 프로세스에 대한 대부분의 불만은 실제로 프로세스 속도를 높여서 해결됩니다.
  • 코드 상태에 영향을 줄 수 있습니다. 리뷰가 느리면 개발자가 자신이 할 수 있는 수준이 아닌 CL을 제출하도록 압력이 가중됩니다. 느린 검토는 또한 코드 정리, 리팩토링 및 기존 CL의 추가 개선을 권장하지 않습니다.

코드 리뷰는 얼마나 빠릅니까? 


집중된 작업을 수행하지 않는 경우 코드 검토가 시작된 직후에 수행해야 합니다.


영업일 기준 1 일은 코드 검토 요청에 응답하는 데 걸리는 최대 시간입니다 (즉, 다음 날 아침에 가장 먼저 하는 것).


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


속도 대 중단 


개인 속도에 대한 고려가 팀 속도보다 우선하는 경우가 있습니다. 코드 작성과 같은 집중된 작업을 수행하는 동안 코드 검토를 방해하지 마십시오. 연구에 따르면 개발자가 중단 된 후 원활한 개발 흐름으로 돌아 오는 데 시간이 오래 걸릴 수 있습니다. 따라서 코딩하는 동안 자신을 방해하는 것은 다른 개발자가 코드 검토를 조금 기다리게 만드는 것보다 실제로 팀에게 더 비쌉니다.


대신 검토 요청에 응답하기 전에 작업 중단 점을 기다리십시오. 현재 코딩 작업이 완료된 후, 점심 식사 후, 회의에서 돌아 오거나, 마이크로 주방에서 돌아 오는 등일 수 있습니다.


빠른 응답 


코드 검토 속도에 대해 이야기 할 때 전체 검토를 통과하고 제출하는 데 CL이 걸리는 시간이 아니라, 응답 시간이 중요합니다. 전체 프로세스도 빠르고 이상적이어야 하지만 전체 프로세스가 빠르게 진행되는 것보다 개별 응답이 빨리 오는 것이 더 중요합니다.


전체 검토 프로세스를 완료하는 데 시간이 오래 걸리더라도 프로세스 전체에서 검토 자의 빠른 응답을 받으면 개발자가 "느린"코드 검토로 느낄 수 있는 좌절감을 크게 완화 시킵니다.


CL이 들어 왔을 때 전체 검토를 수행하기에 너무 바쁘더라도 개발자에게 언제 도착했는지 알려주는 빠른 응답을 보내거나 더 빨리 응답 할 수 있는 다른 검토 자에게 제안하거나 초기에 광범위한 의견을 제공합니다. (참고 :이 중 어느 것도 이와 같은 응답을 보내더라도 코딩을 중단해서는 안됩니다. 작업의 적절한 중단 점에서 응답을 보내십시오.)


"LGTM"이 "이 코드는 우리의 표준을 충족 함"을 의미한다는 것을 검토 자들이 검토하는 데 충분한 시간을 소비하는 것이 중요합니다. 그러나 개별 응답은 여전히 ​​이상적이어야 합니다.


교차 시간 영역 리뷰 


시간대 차이를 처리 할 때는 여전히 사무실에 있을 때 작성자에게 다시 연락하십시오. 이미 집에 돌아간 경우 다음 날 사무실로 돌아 가기 전에 검토가 완료되었는지 확인하십시오.


의견이 있는 LGTM 


코드 검토 속도를 높이기 위해 검토자가 CL에 대한 미해결 의견을 남기더라도 LGTM / 승인을 제공해야 하는 특정 상황이 있습니다. 다음 중 하나 일 때 수행됩니다.

  • 검토자는 개발자가 모든 검토 자의 나머지 의견을 적절하게 처리 할 것이라고 확신합니다.
  • 나머지 변경은 사소한 것이며 개발자가 수행 할 필요는 없습니다.

명확하지 않은 경우 검토자는 이러한 옵션 중 원하는 옵션을 지정해야 합니다.


LGTM With Comments는 개발자와 검토자가 서로 다른 시간대에 있는 경우 고려할 가치가 있으며 그렇지 않은 경우 개발자는 "LGTM, 승인"을 받기 위해 하루 종일 기다릴 것입니다.


큰 CL 


누군가가 너무 큰 코드 검토를 보내면 검토 할 시간이 언제인지 잘 모르겠습니다. 일반적인 응답은 개발자에게 CL을 서로 구축하는 여러 개의 작은 CL로 나누도록 요청하는 것입니다. , 한 번에 모두 검토해야 하는 하나의 거대한 CL 대신. 이는 개발자의 추가 작업이 필요하더라도 일반적으로 가능하며 검토 자에게 매우 유용합니다.


CL을 더 작은 CL로 나눌 수 없고 전체 내용을 신속하게 검토 할 시간이 없다면 최소한 CL의 전체 디자인에 대한 의견을 적어 개발자에게 보내 개선을 요청하십시오. 검토 자로서의 목표 중 하나는 개발자의 차단을 항상 해제하거나 코드 상태를 희생 시키지 않으면 서 추가 조치를 신속하게 수행 할 수 있도록 하는 것입니다.


시간 경과에 따른 코드 검토 개선 


이 지침을 따르고 코드 검토가 엄격한 경우 전체 코드 검토 프로세스가 시간이 지남에 따라 점점 더 빨라지는 경향이 있습니다. 개발자는 정상적인 코드에 필요한 것을 배우고 처음부터 훌륭하고 검토 시간이 적게 걸리는 CL을 보냅니다. 검토자는 신속하게 응답하는 방법을 배우고 검토 프로세스에 불필요한 대기 시간을 추가하지 않습니다. 그러나 속도 검토를 위해 코드 검토 표준이나 품질을 타협하지 마십시오. 실제로 장기적으로 더 빨리 어떤 일도 일어나지 않을 것입니다.


비상 사태 


CL이 전체 검토 프로세스를 매우 신속하게 통과해야 하는 경우와 품질 가이드 라인이 완화되는 경우가 있습니다. 그러나 긴급 상황이란 무엇입니까?를 참조하십시오. 어떤 상황이 실제로 비상 사태에 해당되는지 아닌지에 대한 설명.



  • 트위터로 보내기
  • 페이스북으로 보내기
  • 구글플러스로 보내기
  • 카카오톡으로 보내기

페이지 정보

조회 20회 ]  작성일19-09-13 11:24

웹학교