현재 다니고 있는 회사는 개발문화가 그리 발달된(?) 편은 아닙니다.
이 회사에 오자마자 Git Flow 도 전파 시켜 세미나까지 해봤는데 내용에 대해 잘 모르고 있던 분들이 많았습니다.
Git Flow는 다음에 기회가 되면 포스팅 해보겠습니다.
코드 리뷰란?
코드 리뷰란 개발자가 작성한 코드를 다른 사람들이 검토하고 피드백을 전달하고 작성자가 리뷰를 참고하여 코드를 재반영하는 것을 말합니다.
코드 리뷰의 좋은 점?
동기 커뮤니케이션(회의, 전화)이 아닌 비동기 커뮤니케이션(Slack, jira)으로 커뮤니케이션 비용을 줄여 내 업무에 지장을 받지 않습니다.
누군가에게 보여줘야 할 코드이기 때문에 내 코드를 한번 더 검토하여 실수를 줄일 수 있습니다.
다른 사람이 읽었을 때 이해가 잘 되는 코드를 작성하기 위해 노력하는 습관을 가질 수 있습니다.
커밋 메시지와 주석, 네이밍에 신경을 쓰게 됩니다.
여기까지는 코드 리뷰란 무엇이고 왜 적용해야 하는 지 적어보았습니다.
다음은 제가 이 회사에서 코드 리뷰를 어떻게 정착 시킨지 말씀드리겠습니다.
🤔왜 도입하는 것인지?
제가 속한 팀은 좀 특이한 편입니다. 쓰는 언어가 통일되지 않기도 하고 프론트, 백엔드도 같이 있는 팀입니다. 그래서 과연 코드 리뷰를 하는 것이 맞는 것인지 굉장히 오랜 시간 고민을 했으나,
오히려 서로 다른 언어에 업무 분야도 다르지만 서로의 언어에 대해 관련 서적을 찾아볼 수 있는 기회를 가지고 서로 업무 분야에 대해 알 수 있는 시간을 가질 수 있기 때문에 팀의 구성원으로써의 정체성을 가질 수 있고 다같은 개발자끼리 쓰는 언어에 국한 되지 않고 더 나은, 더 친절한 코드를 만드는 과정을 제안함으로써 코드의 품질을 높일 수 있을 거라 기대했습니다.
✍앞으로 코드 리뷰는 어떻게 진행할 것인지?
제가 속한 팀은 각 프로젝트 담당자가 최대 한명에서 두명까지고 서로 여러 프로젝트를 담당하고 있는 팀입니다.
이러한 팀에서 코드리뷰를 어떻게 하면 효율적으로 할지 고민 끝에 아래와 같이 진행하였습니다.
저는 일단 GitLab과 Slack을 이용해서 코드 리뷰 프로세스 정책을 세웠습니다.
Slack에 기본적으로 코드리뷰만 하는 채널을 따로 만들었고 Incomming Webhooks 를 설치하여 GitLab에서 발생하는 이벤트에 대한 알림이 Slack으로 오게 만들었습니다.
아래에서 설명하는 소스 관리는 기본적으로 GitFlow 전략을 따라갑니다.
우선, Develop의 브랜치를 protected로 변경하여 push를 막았습니다.(이유와 방법은 아래에)
Master는 배포 요청자와 배포 담당자를 두어 role 구분을 명확하게 하였고 해당 코드에 대한 권한은 오로지 배포 담당자에게만 두어 해당 프로젝트에 대한 책임감을 높이도록 하였습니다.
다만, 배포 담당자는 계속 고정이 아닌 해당 업무를 하고 있는 여러 명의 담당자들이 돌아가면서 맡습니다.
Develop은 저희 팀 특성상 각 프로젝트당 최대 2명의 담당자밖에 존재하지 않기 때문에 사실 코드리뷰를 하게 되면 리뷰어가 없을 수도 혹은 1명이 될 수 밖에 없었습니다.
그래서, 저희 팀 모두가 리뷰어가 되는 방법을 택했고 그렇게 하기 위해 Develop에도 코드리뷰가 필요하게 되었습니다.
| Master | Develop | |
|---|---|---|
| Merge권한 | 배포담당자 | 본인 |
| 코드리뷰 승인 | 배포담당자 | Any(2명 제한) |
| 코드리뷰 요청 | 배포요청자 | 본인 |
아래는 코드리뷰를 받기 위한 방법을 설명 합니다.
1) 우선 담당하고 있는 GitLab Project를 들어갑니다.
2) 왼쪽 메뉴 리스트에서 Setting > Repository 를 찾습니다. 만약, Setting이 보이지 않는다면, Master 권한을 획득 해야 합니다.
3) Protect Branch를 Expand 합니다.
Branch : Develop
Allowed to merge : developers + Maintainers
Allowed to push : no one
Required approval from code owners : check 해제
4) Setting > Integrations > Slack notifications 선택
5) Merge Request만 남겨 놓고 모두 체크 해제
6) Merge Request에 Slack에서 만든 코드리뷰 채널명 입력
7) 아래 Webhook에 Slack에서 생성한 Webhook Url 입력
9) 위 작업이 모두 끝나면 코드 리뷰가 가능해집니다.
✒ GitLab에서 얉은 코드리뷰 생성하기
지금부터는 GitLab에서 코드리뷰를 생성하는 방법에 대해 말씀드리겠습니다.
우선, 코드 리뷰에서 제외 되는 것은 단순 enum추가나 한줄의 단순안내문구 수정 같은 리뷰는 제외 됩니다. 해당 건들은 자가 승인으로 진행합니다.
1) GitLab 에 프로젝트에 들어갑니다.
2) Merge Request 를 클릭 합니다.
3) New merge request 를 클릭 후 자기가 작업한 feature branch를 source branch에 merge시킬 branch를 Target branch에 갖다놓습니다.
4) title에는 티켓/일감에 대한 간략한 제목을 적습니다.
5) write에 템플릿과 같은 일관된 형태의 글을 적습니다.
저희 팀은 레드마인을 쓰고 우선 간단한 형태의 템플릿으로 가기로 하였습니다.
#redmine issue
일감번호
##as-is
##to-be
6) 코드리뷰를 시작합니다.
1. 서로의 잘못이나 오류를 지적하는 의도가 아닌 것을 항상 기억합니다.
2. 당장 운영에 문제가 있는 hotfix건과 주석 제거와 같이 로직에 큰 변화가 없는 건은 스킵합니다.
3. 기본적인 것에 집중합니다.
a. 오타나 문법적 오류 고쳐주기
b. 언어에 대해 질문하기
c. 변수명, 비즈니스 로직 모르는 거 물어보기
d. 제안하기
- 코드리뷰가 끝나면 finish review를 누르고 담당자에게 코드리뷰가 끝났다고 알려줍니다.
- 담당자는 확인 후 recomment를 달거나 수정 후 반영을 하면 됩니다.
마무리
처음부터 완벽하게 시작하리라 생각하지 않았습니다. 어떠한 일이든 수많은 시행착오 후에 견고해진다고 생각하기 때문에 계속 회고를 통해 수정해 나갈 생각입니다. 어느 정도 코드 리뷰가 진행 된 후에 후기를 작성할 예정입니다.
