SW 테스트 - 정적 테스트 - 코드 리뷰 (Review)

Peer Review

1. Peer Review

  1) 작업자의 동료들이 사전에 정의된 절차에 따라 수행하는 SW 검토

  2) 절차 :  계획 > 사전설명회 > 개별검토 > Review미팅 > Rework > 후속처리

2. Peer Review 역할 상세

  1) 구성요소 : 관리자, 중재자, 작성자, 검토자, 기록자, 발표자

 

Critique - 구글이 개발자 만족도 97%로 코드 리뷰의 고통을 덜어주는 방법

 

Critique’s UI, from  SWE Book

 

 

The diff view, from  Resolving Code Review Comments with ML

 

• 많은 ex-구글러들이 그리워하는 구글의 코드 리뷰 도구 "Critique"
• 구글 내부에서 조사한 결과 개발자 97%가 Critique에 만족한다고 함

구글의 코드 리뷰 가이드 라인

• 완벽함보다는 지속적인 개선을 권장
• 코드베이스의 상태 유지 또는 개선
• 스타일 가이드를 따르기
• 항상 지식을 공유하기: 코드 리뷰를 통해 언어 기능, 코드베이스 및 기타 관련 아티팩트에 대한 지식 공유 권장
• 변경 사항을 작게 작성하기(약 200줄 정도)
• 경량화에 대한 엄격한 기준(24시간 이내에 코드 변경 사항을 검토, 가급적 한 명의 검토자)
• 정중함과 전문성: 신뢰와 존중의 문화를 유지하는 것이 중요

Critique: 구글의 코드 리뷰 도구

• 엔지니어가 코드 변경 사항을 효율적으로 검토하고 제출 가능
• 최근 논문 - Resolving code review comments with ML에 의하면 포괄적인 AI 기반 코드 리뷰 도구를 사용중
  • 리뷰어가 코드에 코멘트를 남기면 Critique에서 ML 기반 편집 제안을 표시
  • 코드 리뷰 작성자는 버튼 하나만 클릭하면 해당 코멘트를 전체적으로 수정할 수 있음

코드 리뷰 흐름

• 단계 1: 변경 작성
  • CL(또는 Pull Request)는 구글의 내부 코드 편집기 Cider 에서 작성됨
  • Critique 및 기타 사내 Google 도구와 긴밀하게 통합되어 개발자 생산성을 높여줌
  • Prereview 도구: 검토 전에 변경 사항을 다듬고, 차이점, 빌드 및 테스트 결과, 스타일 확인을 표시
  • Diff 보기 및 시각화: 구문 강조 표시, 상호 참조, 인트라라인 Diffing, 공백 무시, 이동 감지 기능
  • 정적 분석기의 결과를 표시하여 중요한 결과를 강조하고 수정 제안을 제공. Critique 내에서 실행되는 자동화 테스트인 "presubmits" 를 포함
• 단계 2: 리뷰 요청
  • 풀 리퀘스트를 검토할 준비가 되면 코드 작성자는 검토자를 추가하고 공식적으로 검토를 위해 전송
  • 검토를 위해 PR/CL이 전송되면 현재 코드 스냅샷에 아직 없는 경우 "Presubmits"가 실행됨. 즉, 검토에 참여하는 모든 사람이 코드에 문제가 있는지 여부를 알 수 있음
  • 코드 리뷰를 익명화하여 코드 작성자를 검토자로부터 익명으로 유지할 수도 있음. 하지만 Google은 익명 코드 리뷰와 '실제' 코드 리뷰 간에 유용한 차이를 발견하지 못했음
• 단계 3과 4: 변경 사항을 이해하고 댓글 달기
  • 누구나 변경 사항에 댓글을 달 수 있으며, 검토 진행 상황을 추적하고 댓글을 해결할 수 있는 기능을 제공
  • 해결되지 않은 댓글은 변경 사항 작성자가 확실히 해결해야 할 작업 항목을 나타냄. 이러한 코멘트는 코드 작성자가 직접 댓글에 답장할 때 '해결됨'으로 표시 가능
  • 해결된 댓글에는 변경 작성자의 조치가 필요하지 않을 수 있는 선택 사항 또는 정보 제공 댓글이 포함
  • 검토 상태를 확인할 수 있는 대시보드와 특정 코드 검토에 참여한 사람들이 현재 대기 중인 사람이 누구인지 알 수 있는 "Attention Set"이 있음
• 단계 5: 변경 승인
  • 위에서 언급했듯이 리뷰가 등록되려면 적어도 한 명의 리뷰어로부터 LGTM(Looks Good To Me)을 받아야 함
  • 코드 작성자가 댓글을 달 때 직접 해결된 댓글로 표시할 수는 있지만 해결되지 않은 댓글이 0개여야 함
  • 또한 코드가 들어가는 코드베이스 부분의 소유자의 승인과 가독성 승인이 필요
  • 이 모든 작업은 한 명의 리뷰어가 수행할 수 있음
• 단계 6: 변경 사항 커밋하기
  • Critique 자체 내에서 변경 내용을 제출하고 커밋
  • Critique은 변경 사항이 제출된 후에도 유용함
  • "Google 연구원들은 Critique의 용도가 코드 검토 이상으로 확장된다는 강력한 증거를 발견했음. 변경 사항 작성자는 Critique을 사용하여 Diff를 검토하고 분석 도구 결과를 찾아봄. 경우에 따라 코드 검토는 변경 사항 개발 프로세스의 일부로, 검토자는 구현을 완료하는 방법을 결정하기 위해 미완성 변경 사항을 보낼 수 있음. 또한 개발자는 변경 사항이 승인된 후에도 제출된 변경 사항의 이력을 검토하기 위해 Critique을 사용함."

Google의 최신 코드 리뷰 통계

• 변경 작성 빈도:
  • 중앙값: 주당 3번 변경
  • 80%의 작성자가 매주 7건 미만으로 변경
• 리뷰 빈도:
  • 중앙값: 주당 4건의 변경 내용을 리뷰
  • 검토자의 80%는 매주 10개 미만의 변경사항을 처리
• 주당 리뷰에 소요되는 시간:
  • 평균 주당 3.2시간
  • 중앙값 주당 2.6시간
• 초기 피드백 대기 시간:
  • 작은 변경: 평균 시간 1시간 미만
  • 매우 큰 변경: 약 5시간
• 전체 리뷰 프로세스 시간:
  • 모든 코드 크기의 평균 지연 시간: 4시간 미만
  • 다른 회사와의 비교:
    • AMD: 17.5시간(승인까지 걸리는 시간 중앙값)
    • Chrome OS: 15.7시간
    • Microsoft 프로젝트: 14.7시간, 19.8시간, 18.9시간
    • Microsoft(다른 연구): 24시간

왜 Critique을 구글러들이 사랑할까?

• 정적 분석: 코드에 대한 실행 가능한 피드백을 자동으로 제공하는 모든 기능을 갖춘 정적 분석 도구 제품군을 보유. 이를 통해 코드 작성자와 검토자가 모두 시간을 절약할 수 있으며, 검토자는 뻔한 항목을 일일이 지적할 필요가 없음
• 가장 최근에 변경된 파일에만 집중: 코드의 최신 '스냅샷'에만 집중할 수 있음. 이전 스냅샷, 커밋 및 코드 변경 사항은 표시되지 않으므로 사용자 인터페이스가 더 깔끔
• 친숙한 Side-by-Side Diff 인터페이스: 기본적으로 "마지막 리뷰와의 차이점"이 표시
• 머신러닝 기반 제안: Google의 새로운 ML 기반 제안 기능으로 코드 리뷰 속도가 엄청나게 빨라짐
• 다른 Google 도구와의 긴밀한 통합: Critique은 Google의 IDE 및 버그 트래커와 같은 기타 내부 도구와 매우 잘 통합되어, 생산성이 향상됨. 여기에는 코드, 댓글, 티켓의 손쉬운 연결이 포함
• '작업 세트' 추적: 누가 다음 작업을 수행해야 하는지 알 수 있음
• 만족스러운 게임화: Critique이 게임화되도록 설계된 것은 아니지만, 구글러들은 Critique이 '녹색으로 전환'되어 PR을 제출할 준비가 되었을 때(모든 테스트 통과, 검토자 LGTM 승인) 즐거웠다고 얘기함
• 레딧에 달렸던 코멘트 들
  • 수많은 코드를 매우 효율적으로 검토할 수 있는 놀라운 키보드 단축키
  • 기본적으로 "마지막 리뷰와 다름"을 표시
  • "코드 이동 감지" 기능이 있어서 코드의 변경 사항에 집중할 수 있음
  • 리뷰어든 작성자이든 누가 조치를 취해야 하는지 알려주는 놀라운 기능을 제공
  • 크롬 확장 프로그램과 함께 사용하면 알림을 쉽게 받고 리뷰 대기열을 확인할 수 있음
  • 내부적으로 누구나 코드 리뷰 데이터에 대해 쿼리를 실행하여 인사이트를 수집할 수 있음
  • 코드와 댓글의 자동 연결(티켓 및 이동/링크 포함)
  • 여러 라운드의 코드가 포함된 PR의 진행 상황을 훨씬 쉽게 이해할 수 있도록 PR의 분석 및 내역과 코멘트를 표 형식으로 볼 수 있음
  • 선택 사항, 참고 사항 등 댓글의 용어/태그가 매우 일관적

생각과 시사점

• 이러한 기능 중 상당수는 오늘날 다른 도구에서도 사용할 수 있지만, 이 도구가 사랑받는 이유는 Google 고유의 워크플로와 코드베이스에 대한 도구의 긴밀한 통합과 극도의 '개인화' 덕분이라고 생각
• 동시에 모든 회사가 Critique 및 관련 도구를 정확히 복제하는 것은 현실적으로 불가능하다는 뜻이기도 함. 예를 들어, 일부 도구는 모노레포 구조로 인해 발생하는 문제에 특화되어 있음
• Critique 자체가 오픈소스로 제공되지는 않겠지만, Gerrit는 크리티컬과 유사한 도구. 이 역시 Google에서 만들고 유지 관리하는 오픈 소스 코드 검토 도구
• 하지만 구글은 개발자의 생산성을 위해 많은 노력과 고민을 하고 있다고 생각. 그들은 자신의 연구를 자유롭게 게시하며, 그들의 작업에서 유용한 시사점을 얻을 수 있음

 

• 코드리뷰란, 말 그대로 개발자가 작성한 코드를 다른 개발자가 리뷰(피드백)하는 과정을 말한다.
• 이 과정을 거치면 개발자는 본인이 발견치 못한 실수(오타, 버그 등)를 초기에 대응할 수 있고
• 팀 내 정해진 컨벤션 규칙을 유지하고 기술 부채를 줄일 수 있다.
• 또한, 다수의 개발자가 참여하기에 해당 코드를 다른 관점에서 보고 더 나은 해결방법을 제시할 수도 있다.
• 하지만 리뷰를 하는 과정에서 코멘트로 인해 팀원 간 감정이 상하는 경우가 발생하곤 하는데…
• 이번시간에는 더 나은 리뷰 코멘트를 위해 구글, 뱅크샐러드, 카카오, 토스랩팀의 코멘트 원칙을 살펴보았다.

https://youtu.be/xmfUSQ5L8cQ

https://www.hanbit.co.kr/channel/category/category_view.html?cms_code=CMS3858769941&cate_cd= 

LGTM이 뭐지? : 구글의 코드 리뷰 & 코드 리뷰 유형

https://blog.hwahae.co.kr/all/tech/12534

지속가능한 코드리뷰 문화를 만드는 여정 – 화해 블로그 | 기술 블로그

https://mong-blog.tistory.com/entry/Team-%EC%BD%94%EB%93%9C-%EB%A6%AC%EB%B7%B0-%EC%BD%94%EB%A9%98%ED%8A%B8%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%9E%91%EC%84%B1%ED%95%98%EB%A9%B4-%EC%A2%8B%EC%9D%84%EA%B9%8C-%EC%BD%94%EB%93%9C-%EB%A6%AC%EB%B7%B0-%EC%9B%90%EC%B9%99-%EB%93%A4%EC%97%AC%EB%B3%B4%EA%B8%B0

[Team] 코드 리뷰 코멘트는 어떻게 작성하면 좋을까? 코드 리뷰 원칙 들여보기

1. https://tech.kakao.com/2022/03/17/2022-newkrew-onboarding-codereview/
2. https://www.bloter.net/news/articleView.html?idxno=21860
3. https://www.samsungsds.com/kr/insights/global_code_review.html
4. https://google.github.io/eng-practices/
5. https://blog.banksalad.com/tech/banksalad-code-review-culture/
6. https://www.theteams.kr/teams/859/post/64467

 

https://engineercodex.substack.com/p/how-google-takes-the-pain-out-of

How Google takes the pain out of code reviews, with 97% dev satisfaction