승돌 쓰다

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

seungdols 2022. 4. 28. 09:23

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) 리뷰어의 응답을 기다리다가 지체 되는 현상이 발생할 경우?
  • 팀에서 룰을 정할 수 있다.
    • 반나절동안 리뷰가 안된다면, 리뷰어 승인 없이 배포 나가고 스스로 책임을 진다. (좋은 방법 같다.)
반응형
1 2 3 4 5 6 7 8 9 ··· 798