CodeReivew

코드리뷰의 도입이 힘든 이유

사례 A. 개발과정의 병목으로 여겨지는 경우

1. 언젠가는 하겠지, 실제 메인 업무는 개발이다. 의무감에 비롯됨 귀찮다. 가장 대표적 (60%)
2. 어떻게든 해보자.. 하지만 나 하나쯤이야 ㅎㅎ LGTM + 위치, 서열, 심리적 부담감(40%)
3. 지친다.. PR을 3개 째 보고 있다.. 누군가 하겠지

사례 B. 결국 그냥 Merge하세요 ㅎㅎ LGTM(looks good to me)

• 가장 독성인 경우 : 리뷰 안에 상대방에 대한 비난이나 공격이 포함되는 경우
  • @@님 습관적으로 이런 식으로 짜시던데, 옳지 않다.
  • 상황에 따라 다르다. 취향 차이의 문제이지 옳고 그름의 문제가 아니다.

결국 이러한 코드 리뷰 경험으로 인해서 팀 내 불화가 발생하고, 코드 리뷰는 종료될 가능성이 높습니다.

그렇다면 왜! 코드리뷰를 해야할까요?

제품 품질의 전반적인 상승과 보존 효과가 크다.

1. 설계. 구현, 배포 잠재 오류를 사전에 발견 할 수 있습니다.
   여러 사람이 보았기에 문제 발생 시 해결 속도가 향상되고(미리 살펴보거나, 여러 사람이 보았기에 (on Call 상황시 이 코드를 짠 개발자가 아닐 확률이 높습니다.) 내가 작성한 코드가 아니지만 리뷰를 통해서 문제 발생 시의 해결 속도가 빨라진다. → 제품 품질 전반적인 상승 효과 창출)
2. Bus Factor의 최소화
   • (Bus Factor : 프로젝트가 잘 진행되기 위한 꼭 필요한 사람의 수)
   • 이 사람을 대체할 사람이 몇명인가 하지만 이 코드를 팀 내에서 공유했기에 엔지니어 가담 가능성이 상승된다. Context Sharing을 통했기에 (문맥 공유)
3. 엔지니어링 업무의 효율화
   • 각자 다른 개인의 방식을 팀의 방식으로 합의시키는 과정
     서로 다른 코딩 convention부터 전반적인 원칙까지 점진적으로 싱크

우리 팀에 올바른 코드 리뷰 문화 정착시키기.. 어떻게 하면 좋을까요?

• 코드 리뷰를 “받는” 사람의 노력
• 코드 리뷰를 “하는” 사람의 노력
  • 결국 양쪽 모두의 노력이 필요합니다.

코드 리뷰를 받을 준비를 잘하는 것이 리뷰 자체보다 중요,

리뷰의 부담은 줄이고, 효율성은 높이고 → 누군가 하겠지.. 업무의 병목현상 해소 , Mental Set 탑재
이게 어떤 feature를 만드는건지, 이게 어떤 PR를 하려고 만드는거지?? 

1. Git을 똑바로 사용하자.
2. 리뷰 받을 준비가 된 PR을 만들자. Git 부터 똑바로 사용하자.
   • 팀 내 Branch 관리 전략 준수
     • Git-flow , Github-flow
     • branch 이름이나 컨벤션을 보고 어디서 뭘 하려고 했는지 직관적으로 알 수 있게 하자
     • hotfix 브랜치에 올라온 PR이다? → 정신차려서 봐야한다.
       • 결국 Brach만 보고서도 어떤 mental set을 통해서 이걸 중점으로 다뤄야 하는지 알 수 있다.
   • Commit Convention 지정하기
     • 하나의 작업에 하나의 Commit
     • Commit 메시지로 변경 사항 예측이 가능하게 (fix, feat, refactoring, docs 등)
       • 예) [TYPE]: SUBJECT : 직관적으로 해당 컨벤션의 Type을 보고 정할 수 있다.
         [BODY]:
       https://www.conventionalcommits.org : 이 원칙을 통해서 컨벤션을 유지해볼것
       

결국 CVS 에 대해서 높은 이해도를 바탕으로 코드리뷰의 기반이 되는 병목 현상을 최대한 제거해야 합니다.
그리고 이는 팀 내 싱크를 통해 합의 되어야 합니다.

리뷰 받을 준비가 된 PR을 만들자.
리뷰어의 시간은 소중, 당연하게 여기지 말자!

 

이를 위해서 3단계의 확인이 필요합니다. 

1. CI 파이프라인이 통과되었는가?
2. PR이 리뷰가 가능한 크기인가?
3. 적절한 리뷰어를 설정하였는가? 

CI(지속적 통합) 파이프라인 통과

개인의 코드가 팀의 코드로 인정받기 위한 최소 조건이자,
리뷰어가 굳이 보지 않아도 될 당연한 문제들을 없애주는 역활 (중 괄호 아래로 , 위로 올려요)

• Formatter, Type Checker 등 팀이 합의한 기준 통과 확인하기
  • ex)CI를 통과한 PR을 리뷰로 올린다.
• Unit Test 코드 모두 통과 확인하기
  • CI를 통해 재확인

이러한 기준을 통과한 PR을 리뷰받을 준비가 된것이다.

적당한 크기의 PR을 세팅하고 꼼꼼하게 리뷰 받자! → 중간 중간에 변경이 발생했던 부분에 대해서 소통이 있어야 할 부분이 있을 것이다. 항상 적당한 크기의 PR을 세팅해서 꼼꼼히 리뷰받아야 한다.
너무 많은 file changed 는 너무 큰 피로감.. (+162,410 -173)

리뷰어 설정을 도와주는 도구들

• 개인 별 Reviwer 지정
  함께 작업하는 팀원, 및 특정 인물에게 리뷰를 받아야 할 지 명확한 경우 사용
• Team Reviwer 지정
  개발 과정 중 특정 팀의 리뷰가 필요할 때 사용
  태그된 팀의 N명이 규칙적으로 배정되도록 설정도 가능함 (RR : 라운드 로빈)
• Branch Protection Rule
  Merge하기 위한 조건을 자동으로 판단 : PR을 날리고 N명 이상에게 리뷰를 받고
  merge 가능
• Code Owner
  특정 코드가 수정되었을 때 꼭 리뷰하여야 하는 사람 지정 가능
• 파일 혹은 디렉토리 단위로, 사람 또는 팀 지정 가능 (DevOps 등등)*

리뷰를 보내기 전에 내가 먼저 셀프 리뷰하자
코드를 작성할 때 고민했던 다른 대안, 내가 생각하는 문제점 등을 미리 전달하자
고민을 먼저 제시하여 더욱 효율적이고 풍부한 리뷰 가능

ex) index Mapping을 여기에서 저장하도록 했는데, 라이브 환경에서의 병목이 우려되긴 합니다. 좋은 방법이 있을까요?

코드 리뷰는 “코드만” 리뷰하는것이 아니다.

1. 모든 것이 리뷰의 대상이다.

코드 리뷰 이지만 코드만 리뷰하지는 않는다.

전반적인 로직 구성과 대안 검토는 당연 + 풀고자 하는 문제와 미래에 올 상황에 대한 고민 역시 함께 해야한다. (지금 우리가 어떤 Bl을 풀려고 코드를 작성했는가?)

• 코드 품질을 향상 시키는 목적을 달성시킬 수 있음.
• 내 지식은 공유하고, 책임은 서로 나눈다.

그 코드를 가장 잘 짤 수 있는 방법을 다각도에서 공유하고, 그 코드에 대한 Ownership은 공유해서 문제에 함께 대응한다. (이렇게 할 경우 이런 문제가 발생할 수도 있으니 이렇게 해보는 것은 어떠세요? 저는 이렇게 생각했었어요) 터졌으면 결국 팀 단위로 대처해야 하기에 주인의식을 갖고 상세하게 볼 수 있어야 한다.

2. 리뷰를 두려워 하지말자

Request Changes를 두려워 하면 안된다.

코드를 더 좋게 만들기 위한 의지가 있음을 서로 믿어야 하고 그렇기 때문에 솔직하게 이야기하고 건강하게 충돌하자. (내가 틀릴 수도 있다. 그건 곧 내 성장과 이어진다. 항상 적극적으로 피드백 해야한다. 나를 너무 고깝게 보시지 않을까 하고 고민하지 말것)

사람이 아닌 코드와 현상이 비판한다는 합의를 전제한다.

리뷰가 나에게 하는 인신공격이나 비난이 아님을 알고 상처받지 말자 조직 전체가 효율적으로 소통하고 더 생산적으로 일하자는 약속 (아 다음에는 이렇게 해봐야지, 아 어떻게 하면 조직이 생산적으로 일할 수 있을까 이걸 문화로 전파하려면 어떻게 하면 좋을까?, 아 조금 더 솔직하게 말하자)

3. 상대방을 존중하고 좋은 부분은 칭찬하자

칭찬은 고래도 춤추게 한다.

지적 사항이 없을 때도 괜히 찾아서 쓰려고 하지는 말자

그냥 ‘Approve’만 하면 대충 리뷰한 것 같다는 생각은 지양하자 괜히 잘 쓴 코드 다시 보고 망가뜨리는 일
조금 더 쉽게 피드백을 할 수 있다.

서로 존중하고 칭찬하는 문화를 유지하자

끈끈한 팀워크는 엔지니어링 팀에 큰 효용을 가져다주는 특성
양성 피드백은 그 개발자의 의지를 북돋아 더 나은 퍼포먼스를 내게 한다

4. 마치며

• 코드 리뷰는 ‘문화’다.
• 나 혼자해서는 안되고, 팀 전체가 그에 맞게 이해하고 움직여야만 잘 할 수 있다 그렇기에 서로 다른 팀은 서로 다른 문화를 지닌다.
• 우리 팀에 맞는 방법을 찾아서 먼저 제안해보자
• 우리 팀에 맞는 방법은 내가 제일 잘 안다. 내가 먼저 정리해서 제안하고 적극적으로 퍼뜨려보자 시간이 지나면서 성숙해지면 우리 팀만의 자랑스러운 문화가 되어 있을 것