코드리뷰가 쏘아올린 작은공 - 우아한형제들 기술 블로그

뜨거웠던 개발 후 외로운 사람들
얕은 코드리뷰 도입하기
- 머지 템플릿 작성
- 리뷰어 선정하기
코드리뷰 도입 후
박지은님
전수현님
마치며

안녕하세요. 우아한형제들 배민선물하기팀에서 프론트엔드 프로그래밍하는 송요창입니다. 코드리뷰 도입한 배경과 이후 찾아온 변화에 관해 이야기하려고 합니다.

뜨거웠던 개발 후 외로운 사람들

저희 팀은 작년 하반기에 사전예약 프로젝트를 진행했습니다. 기존 서비스와 다른 부분이 많아 전시영역부터 결제, 대사까지 여러 팀과 협업하며 새롭게 만들어야 했습니다. 적은 일손으로 진행하다 보니 정말 모든 팀원이 바쁘게 일했습니다.

배민 내 서비스는 사용자가 주문한 당일 배달을 받거나 포장/방문 할 수 있습니다. 이와 달리 사전예약은 사용자가 픽업하는 날짜가 당일이 아니며, 예약하는 날짜는 픽업보다 며칠에서 몇 주 이상 앞서 이뤄집니다.

프론트엔드의 경우 처음에는 전시, 주문, 관리자 등 전체 개발 영역을 서로 오가면서 코드를 생산했습니다. 그러다 익숙한 영역의 일만 처리하기에도 벅찬 상태가 되었습니다. 자연히 서로의 코드를 볼 일이 줄었습니다.

그렇게 프로젝트를 마치고 프론트엔드 프로그래머들만 모여서 회고하는 시간이 있었습니다. 그동안 진행하지 못한 기술부채 청산이나 코드 컨벤션, 기술 문서화 등 다양한 논의가 있었습니다. 그리고 혼자 일하는 것 같다는 의견이 나왔습니다.

혼자일하는... 너무 익숙한 모습인데 왜 눈에서 땀이나니

혼자 일하는 느낌이 덜하도록 또는 없도록 하기 위한 아이디어 중 코드리뷰 가 있었습니다. 그전까지 배민선물하기팀 내 프론트엔드 프로그래머들은 각자 머지 리퀘스트(Merge Request, 이하 MR)를 만든 뒤 스스로 머지(Merge)했습니다.

일하는 방식 before 기존에 일하던 방식

이 방식에 작은 변화를 주기로 했습니다.

얕은 코드리뷰 도입하기

코드리뷰를 고려하던 차에 주니어 개발자들의 (얕은) 코드리뷰 도입기란 글을 읽었습니다. 글쓴이의 상황이 저희처럼 스스로 머지하는 상황인게 공감되고, 글 안에 실행법도 자세히 나와 있어 길잡이로 삼았습니다.

위 글과 짝이되는 글 우리, 코드 리뷰 해볼래?

그리고 아래 규칙을 마련했습니다.

MR 내용은 머지 템플릿(Merge Template)에 따라 일관된 형태로 남긴다.
MR에는 최소 1명의 리뷰 담당자를 지정한다.
리뷰 담당자는 가벼운 마음으로 아래 역할을 수행한다.
- 오타 찾기
- 질문하기
  - 변수명, 비즈니스 로직 등 모르는 거 물어보기
  - 질문받은 사람은 이를 설명하면서 다시 복기할 수 있고 질문한 사람은 답변을 보고 로직에 관한 지식을 얻는 게 목적
- 제안하기
  - 이건 A 목적인 건가요? A 목적이 맞는다면 이렇게 해보면 어떨까요? 정도로 자신의 가설과 제안을 함께 작성한다.
  - 되도록 읽는 사람이 한 번에 정보를 확인할 수 있도록 한다.

머지 템플릿 작성

템플릿은 저희 팀 동료분이 여러 템플릿을 참고하여 작성해주셨습니다.

### 작업 개요
<!--
  ex) 고양이가 야옹 소리를 내도록 수정
-->
### Jira
<!--
  ex) BAEMIN-1004
-->
### 작업 분류
- [ ] 버그 수정
- [ ] 신규 기능
- [ ] 프로젝트 구조 변경
<!--
  - [ ] 버그 수정
  - [x] 신규 기능
  - [ ] 프로젝트 구조 변경
-->
### 작업 상세 내용
<!--
  ex) 
  1. 네 발 짐승 클래스에 `크앙` 함수 추가
  2. 고양이 클래스에서 `크앙` 함수에 `미야아옹.wav` 재생시킴
-->
### 생각해볼 문제
<!--
  ex) 
  1. wav 파일을 매번 입력하기 귀찮겠다.
-->

작업에 관한 내용과 작업하면서 아쉬운 점이나 긴 시간을 가지고 변경이 개선점 등을 함께 적게 되어있습니다.

“내가 한 작업이 아닌데 나보고 봐달라고 하는 상황에서 작업자에게 정말 물어보고 싶은 것이 뭘까 고민하며 템플릿 만들어봄” - 템플릿을 작성한 박지은님

리뷰어 선정하기

코드리뷰 도입 시에 어떻게 리뷰어를 선정할까 고민하게 되었습니다. 아무나 선정하면 되지만 아무나 선정하다 보면 한 사람이 많은 리뷰를 할 가능성이 있습니다. 이를 방지하는 대책은 무엇이 있을까요? 달면삼키고쓰면뱉는다 간신과 충신 중 당신의 리뷰어는 누구입니까?😭

첫 번째 💡아이디어는 진행 중인 리뷰 갯수 체크용 웹 API를 만들고 MR 생성자가 결과에 따라 할당하는 방식입니다. 이 방식은 만들긴 쉬운데 매번 API 실행이 필요해서 귀찮습니다.

리뷰어 선정 아이디어1 리뷰어 선정 아이디어 1 - 사람이 하는 일이 너무 많다😭

두 번째 💡아이디어는 첫 번째 아이디어에서 나온 웹 API를 만들고 나서 gitlab webhook이 MR 생성 시마다 API를 호출하여 할당하는 방식입니다. 앞선 방식보다 사람 손이 덜 타고, 신규 입사자가 들어와도 별도의 교육이 필요 없습니다.

리뷰어 선정 아이디어2 리뷰어 선정 아이디어 2 - 게으른 인간을 위한 자동화🛠🤖

저희는 두 번째 아이디어를 구체화해서 코리(cory)라는 슬랫 봇을 만들었습니다. 코리는 다음 2가지 일을 처리합니다.

코드리뷰 봇 이라서 이름이 코리에요. ~~아이가 보는 애니메이션 캐릭터명이라서 그런거 아님~~

webhook 수신 후 리뷰 담당자를 할당한 뒤 슬랙으로 알림을 메시지 발송
월요일 오후 1시 30분, 화요일~금요일 오전 10시에 각자에게 진행중인 리뷰 알림 발송

코리 봇과의 즐거운 대화 코리를 만들며 즐거워하는 개발자

코리가 리뷰 담당자 선정 시 리뷰 그룹 정보를 참고해서 선정합니다. 최초에는 레포지토리(repository) 소속 멤버를 기준으로 하려고 했습니다. 그런데 레포지토리에 백엔드 프로그래머나 다른 팀 동료가 들어간 예도 있어서 이를 분리하게 되었습니다.

어떤 레포지토리 현황 16명의 개발자가 포함된 선물같은 레포지토리 근황

코드리뷰 도입 후

MR을 머지하기 전에 코드리뷰 단계가 추가된 후 작은 변화가 일어났습니다.

일하는 방식 after 코드리뷰가 포함된 일하던 방식

통신을 동기로 처리하다가 비동기로 처리하듯 코드 리뷰가 이뤄지기까지 약간의 버퍼가 생겨났습니다. 그사이 다른 작업을 진행하거나 MR 리뷰 담당자가 어느 부분을 중점적으로 봐줘야 할지 설명하기도 합니다.
자신은 알고 있는 부분을 누군가는 모르기 때문에 설명하면서 다시 정립하기도 합니다.
동료의 코드를 보면서 평소에 안 쓰던 코드 스타일을 살펴볼 수 있었습니다.
누군가가 코드를 봐준다고 생각하니 약간 안심(?)이 되기도 합니다.

아래는 동료들의 후기입니다.

박지은님

리뷰 전 3줄 요약:

나 혼자 일할 때는 기러기아빠가 된 느낌이었다. 그때까지는 덜 외로웠다.

근데 어느 순간 성장이 멈추는 기분이 들었다.

내가 모르는 도메인에 대해 문의가 들어왔을 때 빠르게 응대가 할 수 없어서 더 외로웠다.

리뷰 후 3줄 요약

내 일이 아닌 다른 문제에 대해서 생각해 볼 수 있어서 좋음. 두뇌 회전에 좋음.

팀원끼리 의견 나누는 게 좋음.

서로 코드 스타일도 맞아가는 거같아서 더 좋음.

결론: 안 외롭다.