코드 리뷰, 그 냉정과 열정 사이 (4) - 코드 리뷰의 종류

  오늘은 회사에서 수행하는 코드 리뷰의 종류에 대해서 생각해 보려 한다.

  하기 블로그에 코드 리뷰의 기법들에 대해서 잘 분류/소개가 되어 있다.

조대협의 블로그 - 코드리뷰 기법

  또한 하기 링크를 통해 smartbear사에서 공짜로 배포하는 code review에 대한 ebook도 다운받을 수 있다. 코드 리뷰의 방법과 절차에 대해서 정리가 잘 되어 있으므로 한번 읽어보기를 권한다.

best kept secrets of code review

  일단 우리 회사는 메인라인에 코드 반영시 반드시 코드 리뷰를 받도록 되어있다. 또한 코드 리뷰를 받으면 하기 내용들이 적힌 문서를 코드와 함께 업데이트 하도록 되어있다.

(1) 리뷰 받은 코드의 버전
(2) 리뷰시에 나온 코멘트들
(3) 코멘트에 따른 action item이 있을 경우, 해당 action item의 시작/마감일 및 action item이 반영된 코드의 버전
(4) 체크 사항 (주로 코딩 컨벤션 (coding convention) 관련된 항목들)

  별거아닌 변경 사항에도 항상 코드 리뷰 받고, 문서를 작성해야 하니 약간의 불편함이 느껴지지만, 이런 활동들이 코드의 품질과 코드 변경점에 대한 traceability를 높여주기 때문에 필요한 활동들이라고 느껴진다.

 일단 내가 코드 리뷰를 받는 형식은 2가지로 나뉜다.

(1) minor change의 경우, 기능팀 리더에게 노트북을 들고 찾아가서 변경 사항에 대해서 간략히 설명하며 코드 리뷰를 받는다. 상기 블로그에서 언급한 Peer review의 형태이다. (사실 우리 기능팀의 한국 사람이 나+기능팀 리더 2명 뿐이라, on-site 리뷰를 해줄 사람이 기능팀 리더밖에 없다. 나머지 4명은 인도 개발자들 ㅜㅜ)

(2) major change의 경우, 기능팀 리더와 아키텍쳐 및 major change에 관련된 개발 담당자들을 초대하여 코드 리뷰를 한다. 이 경우 상기 블로그에서 언급한 팀 리뷰 + 워크 쓰루를 혼합한 정도로 진행한다. 물론 블로그의 팀리뷰 방법에서 설명한 역할인 모더레이터 (moderator)나 저작자 (author)를 나누지 않고, 저작자인 내가 모더레이터의 역할도 함께 수행한다. 물론 코드 리뷰 시에 나온 모든 코멘트들은 문서로 작성하며, 코드와 함께 반영한다.

  또한 시점상으로 "이미 양산에 들어간 SW"에 반영해야 하는 코드가 있는 경우, 기능팀 리더와 아키텍쳐를 초대하여 코드 리뷰를 자세히 받는다. 변경된 코드에 의해서 새로운 문제가 만들어질 수 도 있기 때문에 양산 이후의 변경 사항에 대해서는 항상 신중을 기한다.

  코드 리뷰의 종류에 대해서 찾아보는 동안, 상기 블로그에 나온 것 처럼 정기적인 코드 리뷰를 하면 좋겠다는 생각이 들었다. 정기적인 코드 리뷰를 통해서 기존에 작성된 코드들을 점진적으로 개선해 나갈 수 있겠다는 생각이 들었다. 정기적인 코드 리뷰를 한번 시도해 볼까 고민 중이다.