코드리뷰(code review)의 구체적인 방안 및 적용
앞서 코드리뷰의 글을 최대한 다이어트하여 글을 적어보면
코드리뷰란?
하나의 코드를 가지고 나 이외의 사람들과 함께 의견을 나누는 것.
그렇다면 왜 코드리뷰는 왜 하는가?
- 남들에게 코드를 보여주면서 좀 더 퀄리티 높은 코드를 작성한다.
⇒ 자신의 노력과 애정을 담은 코드를 리뷰를 통해 성장 가능성 증대
- 코드에 대한 책임이 코드를 짠 혼자가 아니라 우리 모두에게 있다는 문화를 만들기 위해 한다.
책임자를 비난하는 문화를 제거 ⇒ 일하고 싶고 자유롭게 생각을 공유하는 문화로 발전.
그렇다면 우리는 지식과 경험을 나누게 되고 더 좋은 product를 만들 수 있다.
또 다른 이유로는1. 다른 사람의 잘 만들어진 코드를 보면서 배울 기회를 얻어 주니어, 시니어 개발자의 성장
2. 부재 시의 팔로업의 가능성 증대.
3. 이해 수준을 상향 평준화 하는 것.
4. 조기 버그 발견 가능성 상승.
어떻게 할 것인가
- 지라를 이용한 방식.
[1월 4쨋주 팀이름] 이렇게 pms를 생성하고 Merge Request를 날릴 때 메시지에 [1월 4쨋주 팀이름][primary key]을 붙여 git-bot이 인식하여 pms에서 볼 수 있는 시스템 구축.
2. 구체적인 체크리스트를 통해 컨벤션 구축
- 잘했으면 잘했다는 댓글, 좋아요 등 적극적인 피드백
- 자신의 스타일이 아닌 컨벤션을 통한 리뷰.
- 리뷰시 구체적이고 명시적인 피드백 제공.
- 하나의 이슈당 하나의 코드 리뷰하고 설명을 미리 적어두기.
- 리뷰는 미루지 않기. ⇒ 정하지 않고 코드마스터의 판단에 의하여 진행, 일단 시작하고 생각하기.
3. 일단 시작하기!
시작을 통해 아쉬운 점을 고쳐 나가는 방식이 훨씬 빠르다. 회의를 통해 컨벤션을 구축하고 빠르게 도입하는 방안으로 진행하기.
논점 주제
- 누구에게 리뷰를 받아야하는가?
팀원전체가 전부 리뷰어가 되는가, 해보았던 언어 위주, 직급으로, 파트별로 나뉘는가에 대한 논의.
리뷰어, 리뷰어 요청, 3명에서 4명 cc 걸기. 리뷰받는 사람이 원하는 사람을 cc 걸기. codemaster가 리뷰를 판단.
Q : 숙제 받는 느낌 ? ⇒ A : 숙제처럼 받으면 좋을 것 같다. 강제성 필요.
Q : 리뷰 받는 사람이 한정적이지 않는가? ⇒ 참조 안되도 볼수 있다.
Q : 설계에 대한 문서에 대한 공유.
건의사항 : 코드 리뷰 시간을 빼주엇으면 좋겠다.
2. 어느 정도까지의 리뷰를 받아야 하는가? (ex: 쿠폰번호 변경 등의 간단한 변경사항은 리뷰를 받아야 하는가)
- 기준이 없어야 된다고 생각. ⇒ 쿠폰 번호라도! 받기.
- 리뷰어의 수는 코드마스터가 판단해서 merge ⇒ 코드마스터는 리뷰보다는 판단 위주의 업무(재판관). 댓글상황을 통한 중재 및 진행.
- 리뷰받고 싶다면 태깅을 걸기.
3. 리뷰에 대한 설명을 어디에 기록하는가 ⇒ gitlab, 지라에도 간단하게 적어주기.
4. 개발한 단계, 릴리즈 단계 에서 컨펌을 받는가, 문제가 생겼을 때 ⇒ 논의에 대한 시점
가이드라인은 릴리즈 전이고 자신이 원할 때도 받을 수 있게, 진행.
도입한 이후에는 코드리뷰에 대한 노하우를 공유하기.
리뷰 메뉴얼
리뷰 요청자 (소스 코드를 작성한 개발자이자 리뷰어에게 리뷰를 요청하는 역할)
- 코드 리뷰가 진행되지 않은 건은 배포할 수 없다. (개발, 수정 스케일에 구분 없음)
- 리뷰 요청자는 반영하고자 하는 소스 코드에 대한 상세한 설명을
반영하고자 하는 merge request내 작성한다.
리뷰어 (리뷰 요청자로부터 리뷰 요청을 받은 이후, 소스 코드를 함께 점검하고 그 결과에 대한 피드백을 남기는 역할)
- 리뷰 요청을 받은 이후 최대한 소스 점검 및 피드백을 지원하도록 노력한다. 단, 의무로 생각할 필요는 없다. (아래 Q&A 1번 참고)
코드 마스터 (리뷰어가 남겨놓은 피드백을 보고 이후 반영에 대한 최종 판단 및 추가 피드백을 주는 역할)
3,4 명정도 피드백이면 충분할 것 같다는 것을 판단하는 역할. 추가적인 피드백.
Q&A
위 내용을 기반으로 아래 QA를 응답하였음.
Q1.
리뷰 요청자가 팀원 14명의 리뷰어(극단적인 예)에게 요청하였을 경우, 14 번의 피드백을 기다려야 반영이 가능한 것인가?
A1.
코드 마스터가 리뷰어들의 피드백을 살펴보고 반영하고자하는 소스의 스케일에 따라 판단하면 됨.
예로 작은 스케일의 반영 요청(문구 변경, 단위 변경 등)의 경우 14번의 요청 중 2건의 긍정적인 피드백이면 충분하다면 반영 단계로 넘어갈 수 있도록 처리할 수 있고,
반대로 큰 스케일의 반영 요청임에도 불구하고 2번의 요청 중 2번의 긍정적인 피드백이 왔다면 추가적으로 다른 리뷰어를 태깅하여 추가적인 코드 리뷰를 요청할 수 있음.
Q2.
그러면 책임을 함께 하자는 코드 리뷰의 취지와 맞지 않게 코드마스터에게 부담이 쏠리지 않는가?
A2.
그렇지 않다. 코드 마스터는 반영하고자 하는 소스의 스케일(리뷰 요청자의 반영 요청 내용을 보고 판단)과 리뷰어의 피드백을 고려하여 반영하기에 적합한지 판단하는 것이 주된 역할이다.
추가적으로 필요하다고 판단되면 코드 마스터 또한 코드 리뷰를 진행하여 피드백을 남길 수 있다.
선행되어야 할 todo
- repo 권한 할당
gitlab(코드가 최신화가 아님. 거의 안씀, 소스를 올리고 합치는 방식 고민 중), svn 프로젝트(svn에서 관리 중), git
각 소스 코드에 대한 이해도가 필요하다. 플랫폼이 다르기에. 어느 정도 까지 대한 리뷰를 해야 하는가.
작게 시작해서 쌓아 나가는 방식.
리스트업하기⇒ 숫자를 적어서 권한이 없는 것을 이메일, 사번 과 숫자 남겨서 권한을 부여하는 방식으로 진행.
gitlab 우선적으로 코드 리뷰 시행.
각 부문마다 어떤 프로젝트를 쓰고 있는가에 대한 정리의 필요성. 위키에 폴더를 파서 한눈에 볼 수 있게 정리.
