PR 코드 리뷰 문화에 대한 고찰

• 개발자에 지대한 영향을 주는 회사의 요소는 단연코 그 회사의 PR문화라 할 수 있다.
• 이건 대부분의 개발자가 알고 있고 시행을 하고자 하지만 보통 높은 확률로 바쁘다는 이유로, 크게 도움되지 않는 다는 이유로 시행되지 않기도 한다.
• 내가 지금 있는 셀러노트도 PR문화는 그래도 나쁘지 않았고 많은 리뷰도 받고 내가 리뷰를 하며 새로 알게된 것들도 많았다. 그리고 최근 개발자 인원이 많아지면서 지금까지는 인력이 적어 어쩔 수 없었던 것들에 대해 어떻게 개선해 볼 수 있을지 정리 해보자 한다.

 

> 코드 리뷰의 목적

1. 실수를 줄이는 것
   • 아예 돌아가지 않는 실수가 있고 (오탈자 등) 개선의 여지가 명확히 보이는데 급하게 개발하며 놓치고 비효율적으로 개발하는 실수가 있다.
   • 전자는 테스트 코드나 로컬 테스트를 통해 발견할 수 있고 후자는 다른 개발자가 발견하거나 리팩토링을 하지 않는 이상 바로 배포된다면 레거시가 되어버릴 확률이 크다.
2. 변경 사항 공유
   • Enum이나 공통 함수를 새로 만들어 개발하거나 비즈니스 로직 변경 등이 있을 때 다른 개발자도 알고 있어야 하기 때문에 코드리뷰를 통해 공유한다. 특히 코드 리뷰에 required로 넣는다면 무조건 approve를 해야 merge가 되기 때문에 알 수 밖에 없다.
3. 더 좋은 코드를 만드는 것
   • 당연한 거니 Pass

 

>  리뷰 문화에 있어 걸림돌

1. 리뷰에 의한 업무 증가
   • 그냥 훑어보는것만 해선 사실 의미가 없는 코드리뷰이기 때문에 꼼꼼하게 봐야하는데 그러다 보면 시간이 길어질 수 밖에 없다.
   • 해결 방안 : 
     • 코드 리뷰 요청하는 사람은 최대한 쪼개서 해야 제대로 된 코드 리뷰 퀄리티를 보장 받을 수 있다.
     • 코드 리뷰 분산을 통해 다른 개발자에게 코드 리뷰을 일부 위임하거나 요청해서 퀄리티를 유지 할 수 있다.
     • 코드 리뷰 요청 자체를 자율적으로 판단하게 하기 (불필요하다 판단시 바로 merge.. > 이건 좀 근데 리스키하다)
2. 길어지는 리드타임
   • 리뷰가 없었다면 바로 배포 할 수 있었던 것을 리뷰를 통해 해야하고 리뷰어가 만약 바쁘고 회의를 계속 한다면 같이 길어질 수 밖에 없다.
   • 해결 방안 :
     • 코드 리뷰 받는 사람 역시 요청을 받으면 최대한 바로 리뷰를 해주고자 한다.
3. 예상할 수 없는 일정
   • 개발자마다 저마다의 개발 일정이 있을껀데 리뷰 받는 코드의 양이 많거나 중요하다면.. 그날 일정은 뜬금없이 밀리거나 할 수 밖에 없다.
   • 해결 방안 :
     • 코드 리뷰를 할 예정이 있으면 스프린트 개발 일정 공유시 리뷰어도 알 수 있게 리뷰 요청 일정을 알 수 있게 해준다.
     • 2번 문제의 해결 방안일 수도 있는데 리뷰 요청하는 사람, 요청 받는 사람 모두 일정을 확실하게 미리 알 수 있게 해준다.
       • 리뷰 요청하는 사람도 반나절 안에는 요청이 올 것이라고 예상할 수 있게 약속을 정하기
       • 리뷰 요청받는 사람도 오후에 요청이 들어올 것이라는 미리 사전에 안내를 받기
       • 리뷰 예상 시간을 리뷰 내용에 기입하여 리뷰어도 미리 마음의 준비를 할 수 있게 한다.