eng-practices (The CL author’s guide to getting through code review) 읽기

2913 단어 google
Google's Engineering Practices documentation 는 읽고 있기 때문에 되었기 때문에 궁금한 부분을 메모.

Writing good CL descriptions


  • 왜 바꾸었는지와 무엇을 바꾸었는지

    • First Line


  • what & 명령문 (Delete xxx instead of Deleting xxx)

    • Body is Informative


  • why
  • 단점이 있다면 쓴다
  • 배경 (bug number, benchmark, design doc, etc.)

    • Bad CL Descriptions





    Good CL Descriptions





    Review the description before submitting the CL





    소형 CLs



    Why Write Small CLs?


  • 리뷰 속도가 빨라집니다
  • 잘 보이는
  • 버그가되기 어렵다
  • 거부되었을 때 낭비가 적습니다
  • 병합하기 쉬운
  • 거대한 변경보다 디자인하기 쉽다 (지금 알 수 없다)
  • 자기 완결하고 있는 변경으로 하면, 그것이 리뷰중에서도 다른 변경을 코딩할 수 있으므로 블록 되기 어렵다
  • 롤백하기 쉬운

    • What is Small?


  • 자기 완결하고 있는 하나의 변경
  • just one thing
  • 장래의 추가를 생각하지 않고 CL만 보면 알 수 있다
  • 넣어도 움직일 수 있다
  • 이해하기 어려울 정도로 너무 작지 않다 (API를 추가한다면 그것을 사용하는 것도).

  • (결정은 없지만) 100행이라면 대개는 타당, 1파일 200행은 알지만 50파일 200행은 크다
  • 자신이 쓴 것에 관해서는 배경등 정통하고 있기 때문에, 자신이 생각하고 있는 허용 가능한 사이즈는 실제의 reviwer 가 허용 가능한 사이즈보다 커지기 쉽다 (시험에 작게 보내도 불평한다 드물다)

    • When are Large CLs Okay?


  • 파일 삭제
  • 기계적 처리

    • Separate Out Refactorings


  • 리팩토링을 기능 추가 또는 bugfix에 섞지 마십시오

    • Keep related test code in the same CL


  • 테스트 코드를 변경할 수 없습니다

    • Don’t Break the Build


  • 계속 움직이는 CL 로 한다

    • Can’t Make it Small Enough


  • 굉장히 드뭅니다.
  • 리팩토링을 먼저 할 생각
  • 매우 드뭅니다.

    How to handle reviewer comments



    Don’t Take it Personally


  • 코드에 대한 비평을 개인을 공격하고 있다고 파악하여 화내지 않는다

    • Fix the Code


  • 코드를 이해할 수 없다고 말하면 코드를 정리하고 코멘트를 넣는다.

    Think for Yourself





    Resolving Conflicts



    • Node.js에서 Google 검색 사용
    【gas】gmail 첨부 파일을 드라이브에 저장, 업데이트

    좋은 웹페이지 즐겨찾기

    개발자 우수 사이트 수집

    개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
    best100-homepage