#014. 백엔드 성장일기: 코드리뷰어를 지치지 않게 하는 커밋하기

버거킹은 고객 문의 사항에 대해 48시간 이내에 대응하는 룰이 있다고 한다. 반면에 맥도날드는 고객 문의 사항 대응이 엉망이라는 것을 이용해서 바이럴 마케팅을 한 케이스가 있다.

 

코드 리뷰를 받는 일이 많아지면서 어떻게 하면 더 나은 코드리뷰를 받을 수 있을까 고민했던 내용을 이 마케팅과 엮어 설명해보려고 한다.

---

(1) 자잘한 style 이슈들 => 코드 리뷰어가 읽는 방식대로 읽어보기.
로직 위주로 코드를 읽고 작성하다보면 자잘하게 놓치는 부분이 많았다. 리뷰어가 지적 해주면 그제서야 왜 이랬지 싶은 것들이 IDE를 열고 보면 눈에 잘 안들어왔다. 예를 들면 아래와 같은 리뷰들이 있다.

띄어 쓰기 해야할 곳에 띄어쓰기를 안 한 경우

컨벤션을 안지킨 경우

ㅠㅠ 너무 기본적인 실수

필요 없는 await

삭제해야할 라인 삭제를 안 한 경우

삭제해야할 라인 삭제를 안 한 경우

파라미터가 많은 데 DTO 처리를 안 한 경우

쓰레기를 안치운 경우

한 파일 길게 작성하기

필요 없는 필드 남겨두기

이런 자잘한 린트 에러들은 대표적으로 리뷰어들을 지치게 한다. 그러다보면 핵심 로직이나 엣지케이스 등 정말 체크해야 할 이슈들을 놓치게 된다. 이 문제를 해결하기 위해 커밋 전에 리뷰어가 보는 것처럼 깃헙 페이지로 보고 있다. 마치 다른 사람이 작성한 코드처럼 볼 수 있어서 더 잘 보이는 것 같다. 이전에는 커밋 작성 후에 바로 코드 리뷰 요청을 했는데, 이런 자잘한 린트 에러들을 잡기 위해 깃헙 페이지로 스스로 확인 하고 수정한 이후에 리뷰 요청을 하고 있다.

(2) 네이밍 이슈 => 코드를 문장으로 풀어서 읽어본다 + 일반적으로 사용하는 컨벤션 참고하기

네이밍을 참고할 만한 클래스나 파일이 있다면 쉽게 해결되지만 그렇지 않은 경우도 있다. 이런 경우 만들고자 하는 걸 풀어서 읽어보면 도움이 되었던 것 같다. 아직 자신이 없는 부분이긴 한데 어제 코틀린 수업을 들으면서 오픈소스의 네이밍 컨벤션을 참고할 수 있는 사이트를 알게 되어서 적극적으로 이용해볼 예정이다.

함수/클래스를 처음 작성할 때와 여러번 수정을 거치며 작성을 끝낼 때 쯤에는 처음 정한 이름과 맞지 않는 경우들이 있는 것 같다.

indexing 대신에 DTO나 객체를 만들어서 key에 의미를 담아야 겠다.

(3) PR 내용 작성하기 (not too long not too short)

이건 리뷰어에게 확인 받은 사항은 아니지만, 가능하면 자세하고 읽기 좋게 PR을 작성하려고 노력하고 있다. 어떤 로직을 사용했고 에러처리는 어떻게 했는 지 작성하고 있다. 또 생각은 했지만 아직 구현하지 않은 것들은 // todo 주석으로, 특별히 질문하고 싶은 내용은 comment를 이용해서 커뮤니케이션 하려고 노력하고 있다.

(4) 코드 리뷰 후 반영까지 시간 줄이기

사실 이 부분이 위에서 말한 버거킹 마케팅과 연결되는 부분이다. 이상하게 프로젝트 기간이 길어지는 이유가 무엇일까에 대한 답을 찾기 위해 내 습관들을 돌아봤다. 그러면서 깨달은 것이 코드 리뷰를 받고 반영하는 데까지 이유 없이 하루 정도가 걸린다는 것이었다. 보틀넥을 확인하고 버거킹이 이슈 대응을 하는 것처럼 무조건 1시간 이내에 코드 리뷰를 (최소한) 시작하자는 규칙을 정했고, 리뷰를 반영하는 데에까지 시간이 줄어들면서 커밋 -> 리뷰 -> 반영코드까지의 시간이 줄어들고 있다.

(5) 이야기된 이슈를 다 처리 하지 않은 경우 => 정신 차리자.

작성하다보니 그래도 이제 이런 이슈들이 이제는 내 눈에도 보여서 다행이라는 안도감과 함께, 얼마나 쓰레기 코드를 적었었는 지 숙연함이 동시에 느껴진다.. 위에서 정리한 부분들이 많아지면 리뷰어도 지치고 리뷰이도 움츠러 들어 하고자 하는 로직을 표현하는 데에 자신감을 잃는 것 같다. 자신있는 코드로 원하는 로직을 자유롭게 표현할 수 있도록 의식적으로 연습을 꾸준히 하자.

---

https://youtu.be/lzvYjuMMhDU