팀에 인원이 증가하면서 개인의 습관에서 비롯된 다양한 코드들이 등장했습니다.
기본적으로는
1. 변수를 선언할 때 규칙이 다르거나
2. 상대적으로 비효율적인 코드들이 보이기 시작했습니다.
혼자 개발하면서도 git flow를 유지하면서 개발 중이었는데, 새로 합류하시는 분들에게도 develop에 merge할 수 있는 권한이 있다보니 저희의 레포는 조금씩 일관성 없는 코드로 채워지기 시작했습니다. 지난 포스트에서 언급한 것 처럼 매주 사용자 피드백도 같이 받고 있던 상황이기 때문에 바쁘다는 핑계로 그냥 두다가, 앞으로 점점 개발팀이 커지면 문제가 될 수 있을 것 같아서 CTO님과 다른 개발자분들에게 코드리뷰를 제안했습니다.
1. 서로 코드를 봐주고
2. 이해가 안되는 부분은 질문하고
3. 고칠 수 있는 점들이 발견되면 제안하자
3가지 이유로 코드리뷰를 제안했습니다.
코드리뷰는 내가 작성한 코드를 다른사람에게 검사받는 시간이 아니라, 최선의 코드를 작성하기 위한 공동의 노력입니다. 코드리뷰를 통해서 다른 개발자들과 소통할 수 있고, 생각하지 못했던 방식들을 배울 수도 있고, 더 좋은 프로젝트를 만들 수 있습니다. 이 부분은 동의하지 않는 분들도 있겠지만, 코드리뷰를 하게되면 누군가에게 보여주는 코드가 되기 때문에, 더 좋은 코드를 작성하기 위해 노력해야 겠다는 심리적 효과가 있습니다.
위에 언급한 3가지 방식으로 코드리뷰를 하니, 비효율 적인 코드는 상당수 개선할 수 있었습니다. 하지만 변수를 선언할 때 규칙이 다르거나, package import순서가 다르다거나, 함수의 위치가 달라서 코드 파악이 어려운 문제는 아직 남아있었습니다. 그래서 컨벤션을 작성하기로 했습니다.
변수명이 뭐가 그렇게 중요하냐고 생각할 수 있지만, 일관성 있는 코드는 가독성에 유리합니다. 또한 내가 작성 한 코드에서 발생한 문제를 다른 개발자가 해결해야 하는 경우도 있는데, 이 경우에 코딩 컨벤션이 지켜진다면 시간을 아낄 수 있습니다.
백엔드는 당시 Django를 사용해서, 파이썬 변수명에 대한 코딩 컨벤션을 만들었습니다. PEP8규칙을 따르려고 노력했고, 노션으로 공유한 문서에 팀원들 피드백을 받아서 저희만의 파이썬 컨벤션을 작성했습니다. 엔드포인트에 다양한 method들을 작성할 수 있으면 Class-Based View를 사용하고, 하나의 method만 작성할 경우에 Function-Based View를 사용하기로 했습니다. 아! 그리고 저희는 파이썬 코드는 align합니다.
프런트엔드는 조금 복잡했습니다. React와 React Native를 사용중인데, 타입스크립트 컨벤션, 리액트 컨벤션, 그리고 eslint 규칙까지 정해야했습니다. 기본적으로는 airbnb에서 추천하는 방식을 따르고, 컴포넌트 내 함수와 hook들의 위치. import 순서, eslint 규칙들을 모든 프런트엔드 개발자들이 모여서 결정했습니다. 예전에 발표자료에서 보니 토스는 토스 린트가 있어서 컨벤션을 지켜주던데, 가능하다면 같은 기능을 하는 자체 모듈을 개발하고자 하는 목표가 있습니다.
기능만 잘 작동하면 되는데 왜 굳이 코드리뷰를 해서 시간을 낭비하느냐고 생각할 수도 있습니다. 리뷰를 하게되면 데드라인이 금요일까지라면 목요일까지는 완성해야 리뷰를 반영해서 해당 feature를 완성할 수 있습니다. 바쁜데 리뷰까지 하라고? 라는 생각을 하실수도 있겠네요.
하지만 코드리뷰는 시간을 낭비하는 것이 아니라 아끼는 방법입니다. 내가 놓쳤던 부분을 다른 개발자가 확인해서 에러를 미연에 방지할 수 있습니다. 코드 효율이 개선되면 사용자들의 시간을 아낄 수 있고, 컨벤션을 통해서 규칙적인 코드를 작성한다면, 내가 작성한 코드를 다른사람도 쉽게 이해할 수 있습니다.
지금은 슬랙 채널에 알림이 오면 가장 빨리 확인하는 2명이 리뷰를 하고, develop으로 merge하는 방식으로 코드리뷰를 하고 있습니다. 슬랙 채널 알림을 확인하지 못하는 경우가 종종 있어서 github workflow을 통해 랜덤으로 리뷰어를 배정하고 배정된 리뷰어에게 슬랙으로 DM을 보내는 방향을 고려중입니다.
위에서 언급한 것처럼 코드리뷰는 최선의 코드를 작성하기 위한 공동의 노력이기 때문에, 고칠 점은 안내하고, 잘 작성한 부분은 칭찬(?)하는 방식으로 리뷰를 진행하고 있습니다. 그리고 이해가 안되는 부분은 질문하고, PR author는 본인의 의도를 설명합니다. 그동안은 "주석 없이도 이해할 수 있는 코드가 좋은 코드다"라고 생각해서 주석은 제거하자는 생각이었는데, 팀이 커지고 프로젝트 규모가 커지면서 "주석도 잘 활용하면 좋겠다"는 생각이 듭니다.
저희가 코드리뷰 하는 방식을 스크린샷으로 조금 첨부했습니다. jasonkang14는 제 계정이고, 다른 분들의 이름과 계정은 가려보았습니다.
글과 예제를 보시고 저희의 코드리뷰 시스템에 조언해주실 수 있다면 댓글로 부탁 드립니다!
