Code Review (우아한 Tech) 2/2

아래 링크를 보며 정리를 한 내용입니다.
https://www.youtube.com/watch?v=ssDMIcPBqUE

1편은 아래로!
https://velog.io/@leverest96/Code-Review-%EC%9A%B0%EC%95%84%ED%95%9C-Tech-12

1. 코드 리뷰의 어려움

1. 코드 리뷰는!
   • 지식 / 공학적 결정을 공유하는 기회
   • 공유를 통해 서로의 지식 / 경험을 나누며 상호 학습을 통한 역량 증대 수단
2. 코드 토의를 개인적 공격으로 받아들이지 않기
   • 생각을 글로 전달하는 것에 대한 어려움으로 오해의 위험이 크다.
   • 피드백을 조심스럽게 표현하는 것이 더 중요

2. 코드 리뷰의 기법들

2-1. 효율적인 PR 방법

• 지루한 작업은 컴퓨터로 처리
  • 컴퓨터가 할 수 있는 일을 사람이 하게 하지 말라!
    • 중복 체크 등
  • Formatting Tool
    • 정해진 format과 많이 다를 경우 별도의 commit/PR로 분리
      • 리뷰 불필요를 기술해서 리뷰를 생략할 수 있도록
  • unused import, declaration
    • Setting → Editor → Inspections에서 error가 뜨게 설정 가능
• 스타일 가이드를 통해 스타일 논쟁을 해소
  • 해결책
    • 있는 스타일 가이드를 적용해라
    • 조직의 스타일 가이드를 점진적으로 발전시켜 나가라
    • 하이브리드 접근
• PR을 올릴 때 주석 달기
  • PR을 저자가 먼저 읽어 보고
  • 리뷰어들을 위한 설명을 커멘트로 남겨서
  • 리뷰어들의 시간을 절약할 수 있게 하라
• 모두를 포함하라
  • 많은 사람들이 볼수록
    • 버그를 더 잘 찾아낸다.
    • 더 잘 하려는 경향이 있다.
• 의미있는 커밋으로 분리
• 혼자하는 PR도 의미있다!

2-2. 효율적인 리뷰 방법

• 리뷰는 즉시 시작
  • 코드 리뷰를 높은 우선순위로 선정해서 빨리 끝낼 것
    • 저자는 리뷰 종료될 때까지 대기해야한다.
  • 리뷰를 바로 시작하면 선순환된다.
    • 피드백을 줄 때는 시간을 가지고 진행해도 되지만 시작은 바로 해라.
    • 이상적으로는 수분 내에
  • 리뷰 라운드의 최대 시간은 하루
    • 우선순위 높은 업무로 1일 내 불가하면 다른 리뷰어 지정
    • 월 1회 이상 재지정을 해야한다면 속도를 줄여서 건강한 개발 관습을 유지할 수 있어야한다.
  • If if hurts, do it more often (Mark Seemann)
    • 일 2회(아침, 점심 직후) 30분 정도씩의 스탠드 미팅 시간을 확보해둔다.
      • 아침에는 그 전날, 점심은 오전의 PR
      • 따라서 PR에 변경이 적도록 노력해야한다. (4시간 안에 완료될 수 있도록)
    • 리뷰할 시간이 없다고 느낀다면 그것은 개인이 아닌 조직의 문제
      • 개인 기여로만 평가받지 않아야 PR이 시간낭비로 보이지 않는다.
  • Pull Requests vs Pair Programming : 답은 없다! (앙상블 방식도 생각해볼 것)
    • Pull Requests
      • Latency 🔻 / throughput 🔺
      • 팀의 분위기 : 내성적, 사색, 비동기
    • Pair Programming
      • Latency 🔺 / throughput 🔻
      • 팀의 분위기 : 외향적, 친밀한 개인적 상호 작용
• 고수준으로 시작, 저수준으로 내려가라
  • 리뷰 라운드에서 많은 의견(20 ~ 50)을 남길수록 저자가 당황할 위험이 커진다.
  • 초기 라운드에서는 고수준 피드백으로 제한
    • 버그, 장애, 성능, 보안 등
    • Extract Method, Composed Method, Invert-if(복잡도) 등
  • 고수준이 처리된 후 저수준 이슈를 처리
    • 설계 개선(선택적), 변수명 변경, 주석을 명확하게 하는 것 등
• 예제 코드 제공에 관대해라
  • 리뷰 중에 선물(예제 코드) 주기
    • 너무 긴 예제는 관대한 것이 아니라 억압적으로 보인다.
  • 라운드당 2~3개의 코드 예제로 제한
    • 너무 많으면 저자가 코드를 작성할 수 없다고 생각하는 신호
• 리뷰의 범위를 존중하라
  • 자주 보이는 Anti-Pattern : PR 근처의 코드를 보고 저자에게 수정을 요청
  • Rule of thumb : PR에 포함되지 않은 라인은 리뷰 범위가 아니다.
    • 단, PR이 둘러싼 코드에 영향을 미칠 때는 가능
      • 변수 명이 달라지는 경우 등
• 태그를 활용
  • [Nit] : “고치면 좋지만 아니어도 그만” 을 의미
    • 교육적인 목적, 지속적으로 기술을 연마하는 것을 돕는 목적
• 한두 등급만 코드 레벨을 올리는 것을 목표로
  • D 등급의 PR을 받으면 저자가 C나 B 등급을 받도록 도와라
    • 완전하지 않아도 충분히 좋은 코드가 되도록
    • Letter Grade
      • F : 기능적으로 틀렸거나 너무 복잡해서 정합성에 확신이 없는 상태
  • 승인을 보류하는 유일한 이유 : 수 차례의 리뷰 라운드 후에도 코드가 F 상태일 경우

2-3. 피드백 방법

1. 절대 ‘너’라고 하지 마라
   • 리뷰의 핵심 : 무엇이 코드를 나아지게 하는가
     • 누가 잘못 했는지가 아니다!
   • 저자의 방어 유발을 최소화하는 방법으로 피드백
     • 비판의 대상은 코드이지 저자가 아니다.
   • 너만 빼더라도 나아진다.
     • I Message 대화법 (행동 → 결과 → 감정) 사용
   • “~하는 것을 제안합니다.” 혹은 “~하는게 어떨까요?” : 오픈 커뮤니케이션
2. 건설적인 피드백을 하라 → 실수에서 배우고 역량을 증대하도록 동기부여한다!
   • 경쟁 유발이 아닌 팀의 생산성을 높이는 것
   • 코드 리뷰를 비판이 아닌 학습의 과정으로 인지할 것
   • 건설적이지 않을거면 말하지 말라!
3. 진정한 칭찬을 해라 → 도와주려는 팀동료라는 것을 보여준다!
   • 잘못된 부분에만 집중하지 말고 좋은 변경이 있을 때마다 칭찬해라!
4. 피드백은 명령이 아니라 요청으로 표현해라
   • 선언형으로 요청할 것 : “~ 부탁해요.”, “~할 수 있을까요?”, “~ 괜찮을까요?”
5. 의견이 아니라 원칙에 기반하여 피드백하라
   • 제안하는 변경과 변경의 이유를 모두 설명할 것
   • 단순히 보기 싫을 경우
     • 이 코드는 혼란스럽네요 → 나는 이 코드를 이해하기 어렵네요 (I Message)
6. 반복적인 패턴에 대해서 피드백을 제한하라
   • 동일한 패턴임을 식별했다면 모든 경우를 언급하지는 말라

2-4. 교착상태 시

1. 기조
   • 토론의 톤 / 라운드당 코멘트가 줄어들지 않는 경향 / 코멘트에 저항이 식별되는 등
2. 코드 리뷰의 최악의 결과가 교착상태
   • 커멘트를 반영하지 않으니 승인을 거부 저자는 커멘트 반영을 거부
3. 만나서 이야기해라! : 화상 혹은 만나서
4. 인정하거나 Escalate
   • 저수준 코드를 무심코 승인하면 SW 품질이 낮아질 수 있지만
   • 함께 일하지 않는다면 고수준의 품질을 얻을 기회가 사라진다.
5. 인정이 불가능하다면?
   • 저자에게 논의를 팀장이나 테크 리더에게 Escalation
   • 다른 리뷰어에게 할당
6. 교착상태로부터 회복
   • 상황을 관리자와 논의하라.
   • 휴식을 가지고 가능하다면 안정될 때까지 PR을 서로 보내지 마라.
   • 갈등 해결책을 학습하라.
7. 설계 리뷰를 고려하라
   • 코드 리뷰 때 설계 리뷰 때 논의되었어야 할 사항을 논쟁하는가?
   • 설계 리뷰는 있었나?
8. 아주 심각하지 않다면
   • 그냥 인정하고 좋은 관계로 동료와의 협업을 지속해라
   • Agree to disagree
9. 좋은 사례
   • PR을 작성한 사람과 짝 프로그래밍을 하며 어떻게 고치는 게 나은지 보여주고
   • Revert
   • PR을 작성한 사람이 스스로 개선할 수 있도록 기회를 준다.
     • 20분 짝 프로그래밍 / 2시간 스스로 개선을 통해 스스로 하는 법을 배운다!

1. 코드 리뷰의 목적은 비난이 아니라 배움이다.
2. 완벽한 설계가 아닌 당신이 할 수 있는 최고의 설계를 추구해야한다! : Letter Grade
3. 팀 정신을 위해 불완전한 해결책을 받아들여라.
4. 모든 설계 결함이 항상 실제로 문제가 되지는 않는다.

3. 코드 리뷰 FAQ

1. 코드리뷰 자체가 중요하기보다 공유와 코드에 대한 논의를 할 수 있는 문화가 중요하다.
2. 개발 생산성 vs 개발 품질의 트레이드오프
   • 버그 수정 비용은 개발 라이프사이클(개발, 테스트, 배포 등) 후반으로 갈수록 기하급수적으로 커진다.
   • 품질이 높으면 라이프사이클 후반으로 갈수록 시간이 절약된다.
     • 높은 품질은 “향후 추가 비용” 을 감소시킨다.
   • 따라서 TDD, Test, Refactoring, Code Review 등은 생산성을 증대 시킨다.
3. 너무 기법 / 절차에 의지하지 말아라
   • 온오프를 적절히 섞어라. (짝 프로그래밍 이후 스스로 개발하는 방법 등)
4. PR을 올릴 때 그 크기가 크다면 Commit 단위로 보라는 코멘트를 달아 둘 것
   • 하지만 웬만하면 하나의 의미 있는 단위로 짧게 올릴 것