정보실

웹학교

정보실

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

본문

코드 검토 표준 


코드 검토의 기본 목적은 Google 코드베이스의 전체 코드 상태가 시간이 지남에 따라 개선되도록 하는 것입니다. 코드 검토의 모든 도구와 프로세스는 이를 위해 설계되었습니다.


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


이를 달성하기 위해서는 일련의 균형이 균형을 이루어야 합니다.


먼저 개발자는 자신의 작업을 진행할 수 있어야 합니다. 코드베이스에 대한 개선 사항을 제출하지 않으면 코드베이스는 결코 향상되지 않습니다. 또한 검토자가 변경 사항을 적용하기가 매우 어려운 경우 개발자는 향후 개선을 위해 인센티브를 받지 않습니다.


반면에 각 CL의 품질이 시간이 지남에 따라 코드베이스의 전체 코드 상태가 감소하지 않는 품질인지 확인하는 것은 검토 자의 의무입니다. 특히 팀이 시간이 많이 걸리고 목표를 달성하기 위해 지름길을 가져야 할 때 코드베이스가 시간이 지남에 따라 코드 상태가 약간 감소하여 성능이 저하되기 때문에 까다로울 수 있습니다.


또한 검토자는 검토중인 코드에 대한 소유권과 책임이 있습니다. 그들은 코드베이스가 일관성 있고 유지 관리 가능하며“코드 검토에서 찾아야 할 사항”에 언급 된 다른 모든 사항을 유지하려고 합니다.


따라서 코드 검토에서 기대하는 표준으로 다음과 같은 규칙이 적용됩니다.


일반적으로 검토자는 CL이 완벽하지 않은 경우에도 작업 중인 시스템의 전체 코드 상태를 확실히 개선하는 상태 인 경우 CL 승인을 선호해야 합니다. 


이것이 모든 코드 검토 지침 중 선임 원칙입니다.


물론 여기에는 제한이 있습니다. 예를 들어, CL이 검토자가 자신의 시스템에서 원하지 않는 기능을 추가하면 코드가 잘 설계되어 있어도 검토자는 승인을 거부 할 수 있습니다.


여기서 핵심은“완벽한”코드와 같은 것은 없으며 더 나은 코드 만 있다는 것입니다. 검토자는 승인을 받기 전에 작성자가 CL의 모든 작은 조각을 연마하도록 요구해서는 안됩니다. 오히려 검토자는 제안 된 변경의 중요성과 비교하여 앞으로 진행할 필요성의 균형을 맞추어야 합니다. 완벽을 추구하는 대신 검토자가 추구해야 할 것은 지속적인 개선입니다. 전체적으로 시스템의 유지 관리 성, 가독성 및 이해도를 향상 시키는 CL은“완벽하지”않기 때문에 며칠 또는 몇 주 동안 지연되어서는 안됩니다.


검토자는 항상 무언가 더 나은 것을 표현하는 의견을 자유롭게 남겨야 하지만, 그다지 중요하지 않은 경우에는“Nit :”과 같이 접두사를 붙여야 합니다.


참고 :이 문서의 어떤 것도 시스템의 전체 코드 상태를 확실히 악화 시키는 CL의 체크인을 정당화하는 것은 아닙니다. 그렇게 할 수 있는 유일한 시간은 긴급 상황 일 것입니다.


멘토링 


코드 검토는 개발자에게 언어, 프레임 워크 또는 일반적인 소프트웨어 디자인 원칙에 대해 새로운 것을 가르치는 중요한 기능을 할 수 있습니다. 개발자가 새로운 것을 배우는 데 도움이 되는 의견을 남기는 것이 좋습니다. 지식 공유는 시간이 지남에 따라 시스템의 코드 상태를 개선하는 데 도움이 됩니다. 의견이 순전히 교육적이지만 이 문서에 설명 된 표준을 충족시키는 데 중요하지 않은 경우에는 "Nit :"로 접두사를 지정하거나 작성자가 이 CL에서 이를 해결하는 것이 필수가 아님을 나타냅니다.


원칙 

  • 기술적 사실과 데이터는 의견과 개인 취향보다 우선합니다.
  • 스타일 문제에 대해서는 스타일 가이드가 절대 권한입니다. 스타일 가이드에 없는 순전히 스타일 포인트 (공백 등)는 개인적인 취향의 문제입니다. 스타일은 존재하는 것과 일치해야 합니다. 이전 스타일이 없는 경우 저자의 스타일을 수락하십시오.
  • 소프트웨어 디자인의 측면은 순수한 스타일 문제가 아니며 개인적인 취향에 지나지 않습니다. 그것들은 기본 원칙에 기반을 두고 있으며 단순히 개인적인 견해가 아니라 그 원칙에 근거해야 합니다. 때로는 몇 가지 유효한 옵션이 있습니다. 저자가 (데이터를 통해 또는 견고한 엔지니어링 원칙에 근거하여) 여러 접근법이 똑같이 유효한 것을 입증 할 수 있다면, 검토자는 저자의 선호를 수용해야 한다. 그렇지 않으면 소프트웨어 디자인의 표준 원칙에 따라 선택이 결정됩니다.
  • 다른 규칙이 적용되지 않으면 검토자는 시스템의 전체 코드 상태를 악화 시키지 않는 한 현재 코드베이스의 내용과 일치하도록 작성자에게 요청할 수 있습니다.

갈등 해결 


코드 검토와 상충되는 경우, 첫 번째 단계는 개발자 및 검토자가 이 문서의 내용과 CL Author 's Guide 및이 Reviewer Guide의 다른 문서를 기반으로 합의를 시도하는 것이어야 합니다.


합의에 도달하는 것이 특히 어려워지면 코드 검토 주석을 통해 충돌을 해결하려고 시도하는 대신 검토 자와 작성자 사이의 대면 회의 또는 VC를 갖는 것이 도움이 될 수 있습니다. (이렇게 하면 향후 독자를 위해 토론 결과를 CL에 대한 주석에 기록해야 합니다.)


그래도 문제가 해결되지 않으면 해결하는 가장 일반적인 방법은 이관하는 것입니다. 에스컬레이션 경로는 광범위한 팀 토론, TL 계량, 코드 관리자에게 결정 요청 또는 Eng Manager에게 도움을 요청하는 경우가 많습니다. 저자와 검토자가 합의에 도달 할 수 없으므로 CL을 둘러 보지 마십시오.



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

페이지 정보

조회 23회 ]  작성일19-09-13 10:47

웹학교