우아한테크 세미나 - 지속가능한 SW 개발을 위한 코드리뷰

https://www.youtube.com/watch?v=ssDMIcPBqUE&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9CTech

알게 된 부분

1. unused import, declaration => error로 표시 되도록 설정
2. PR을 올릴 때 주석 달기 -> 먼저 읽어보고 설명을 커멘트로 남겨서 리뷰어의 시간 절약
3. 리뷰어를 모두 포함 시켜라
4. 의미 있는 커밋으로 분리
   1. 파일 생성부터 커밋을 분리
   2. 테스트 추가 커밋 등
5. 리뷰에 대한 룰 확보
   1. 아침 30분, 점심 이후 30분
   2. PR의 변경분이 적도록 노력
   3. 리뷰하는 것 자체의 노고를 인정 해줘야 함.
6. 리뷰의 핵심
   1. 무엇이 코드를 나아지게 하는가? 에 초점
   2. 누가 그런 아이디어를 냈는지가 아니다.
   3. 너만 빼라. 너라고 하지 않는게 좋고, 대상은 코드 그 자체다 사람이 아님.
   4. I message 대화법:
   5. ~ 하는 것을 제안 합니다. ~ 하는게 어떨까요?
      1. 리뷰대로 해도 되고, 안해도 되고 자유
      2. 오픈 커뮤니케이션을 유지 할 것
   6. 건설적인 피드백이 목적이지, 건설적으로 피드백을 줄 것이 아니라면 의미 없음.
   7. 진정한 칭찬을 써주어라
      1. 칭찬 해야 할 부분을 지정해서 쓸 것!
   8. 의견을 줄때, 제안하는 변경과 변경의 이유를 모두 설명하라
   9. 반복적인 실수 패턴에 대해서는 2~3개 정도의 예를 언급하라 - 모든 경우를 다 말할 필요 없다.
   10. 교착 상태를 적극적으로 처리 필요
       1. 만나서 이야기 하거나
       2. 설계 리뷰를 고려 하거나
       3. 아주 심각하지 않다면, 인정하고 협업 관계를 유지 하거나
   11. 짝 프로그래밍을 하면서 어떻게 고치는 게 좋은지 보여주고
       1. 20분 동안 페어 프로그래밍, 2시간 스스로 개선하도록 시간 부여
   12. 결정은 리뷰 요청자가 하는 것
       1. 할 수 있는 최고의 설계를 추구 하는 것
       2. 불완전한 해결책도 받아들이는 것도 좋음
       3. 모든 설계 결함이 꼭 장애가 되진 않음
       4. 코드 자체가 이상하게 그날 이상 할 수도 있음. -> 저자에게 개발 외적인 문제가 생겼을 수도 있다.
          QA) 리뷰어의 응답을 기다리다가 지체 되는 현상이 발생할 경우?

• 팀에서 룰을 정할 수 있다.
  • 반나절동안 리뷰가 안된다면, 리뷰어 승인 없이 배포 나가고 스스로 책임을 진다. (좋은 방법 같다.)