1. 스스로 코드 검토하기
    1. 먼저 직접 읽어보기. 코드를 처음 본다고 가정해서 읽어라.
    2. 리뷰어가 어떤 형태로 보게 될지 고려해 동일한 diff로 확인하자.
    3. 스스로가 완벽할 것이라는 가정은 비이성적
      1. 삭제를 잊어버린 디버깅 코드 등등
  2. 깔끔한 변경 목록을 준비하라
    1. 맥락을 설명하기 위한 틀을 잘 잡아야함. 리뷰어에게만 유효하게 만들 것이 아니라 파트너 팀, 멘토, 코드리뷰어 모두에게 유효해야한다.
    2. 독자에게 필요한 배경 지식을 요약해야한다!!
  3. 쉬운 작업은 자동화하라
    1. 여백 문제, 들여쓰기 등등
    2. 자동화 고려
      1. Git pre-commit 훅, 린터 등을 개발 환경에 투입해 커밋에 앞서 자동으로 필요한 작업 수행하기
  4. 코드 스스로가 질문에 답하게 만들어라.
    1. 코드 동작 방식에 대해 혼란을 표명하게 만들어서는 안된다.
    2. 나쁜 주석을 없애고 그 자리에 좋은 코드를 넣어라.
  5. 변경 영역을 좁혀라
    1. 한 가지만 하는 변경을 수행해라.
    2. 각 변경 내역이 무엇을 의미하는지 커밋으로 명확하게 나눠야 함.
    3. UI도 바꾸고 기능도 바꾸면.. 검토가 안된다.
  6. 기능 변경과 비기능 변경을 분리화라.
    1. 예시. 코드 한줄 고치고 들여쓰기도 고치면? 코드 한줄 고친곳과 들여쓰기 모두 변경점으로 기록되어 리뷰어가 변화를 확인하기 힘들어진다.
    2. 정리하면, 기능 변경과 비기능 변경을 나눠라.
    3. 순서를 정해놓는 것도 좋다.
      1. 기존 동작을 실행하기 위한 테스트 추가
      2. 테스트 코드를 유지하면서 실제 코드를 리팩토링(커밋)
      3. 실제 코드 동작을 변경한 후 여기 맞춰 테스트도 업데이트(커밋)
  7. 큰 변경 목록 분해
    1. 변경 영역을 좁혀라와 친척 관계
    2. 400행 초과해서 변경 시 검토 요청에 앞서 분해할 기회를 모색하기.
  8. 비평에 우아하게 대응하기
    1. 리뷰어가 미묘한 버그를 찾으면 감사하게 생각하기
    2. 당신, 누구누구라는 단어는 주의깊게 사용할 것
    3. XYZ 대신 ABC 라는 이름은 어떨까요? 와 같이 요청으로 하기
    4. 피드백을 받은 경우 내 개인에 대한 가치가 아닌 코드에 대한 객관적인 토론으로 취급해라
  9. 리뷰어가 틀렸을 때 침착하라.
    1. 리뷰어가 착각했다는 것은 위험 신호로 받아들여야한다.
    2. 다른사람도 동일하게 실수할 가능성이 높다,
    3. 리팩터링을 진행해야할 필요성이 있음.
  10. 명시적으로 응답 내용을 전달하라
    1. Gerrit같은 도구를 활용해 조치가 필요한 메모 단위로 확실하게 응답
    2. 메모 내용에 대해 조치를 거부하는 이유 정중하게 설명
  11. 누락된 정보 요청
    1. ex) 이 기능은 혼란스럽다.
      1. 기능이 너무 긴가? 이름이 명확하지 않나? 어떤 의미에서 말한건지 정확하게 말해야함.
      2. 어떻게 변경하면 도움이 될까요? 라는 식으로 질문하기(정중하게 의도 파악하는 질문을 연습하기)
  12. 리뷰어에게 모든 권한을 부여하라
    1. 코드에 대한 일부 결정은 개인적 취향의 문제
    2. 의견이 아니라 원칙을 놓고 토론해야 한다.
      1. 함수 하나를 함수 두개로 쪼개야합니다.. 왜요? → 객관적 증거는 없다.
    3. 리뷰어가 제안할 때, 각각이 자신의 입장을 뒷받침할 거의 비슷한 증거를 확보하고 있을 경우
      1. 리뷰어에게 넘겨라
      2. 리뷰어가 이 코드를 맑은 정신에 읽었기 때문에 더 나은 관점으로 상황 파악이 가능해진다.
  13. 검토 라운드 사이에 지연을 최소화하라
    1. 검토 단계 사이 지연이 커지면 코드 다시 읽어야되고, 토론에 대한 기억회복을 위해 피드백도 다시 읽어야 한다.

오해없는 코드 검토를 위한 표현 방법

IKEA 효과