이번 글은 코드 리뷰 적용기이다.
어떻게 해서 적용하게 되었고, 어떻게 적용했는지에 대해 적어보려 한다.
📝 도입 배경
git에 대해서 잘 모르고, 사용법이 익숙치 않을 때는, git은 그저 나의 완성된 코드를 공유하는 정도였다.
웹 프로젝트를 진행할 때 소규모 프로젝트라면
간단하게 github, gitlab을 통해서 서로 만의 규약을 가지고 개발을 하거나
zip으로 묶어서 프로젝트를 관리하기도 한다.
이번 프로젝트를 6명이서, 백엔드 3명과 프론트엔드 3명으로 나뉘어서 프로젝트를 진행하게 되면서
서로의 역할이 생기며, 그 역할로 인해 서로 분리되어 무엇을 하는지를 잘 모르게 되고 관리가 어려워질 것으로 생각했다.
첫 프로젝트를 진행하다 보니, 서로 개발에 대해 미숙하였기에
이런 부분들을 보완하기 위한 방법으로 코드 리뷰를 선택하게 되었다,
코드 리뷰에 대해서는 공통시스템개발팀 코드 리뷰 문화 개선 이야기 라는 제목으로
우아한 기술 블로그에 잘 나와 있었기에 도입하는 것은 어렵지 않았다.
해당 글을 요약하자면 MR 템플릿, 알람, 라벨링, 규칙 등을 통해 이를 정의해서 체계화 및 일관화를 시켜서 좀 더 편하게 관리한다는 내용이다.
빠르게 진행되는 SSAFY 프로젝트 일정상 현실적으로 모든 것들을 적용시키기는 어려웠고
MR 템플릿과 리뷰어 규칙만을 적용하기로 하였다.
🔍 도입을 위한 준비
SSAFY에서는 gitlab을 통해 프로젝트를 관리한다.
도입을 위해서는 템플릿 준비, 리뷰어 선정, 리뷰어 규칙을 정해야 했다.
템플릿
템플릿은 크게 feat과 fix로 나누었다.
feat
# 새롭게 개발한 기능이 무엇인가요?
*
# 자신이나 다른 사람이 알아두어야 할 특이사항이 있나요?
*fix
# 해결하려는 문제가 무엇인가요?
*
# 어떻게 해결했나요?
* 위와 같이 markdown 형식으로 파일을 만들어
해당 gitlab 저장소의 .gitlab 폴더안에 merge_request_templates 폴더를 만들어서 넣어두면
템플릿 준비는 끝난다.
💻 실제 도입
실제 도입을 통해 우리 팀이 사용했던 장면들을 이미지로 첨부하여 설명하려고 한다.
merge request 생성
merge request를 통해 새로운 merge request를 생성하려고 하면 아래와 같이 default 템플릿이 선택된다.
선택된 템플릿 외의 템플릿을 사용하려면 Choose a templete을 클릭하여 아래와 같이 변경을 하면 된다.
이후 내용을 작성 한 뒤에 사전에 선정했던 리뷰어를 선택한 뒤에 merge request를 생성하면 된다.
deafult 템플릿 지정을 위해서는 default.md로 만들어 두면 된다.
우리는 fix 템플릿을 default로 지정하였다.
리뷰어 선정
리뷰어 선정은 먼저 프론트와 백엔드를 나누었고,
그 안에서는 어떤 한 명을 메인으로 두지 않고, 꼬리물기 형식으로 서로가 서로를 리뷰하기로 하였다.
이후 프론트와 백엔드를 합칠 때는 각각의 리더가 모이거나 모두가 함께 리뷰를 진행하기로 했다.
리뷰어 규칙
리뷰어 규칙은 크게 P1부터 P5까지 있는데, P1에서 P5로 숫자가 높아질수록 우선 순위가 낮아진다.
뱅크 샐러드 블로그를 참고하였기 때문에 자세하게 각 규칙에 대한 설명을 읽을 수 있다.
P1: 꼭 반영해 주세요 (Request changes)
P2: 적극적으로 고려해 주세요 (Request changes)
P3: 웬만하면 반영해 주세요 (Comment)
P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
P5: 그냥 사소한 의견입니다 (Approve)이제 실제 적용을 위한 준비는 모두 끝이 났다.
merge request 리뷰
mr이 생성되면 리뷰어로 선정된 사용자에게 알림이 가고
해당 사용자는 알림을 통해 확인하거나 merge request 란에서 확인 가능하다.
그 다음엔 리뷰어는 앞서 정했던 리뷰어 규칙을 통해 코드 리뷰를 진행하면 된다.
리뷰어가 리뷰를 하고 나면
리뷰이는 해당 리뷰를 확인하고, 변경 사항이 있으면 변경한 뒤에 체크 버튼을 통해 이를 체크한다.
그 다음엔 리뷰어는 본인이 리뷰한 부분들을 재확인하여 변경 사항에 대해 확인한 뒤에
approve & merge를 하여 정상적인 하나의 사이클이 돌아가게 된다.
위의 포스팅에서 언급하지 않은 최소 approve 수 및 작성자 자체 approve 금지와 같은 설정들은
gitlab 공식문서를 통해 확인 및 추가 설정이 가능하다.
느낀점
시작은 호기롭게 했지만, 막상 적용하고 보니 여러 단계를 거쳐야 했고 생각보다 귀찮은 점이 한 두개가 아니였다.
하지만 혼자서 진행하는 프로젝트가 아니고 여러 사람이 협업해서 진행하는 프로젝트이다 보니
이런 점들을 감수해서 진행했고, 익숙해지다 보니 내가 개발을 하며 놓칠 수 있는 부분들에 대해서
코드 리뷰를 통해서 알게 되고, 다른 사람들의 코드를 보며 여러 시각들을 가질 수 있게 되어서
좋은 경험이었던 것 같다.
심화 적용까진 하지 않더라도 가볍게 적용하는 것만으로도 여러 장점들이 부각되는 것 같다.
