이 기사는 Almost Human (마이크로 채널 공개 번호 : almosthuman2014)의 허가를 받아 재 인쇄되었으며, 다음 항목의 재 인쇄가 금지됩니다. Max Kanat-Alexander Almost Human 편집
Google은 이전에 거의 모든 프로그래밍 언어와 다양한 유형의 프로젝트를 다루는 일련의 일반 엔지니어링 실무 지침을 수립했습니다. 오늘날 Google은이 코드 검토 ( Code Review ) 사양 모음을 오픈 소스로 제공했으며, 이는 Google의 최고의 실용적인 경험 모음입니다.
프로젝트 주소 : https://github.com/google/eng-practices
오픈 소스 프로젝트 작성자 또는 다른 개발자는이 프로젝트에서 유용한 지식을 얻을 수 있으므로 Google은이 코드 사양을 오픈 소스했으며 계속 유지할 것입니다. 프로젝트에서 언급했듯이 현재 코드 검토 사양에는 주로 두 개의 독립적 인 문서가 포함됩니다.
1. 코드 검토자를위한 지침
코드 검토 표준
코드 리뷰가 달성하고자하는 것은 무엇입니까?
코드 검토에서 변경 사항 목록 탐색
코드 검토 속도
리뷰 작성 방법
코드 검토 롤백 처리
2. CL 작성자 가이드
좋은 수정 목록 설명 작성
작은 변경 목록 작성
코드 검토 자의 주석을 처리하는 방법
코드 리뷰어 가이드에는 코드 리뷰를 수행하는 가장 좋은 방법이 포함되어 있으며, 모두 장기적인 경험을 기반으로합니다. 코드 리뷰어 가이드는 원래 완전한 문서 였지만 작성자는이를 6 개 부분으로 나누어 독자가 필요에 따라 읽을 수 있도록했습니다. Change List / CL Maker 's Guide에는 개발자가 검토 결과를 빠르게 처리 할 수 있도록 코드 검토를 탐색하는 가장 좋은 방법이 포함되어 있습니다.
코드 리뷰의 기능
코드 검토의 주요 목적은 코드 기반이 항상 "정상"상태로 유지되도록하는 것입니다. 코드 검토의 모든 도구와 프로세스는이를 위해 빌드됩니다. 코드 리뷰는 체계적으로 소스 코드를 확인하고 개발 초기에 발견되지 않았던 일부 오류를 확인하여 코드 품질을 향상시킬 것입니다.
그렇다면 코드 리뷰는 무엇에 감사할까요? 일반적으로 코드 검토는 다음 평가를 완료하기를 희망합니다.
디자인 : 코드가 신중하게 디자인되고 우리 시스템에 적합합니까?
기능성 : 코드의 동작이 작성자의 의도와 일치합니까? 코드의 동작이 사용자에게 정상입니까?
복잡성 : 코드가 더 간단 할 수 있습니까? 앞으로 다른 개발자가이 코드를 더 쉽게 이해하고 사용할 수 있습니까?
테스트 : 코드가 정확하고 잘 설계된 자동 테스트를 통과 했습니까?
이름 지정 : 개발자가 변수, 클래스 및 메서드에 대해 이해하기 쉬운 이름을 선택 했습니까?
주석 : 코드 주석이 충분히 명확하고 유용합니까?
스타일 : 코드가 표준 작성 스타일을 채택합니까?
문서 : 개발자가 관련 문서를 업데이트 했습니까?
코드 리뷰에는 수많은 검사가 필요하기 때문에 우수한 리뷰어를 찾는 것이 매우 중요합니다. 일반적으로 다른 검토자는 개정 목록의 다른 부분에 대해 자세한 검토를 수행합니다. 또한 알리바바의 최신 자바 개발 매뉴얼은 공식 계정 자바 기술 스택 답장 매뉴얼을 따라 가면 얻을 수있어 매우 귀중하고 의미가있다.
물론 짝 프로그래밍이고 팀원이 고품질 코드 검토를 수행 할 수 있다면 이러한 방식으로 작성된 코드는 일반적으로 검토 된 것으로 간주 될 수 있습니다. 또한 대면 검토를 수행 할 수도 있으며 검토자는 개발자에게 몇 가지 질문을 할 것입니다.
코드 검토를위한 일반 사양
전체 코드 리뷰 가이드는 여러 모듈로 나누어 져 있으며 모두 소개 할 수는 없습니다. 따라서이 기사의 끝에서 코드 검토를 수행 할 때 Google 개발자를위한 가장 일반적인 검토 기준을 소개합니다.
Google은 예상 표준으로 다음 규칙을 사용한다고 밝혔습니다.
"일반적으로, 변경 목록이 완전하지 않더라도 변경 목록이 전체 코드의 상태를 개선 할 수 있으면 검토 자도 목록을 승인하는 경향이 있습니다."
이 규칙은 모든 코드 검토 지침의 가장 높은 원칙입니다. 예를 들어 CL이 검토 자에게 필요하지 않은 일부 기능을 추가하는 경우 코드가 신중하게 설계 되었더라도 검토자는 통과해서는 안됩니다.
여기서 핵심은 "완벽한"코드라는 개념이없고 더 나은 코드 만 있다는 것입니다. 검토자는 승인 전에 코드 작성자에게 CL의 작은 부분을 다듬을 것을 요구해서는 안됩니다.
오히려 검토자는 추가 개발 및 수정 제안의 필요성의 중요성을 평가해야합니다. 리뷰어가 요구하는 것은 완벽한 코드가 아니라 지속적인 개선입니다. CL 전체적으로 시스템의 유지 관리 성, 가독성 및 이해도를 향상시킬 수 있다면 완벽하지 않다고해서 업데이트를 며칠 또는 몇 주 동안 연기하지 마십시오.
검토자는 종종 더 나은 성과로 이어지는 관행을 표현하기 위해 의견을 남겨야합니다. 이러한 관행이 그다지 중요하지 않은 경우 코드 작성자에게 이러한 내용을 무시할 수 있음을 알리기 위해 접두사 "Nit :"를 추가해야합니다. " 2 년 코드 리뷰 실무 경험 공유! "이 권장 사항을보세요.
평가 지침
코드 검토에는 언어, 프레임 워크 또는 일반 소프트웨어 디자인 지침 등 개발자에게 개발 경험을 가르치는 매우 중요한 기능이 있습니다. 댓글을 남기면 개발자는 항상 새로운 지식을 배우는 데 도움이되며 지식을 공유하는 것도 시스템 코드의 상태를 개선하는 데 중요한 부분입니다. 물론 검토 자의 의견이 교육적 일 뿐이고 표준 요구 사항에 그다지 중요하지 않은 경우 접두사 "Nit :"를 추가해야합니다.
평가 기준
기술적 사실과 데이터는 의견과 개인적인 스타일보다 우선합니다.
코드 스타일 측면에서 Google의 코드 스타일 가이드는 가장 권위있는 참조 자료입니다. 스타일 가이드에없는 코딩 습관은 개인적인 스타일이지만 기본 스타일이 Google 스타일 가이드와 일치하는지 확인해야합니다.
Google 스타일 가이드 : http://google.github.io/styleguide/
소프트웨어 디자인에는 순수한 스타일 문제 나 순수한 개인적인 습관이 거의 없습니다. 많은 스타일 문제는 몇 가지 기본 기준을 기반으로하며 단순히 개인적인 의견에 의해 결정되는 것이 아닙니다. 또한 코드 작성자가 데이터 또는 기본 엔지니어링 원칙을 통해 여러 방법이 똑같이 효과적임을 입증하는 경우 검토자는 작성자의 스타일을 수락해야합니다. 그렇지 않으면 선호도의 선택은 여전히 소프트웨어 디자인의 표준 원칙에 달려 있습니다.
적용 가능한 다른 규칙이없는 경우 검토자는 전체 코드 상태에 영향을주지 않고 작성자의 기본 설정이 현재 코드 기반과 일치하도록 요구할 수 있습니다.
갈등 해결
코드 검토에서 충돌이 발생하는 경우 첫 번째 단계는 개발자와 검토자가이 프로젝트의 CL 지침에 따라 합의에 도달하는 것입니다. 합의에 도달하기가 매우 어려울 때 개발자와 검토자는 검토중인 댓글을 통해서만이 아니라 직접 대면해야합니다. 회의와 논의가 해결되지 않으면 회의가 확대되고 코드 관리자, 엔지니어링 관리자 및 기타 개발자와의 커뮤니케이션을 통해 최종 합의에 도달 할 수 있습니다.
위는 코드 사양의 일반적인 표준 일 뿐이며 여전히 매우 추상적입니다. 독자가 더 자세한 내용을 알고 싶다면 계속해서 프로젝트를 확인할 수 있습니다.
내 블로그에서 더 많은 것을 읽을 것을 권장합니다.
1. Java JVM, 컬렉션, 멀티 스레딩 및 새로운 기능에 대한 일련의 자습서
2. Spring MVC, Spring Boot, Spring Cloud 튜토리얼 시리즈
3. Maven, Git, Eclipse, Intellij IDEA 시리즈 도구 튜토리얼
4. Java, 백엔드, 아키텍처 및 Alibaba와 같은 주요 제조업체 의 최신 인터뷰 질문
기분이 좋습니다. + 앞으로 좋아하는 것을 잊지 마세요!
마지막으로 스택 리더의 WeChat 공식 계정에 주목하세요. Java 기술 스택, 답변 : Welfare, 제가 2020 년에 컴파일 한 최신 Java 인터뷰 질문의 무료 사본을 얻을 수 있습니다. 일상적인 작업 없이도 정말 완벽합니다 (답변 포함). 