정보실

웹학교

정보실

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

본문

코드 검토에서 찾아야 할 것 


참고 : 이러한 각 사항을 고려할 때는 항상 표준 규범 검토를 고려해야 합니다.


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


디자인 


검토에서 다루어야 할 가장 중요한 것은 CL의 전체 설계입니다. CL에서 다양한 코드 조각의 상호 작용이 의미가 있습니까? 이 변경 사항이 코드베이스 또는 라이브러리에 속합니까? 다른 시스템과 잘 통합됩니까? 이제 이 기능을 추가하기에 좋은 시기입니까?


기능성 


이 CL이 개발자의 의도대로 작동합니까? 이 코드의 사용자에게 개발자가 의도 한 것은 무엇입니까? "사용자"는 일반적으로 최종 사용자 (변경의 영향을 받는 경우)와 개발자 (향후에 이 코드를 "사용"해야 하는 개발자)입니다.


대부분 개발자는 코드를 검토 할 때까지 올바르게 작동 할 정도로 충분히 CL을 테스트해야 합니다. 그러나 리뷰어는 여전히 엣지 케이스에 대해 생각하고, 동시성 문제를 찾고, 사용자처럼 생각하고, 코드를 읽는 것 만으로도 버그가 없는지 확인해야 합니다.


원하는 경우 검토자가 CL의 동작을 확인하는 것이 가장 중요한 시간은 UI 변경과 같이 사용자에게 영향을 미치는 시점 인 CL을 확인할 수 있습니다. 코드를 읽을 때 일부 변경 사항이 사용자에게 미치는 영향을 이해하기 어렵습니다. 이와 같은 변경을 위해 개발자가 CL에 패치를 적용하기가 너무 불편한 경우 개발자가 기능 데모를 제공하도록 할 수 있습니다.


코드 검토 중에 기능에 대해 생각하는 것이 특히 중요한 또 다른 때는 CL에 이론적으로 교착 상태 또는 경쟁 조건을 유발할 수 있는 일종의 병렬 프로그래밍이 있는지 여부입니다. 이러한 종류의 문제는 코드를 실행하여 감지하기가 매우 어렵고 일반적으로 누군가 (개발자와 검토 자 모두) 문제가 발생하지 않도록 주의 깊게 생각해야 합니다. (이는 또한 경쟁 조건 또는 교착 상태가 가능한 동시성 모델을 사용하지 않는 좋은 이유입니다. 코드 검토를 수행하거나 코드를 이해하는 것이 매우 복잡할 수 있습니다.)


복잡성 


CL이 더 복잡해야 합니까? CL의 모든 수준에서 이를 점검하십시오. 개별 라인이 너무 복잡합니까? 기능이 너무 복잡합니까? 수업이 너무 복잡합니까? "너무 복잡하다"는 것은 일반적으로 "코드 리더가 빨리 이해할 수 없음"을 의미합니다. 또한 "개발자가 이 코드를 호출하거나 수정하려고 할 때 버그가 발생할 수 있습니다"를 의미 할 수도 있습니다.


특정 유형의 복잡성은 개발자가 코드를 필요 이상으로 일반화하거나 현재 시스템에 필요하지 않은 기능을 추가 한 과도한 엔지니어링입니다. 검토 자들은 특히 과도한 엔지니어링에주의해야합니다. 개발자가 미래에 해결해야 할 것으로 추측하는 문제가 아니라 지금 해결해야 할 문제를 해결하도록 개발자를 격려하십시오. 미래의 문제는 일단 도착하면 해결되어야 하며 실제 우주에서 실제 모양과 요구 사항을 볼 수 있습니다.


테스트 


변경에 적합한 단위, 통합 또는 종단 간 테스트를 요청하십시오. 일반적으로 CL이 응급 상황을 처리하지 않는 한 프로덕션 코드와 동일한 CL에 테스트를 추가해야 합니다.


CL의 테스트가 정확하고 합리적이며 유용한 지 확인하십시오. 테스트 자체는 테스트 되지 않으며 테스트에 대한 테스트는 거의 작성하지 않습니다. 사람은 테스트가 유효한지 확인해야 합니다.


코드가 손상되면 테스트가 실제로 실패합니까? 코드가 변경되면 오 탐지가 시작됩니까? 각 테스트는 간단하고 유용한 어설션을 작성합니까? 테스트가 다른 테스트 방법간에 적절하게 분리되어 있습니까?


테스트는 유지 보수해야 하는 코드이기도 합니다. 테스트가 기본 바이너리의 일부가 아니기 때문에 테스트에서 복잡성을 받아들이지 마십시오.


명명 


개발자가 모든 것을 위해 좋은 이름을 선택 했습니까? 좋은 이름은 읽기가 어려워지지 않고 항목이 무엇인지 또는 무엇을 완전히 전달하기에 충분히 길다.


주석


개발자가 이해할 수 있는 영어로 명확한 의견을 작성 했습니까? 모든 의견이 실제로 필요한가? 일반적으로 주석은 일부 코드가 존재하는 이유를 설명 할 때 유용하며 일부 코드가 수행하는 작업을 설명해서는 안됩니다. 코드 자체가 명확하지 않은 경우 코드를 간단하게 만들어야 합니다. 몇 가지 예외가 있습니다 (정규 표현식과 복잡한 알고리즘은 예를 들어 수행 중인 작업을 설명하는 주석으로 인해 큰 도움이 되는 경우가 많습니다). 그러나 대부분 주석은 결정의 이유와 같이 코드 자체에 포함 할 수 없는 정보에 대한 것입니다.


이 CL 이전에 있었던 주석을 보는 것도 도움이 될 수 있습니다. 어쩌면 지금 제거 할 수 있는 TODO,이 변경에 대한 조언 등이 있을 수 있습니다.


주석은 클래스, 모듈 또는 함수의 문서와 다르며, 대신 코드의 목적, 사용 방법 및 사용시 동작 방식을 표현해야 합니다.


스타일 


Google에는 모든 주요 언어 및 대부분의 마이너 언어에 대한 스타일 가이드가 있습니다. CL이 적절한 스타일 가이드를 따르는 지 확인하십시오.


스타일 가이드에 없는 스타일 포인트를 향상 시키려면 주석에“Nit :”을 붙여서 개발자가 코드를 개선 할 것이지만 필수는 아니라고 생각할 수 있습니다. 개인 스타일 환경 설정 만으로 CL이 제출되는 것을 차단하지 마십시오.


CL의 작성자는 주요 변경 사항을 다른 변경 사항과 결합하여 포함해서는 안됩니다. CL에서 변경된 내용을 보기 어렵고 병합 및 롤백이 더 복잡해지며 다른 문제가 발생합니다. 예를 들어, 작성자가 전체 파일을 다시 형식화 하려면 형식 재 지정을 하나의 CL로 보내도록 한 다음 기능 변경 사항이 있는 다른 CL을 보내십시오.


문서 


CL이 사용자가 코드를 빌드, 테스트, 상호 작용 또는 릴리스하는 방법을 변경하는 경우 README, g3doc 페이지 및 생성 된 참조 문서를 포함하여 연관된 문서도 업데이트 되는지 확인하십시오. CL이 코드를 삭제하거나 더 이상 사용하지 않는 경우 문서도 삭제해야 하는지 고려하십시오. 문서가 없으면 요청하십시오.


모든 라인 


검토하도록 지정된 모든 코드 줄을 보십시오. 데이터 파일, 생성 된 코드 또는 큰 데이터 구조와 같은 일부는 때때로 스캔할 수 있지만 사람이 작성한 클래스, 함수 또는 코드 블록을 스캔 하지 않고 그 안에 무엇이 들어 있다고 가정합니다. 분명히 일부 코드는 다른 코드보다 신중하게 조사해야 합니다. 즉, 판단해야 하는 결정입니다. 그러나 적어도 모든 코드가 수행하는 작업을 이해해야 합니다.


코드를 읽기가 너무 어려워서 검토 속도가 느려지는 경우 개발자에게 이를 알리고 검토를 시도하기 전에 코드가 명확해질 때까지 기다려야 합니다. Google은 훌륭한 소프트웨어 엔지니어를 고용하며 귀하는 그 중 하나입니다. 코드를 이해하지 못하면 다른 개발자도 코드를 이해하지 못할 가능성이 큽니다. 또한 개발자에게 코드를 명확하게 요청할 때 미래 개발자가 이 코드를 이해하도록 돕고 있습니다.


코드를 이해했지만 검토의 일부를 수행 할 자격이 없다고 생각되는 경우 특히 보안, 동시성, 접근성, 국제화 등과 같은 복잡한 문제에 대해 자격을 갖춘 CL 검토자가 있는지 확인하십시오.


문맥 


CL을 광범위한 맥락에서 보는 것이 종종 도움이 됩니다. 일반적으로 코드 검토 도구는 변경되는 부품 주위에 몇 줄의 코드 만 표시합니다. 때로는 변경 내용이 실제로 의미가 있는지 전체 파일을 살펴 봐야 합니다. 예를 들어, 네 개의 새 줄만 추가되는 것을 볼 수 있지만 전체 파일을 볼 때 이 네 줄은 50 줄 방법으로 되어 있어 실제로는 더 작은 방법으로 분리해야 합니다.


시스템 전체의 맥락에서 CL을 생각하는 것도 유용합니다. 이 CL이 시스템의 코드 상태를 개선합니까? 아니면 전체 시스템을 보다 복잡하고 테스트 수준이 낮습니까? 시스템의 코드 상태를 저하 시키는 CL을 허용하지 마십시오. 대부분의 시스템은 추가되는 많은 작은 변경을 통해 복잡해 지므로 새로운 변경에서 작은 복잡성을 방지하는 것이 중요합니다.


좋은 일 


CL에서 좋은 점을 발견하면 특히 개발자가 귀하의 의견 중 하나를 크게 설명 할 때 개발자에게 알리십시오. 코드 검토는 종종 ​​실수에만 초점을 맞추지 만 모범 사례에 대한 격려와 감사를 제공해야 합니다. 멘토링 측면에서 개발자에게 자신이 잘못한 것을 말하는 것보다 옳은 일을 하는 것이 더 가치 있는 경우가 있습니다.


요약 


코드 검토를 수행 할 때 다음을 확인해야 합니다.

  • 코드는 잘 설계되었습니다.
  • 이 기능은 코드 사용자에게 좋습니다.
  • 모든 UI 변경은 합리적이고 잘 보입니다.
  • 모든 병렬 프로그래밍은 안전하게 수행됩니다.
  • 코드는 필요 이상으로 복잡하지 않습니다.
  • 개발자는 미래에 필요한 것을 구현하지 않고 현재 필요한 것을 모릅니다.
  • 코드에는 적절한 단위 테스트가 있습니다.
  • 테스트는 잘 설계되었습니다.
  • 개발자는 모든 것에 명확한 이름을 사용했습니다.
  • 의견은 명확하고 유용하며 주로 무엇 대신에 이유를 설명합니다.
  • 코드는 적절하게 문서화되어 있습니다 (일반적으로 g3doc).
  • 코드는 스타일 가이드를 따릅니다.

검토 요청을 받은 모든 코드 줄을 검토하고, 상황을 살펴보고, 코드 상태를 개선하고, 개발자가 하는 일에 대해 칭찬하십시오.



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

페이지 정보

조회 21회 ]  작성일19-09-13 11:03

웹학교