코드 리뷰 조금 이해하기

이글은

카카오스토리 팀의 코드 리뷰 도입 사례 – 코드 리뷰, 어디까지 해봤니?

라는 글을 읽고 제 맘대로 정리한 글입니다.ㅎ

 

제가 경혐한 코드 리뷰는 학생 연구원 당시 코드를 짜고서 부족하다고 느낄 때 사수에게 도움을 요청, 코드에 대한 여러 수정 사항을 말해주시면 그에 대한 의견을 나누고 고치는 것이 최대 였다.

 

팀은 문화로 코드 리뷰를 하지않았고 사실 서로간의 의견을 나누기보다 아 그렇군아 하면서 바꾸는 수준이었다. 

 

그래서 그런지 코드리뷰라는 문화에 대한 환상이 있는 것 같다.

 

 

코드 리뷰 방식과 주의점 등을 정리해볼려고 한다.

 

리뷰 없이는 머지되지 않도록 제한

• master, develop 브랜치로는 바로 푸시하지 못하도록 push 깃훅 추가
• 프로젝트를 클론할 때, 깃훅을 반드시 설치하도록 강제함

 

컨벤션 리뷰로 부터 벗어나기 위해 commit 깃훅에 린트 검사 적용하기

 

조금은 불필요한 논쟁이라고 생각했던 리뷰들 지양

• 취향의 차이 (if vs switch)
• 바꾸기도 뭐하고 안 바꾸기도 뭐한 애매한 수준의 변수명 제안
• 아주 미묘한 성능 개선 제안
• 너무 먼 미래에 대한 방어 코드

코드 리뷰가 병목 -> 브랜치 미리보기 서버

• 공유하고자 하는 브랜치를 특정 패턴의 이름으로 푸시하면, 해당 기능의 스냅샷이 배포되도록 서버를 구성함

 

주기적으로 리뷰를 독려하고 머지를 담당하는 ‘리뷰 마스터’ 제도 도입

• 리뷰 마스터는 한 주 또는 특정 주기로 쌓여있는 PR을 빨리 리뷰하도록 처리
• 개인 판단 하에 빠르게 머지 가능한 것은 머지

스펙이 큰 피처인 경우엔 피처를 분리 하여 태스크 단위의 리뷰 진행

• 피처의 큰 줄기인 feature/A 를 따고 하위 태스크를 feature/A-1, feature/A-2 로 땀
• 담당자들이 우선 1차 리뷰 진행하고 상위 피처로 pull 진행

유연한 리뷰

• 간단한 건은 한 사람도 바로 머지 가능
• 마크업 수정, 코드 변경 단위가 적고 큰 영향이 없는 건
• PR이 올라온 지 오래된 리뷰는, 빨리 머지하자라는 분위기가 만들어짐
• 개인적으로도, 이런 건은 큰 문제가 없다면 자세한 리뷰보다는 빠른 머지가 더 의미있다고 생각함
• 좋게 보면 유연해졌지만, 나쁘게 보면 좀 대충 대충 느낌도 있음
• 머지 사이클도 빨라져서, 리뷰가 병목이 되는 상황은 조금 줄어들었음
• 복합적인데, 배포 비용도 적고 주기도 짧아서, 쉽게 수정해서 배포할 수 있다는 생각이 근저에 깔려있기 때문인 듯도 함

한정적인 리뷰 시간, 각자의 리뷰 포인트를 둠

• 배포도 잦아지고 처리해야할 작업도 많아지면서, 리뷰 시간이 갈수록 줄어들음
• 코드를 다 볼 수 없으니, 중요하다고 생각되는 포인트들만 리뷰하게 됨
• 변수명이나 컨벤션 리뷰는 거의 안하게 됨
• 나는 주로 아래 항목 위주로만 리뷰함
• 예외 처리가 잘 되어 있는지 (예: 컨텐츠가 없다거나, 유효하지 않은 파라미터라거나)
• 좀 더 간결하게 작성할 수 있는 방법이 있는지
• 버그가 발생할 가능성이 있는 코드인지
• 병목이 될 가능성이 있는 코드인지
• 빌드/배포 관점에서 (이건 내가 주로 작업했던 부분이라)
• 다른 멤버들도 따로 얘기하진 않았지만, 비슷하게 각자의 포인트를 잡고 리뷰하는 듯 함
• 예) 누구는 성능 위주로, 누구는 프레임워크 위주로, 누구는 크로스브라우징 위주로, 누구는 모바일 위주로 등등

 

후기

코드 리뷰 문화의 성공은 결국 팀원 모두가 코드 리뷰가 필수적인 것으로 받아 드릴 수 있을때 가능한 것이 아닐까 라는 생각을 하게 됩니다. ㅎ

 

Reference

https://tech.kakao.com/2016/02/04/code-review/