google code review(1) - overview

기초

• 코드 리뷰 프로세스 기초

  • 작성자던 reviewer이던, 조금 막히면 직접 찾아가서 이야기하자. 그게 훨씬 효율적
    • 이렇게 합의를 봤고, 결론에 도달한 이유를 반드시 적어놓아야 한다.

• 코드 리뷰는 어느 정도까지?

  • 케이스 1: 대규모 서비스 or 서비스 준비 중 or 큰 과제 or 중요한 과제(오랫동안 사용될 경우)

    • 깐깐한 리뷰 필요
    • 주요 로직에 대해서는 unit test가 다 있어야 한다.
    • 이런저런 test를 추가해 주세요. 는 상당히 당연한 review comment 입니다.

  • 케이스 2: 실험적인 코드, 1-2명이 작업하는 코드, 향후 버려질 가능성이 높은 코드

    • code quality 보다는 속도가 더 중요하다.
    • 리뷰를 너무 깐깐하게 하면, 얻는 것보다 비용이 더 많이 들 수도 있다.
    • 리뷰를 하는 코드와, 하지 않는 코드의 repository나 directory를 완전히 분리하는 것이 좋다.

  • 케이스 1이던, 케이스 2던, 스타일 가이드는 기본적으로 따라야 합니다.

    • 일단 lint 같은 tool로 대부분의 문제는 다 걸러 내고, lint로 안 잡히는 문제는 reviewer가 comment를 줍니다.
    • 단 이 경우, 너무 style guide를 바이블처럼 따를 필요도 없고, 그래서도 안됩니다.
    • style guide를 100% 따르려고 하다보면, 너무 많은 에너지가 들 수 있다.
    • 하지만 reviewer은 style guide에 안 맞는 것이 보이면 comment를 달아 주는 것이 맞고, 작성자도 그런 comment는 다 따라 주는 것이 좋습니다.

  • 변수 함수 이름?

    • 더 나은 이름이 있으면 comment를 가감없이 줘야한다.

standard of Code review

• 가장 중요: 일반적으로 검토자들은 CL이 완벽하지 않더라도 작업 중인 시스템의 전반적인 코드 상태를 확실히 개선하는 상태에 있으면 CL을 승인하는 것을 선호해야 한다.

  • 물론 이것에는 한계가 있다.
    • 예를 들어, CL이 검토자가 원하지 않는 기능을 시스템에 추가하는 경우, 코드가 잘 설계된 경우에도 검토자는 승인을 거부할 수 있습니다.
  • 오히려 reviewer는 제안하는 변경사항의 중요성과 비교하여, 진전을 이룰 필요성을 균형 있게 고려해야 한다.
  • 완벽을 추구하는 대신에, 검토자가 추구해야 할 것은 지속적인 개선이다.

• 전체적으로 시스템의 유지보수성, 가독성 및 이해성을 향상시키는 CL은 "완벽하지 않다"는 이유로 며칠 또는 몇 주 동안 지연되어서는 안 됩니다.

• review는 언제든지, 더 나은 개선사항을 담은 comment를 자유롭게 남겨야만 한다.

  • 하지만, 그것이 그리 중요하지는 않다면, "Nit"를 표시함으로써, 변경해도 되고 무시해도 되는 커멘트라는 것을 표현하세요.

• 코드 퀼리티를 확실히 악화시키는 CL은 절대 승인해서는 안된다. (비상시를 제외하고는 그렇게 해서는 안된다.)

• 코드 리뷰는 멘토링 기능이 있다.

  • 언어, 프레임워크 또는 일반적인 소프트웨어 설계 원칙에 대해 개발자에게 새로운 것을 가르치는 중요한 기능을 가질 수 있다.
  • 개발자가 새로운 것을 배우는 데 도움이 되는 댓글을 남기는 것은 항상 괜찮다.
  • 지식 공유는 시간이 지남에 따라 시스템의 코드 상태를 개선하는 부분이다.

• 원칙

  • 기술적 사실과 데이터는 > 의견과 개인적 선호보다 우선시 되야 한다.
  • 스타일에 관해서는 스타일 가이드가 절대적인 권위이다.
    • 스타일 가이드에 없는 순수 스타일 포인트(흰색 공백 등)는 개인적인 선호도의 문제입니다.
  • 소프트웨어 디자인의 측면: 100% style issue도 아니고, 100% 개인적 선호 이슈도 아닌 경우가 대부분이다. (내용 어렵다...)
    • 하지만 그것들은 근본적인 원칙에 기초하고 있고, 단순히 개인적인 의견에 의해서가 아니라, 그러한 원칙들에 무게를 두어야 한다.
    • 때때로 몇 가지 유효한 옵션이 있습니다.
    • 저자가 (데이터를 통해 또는 확실한 엔지니어링 원칙에 기초하여) 여러 접근방식이 동일하게 유효하다는 것을 입증할 수 있는 경우, 심사자는 저자의 선호를 받아들여야 한다.
    • 그렇지 않으면 선택은 소프트웨어 설계의 표준 원칙에 의해 결정된다.

• conflict 해결하기

  • 코드 검토에 대한 충돌이 발생할 경우, 첫 번째 단계는 항상 개발자와 reviewer가 아래 문서를 기반으로 합의를 시도하는 것이어야 합니다.
    • https://google.github.io/eng-practices/review/developer/
    • https://google.github.io/eng-practices/review/reviewer/
  • 대면으로 하는 것이 경험상 좋다.
    • 토론 결과를 꼭 CL에 주석으로 기록해야 한다.
  • 위 방법으로도 해결하지 못한다면, 팀 discussion 을 하거나, Tech Leader을 참여시키거나, 등 상위 전문가에게 의견을 요청한다.