코드 리뷰는 ‘문화’이다 - 2022.03.27
많은 개발자는 좋은 개발팀에 들어가고 싶어한다. 좋은 개발팀 하면 꼭 따라붙는 키워드는 코드 리뷰이다. 나 역시 좋은 코드리뷰 문화를 갖고 있는 팀에 들어가고 싶어했다. 회사를 다니며 의외로 놀랐던 점은 신입 개발자 뿐만 아니라 경력이 많은 개발자 또한 좋은 코드리뷰 문화를 가진 팀을 원한다는 것이다.
코드 리뷰 문화가 좋은 팀에 들어가고 싶어요!
라는 마음을 나는 입사 하기 전부터 가지고 있었다. 지금 생각해보면 굉장히 이기적인 마음이었는데 그 당시 나에게 코드리뷰의 의미는 경력이 많은 개발자가 적은 개발자를 코칭하는 역할이라고 생각했었다. 지금 생각해 보면 터무니 없는 생각이었고 😵, 실제로 일을 해보니 코드 리뷰란 쌍방 소통이라는 점을 알게 되었다.
그렇기 때문에 다시 돌아와서 좋은 코드리뷰란 무엇인가에 대해 생각해 볼 필요가 있었다. 좋은 코드리뷰를 생각하기 전에 우선 코드리뷰란 무엇인가에 대해에 부터 정의할 필요가 있었다. 내가 정의한것은 이렇다.
😵 코드 리뷰란?
코드 리뷰란 리뷰어가 요청한 사람의 코드를 모두 이해하고 해당 코드에 대해 같은 책임을 지는 행위를 말한다. 그리고 더 나은 코드를 위해 서로가 집단 지성을 이용해 서로의 생각을 공유하는 자리이다.
코드 리뷰의 정의를 확실하게 내린 순간부터 좋은 코드 리뷰란 무엇인지 알 수 있게 된다. 그리고 이것이 왜 일방 소통이 아닌 쌍방 소통인지, 왜 문화라고 불리는지 알 수 있게 된다.
좋은 코드리뷰 문화를 알아보기 전에 우선 bad practice에 대해 알아보면 좋을거 같다.
Bad Practice
#1 넵! 넵! 넵!
- 리뷰어: a 변수명은 알아보기 쉽게 b로 바꾸면 좋을거 같아요.
- 요청자**: 넵!**
- 리뷰어: 해당 코드는 버그 발생의 여지가 있을거 같아요.
- 요청자**: 넵! 수정 하겠습니다!**
- 리뷰어: a 라이브러리를 b 라이브러리로 사용하는건 어떨까요?
- 요청자**: 넵! 변경하겠습니다!**
안좋은 예의 첫번째 사례는 주로 주니어 개발자에게 많이 나타난다. 시니어 개발자가 코드리뷰를 했을 때 무조건적인 의견의 수용이다.
우선 이건 코드 리뷰가 아니다. ☹️ 탑 다운 방식의 일방통행 소통일 뿐이다. 더 나은 코드를 생산할 수 없고 코드에 리뷰어의 의견만 들어가게 된다. 리뷰를 요청한 사람은 로봇처럼 주어진 일만 할 뿐 생산적인 활동을 기대할 수 없다.
또 한가지 치명적인 문제는 책임에 대한 전가이다. 위와 같은 방향으로 코드 리뷰가 진행된다면 리뷰어는 해당 코드에 대한 책임을 더 많이 지게 되고, 책임이 따르는 만큼 더 꼼꼼히 코드 리뷰를 해야만 하는 악순환이 생긴다. 리뷰를 요청하는 사람은 리뷰어에게 책임을 전가하고 있는 꼴이기 때문에 리뷰어의 역할이 너무나도 큰 문제가 있다.
따라서 코드 리뷰는 아래와 같이 이루어져야 한다.
👍 Good practice
- 리뷰어: a 변수명은 알아보기 쉽게 b로 바꾸면 좋을거 같아요.
- 요청자: 저는 ~한 이유때문에 a로 지었는데 어떻게 생각하시나요?
- 리뷰어: 아 그러면 a라는 변수명이 더 적절한거 같아요.
- 리뷰어: 해당 코드는 버그 발생의 여지가 있을거 같아요.
- 요청자: 앗 제가 놓친 부분이네요. 수정할게요!
- 리뷰어: a 라이브러리를 b 라이브러리로 사용하는건 어떨까요?
- 요청자: 두가지 라이브러리에 대해 장단점을 조사 한 뒤 무엇을 사용하면 좋을 지 미팅을 한번 잡으면 좋을거 같아요.
요청자에게 코드에 대한 책임이 더 실리고, 더 나은 코드를 향해 의견을 공유할 수 있다!
의견 공유를 위해서라면 100개가 넘는 코멘트 까지 달리는 platform팀
#2 킹프루브
- 요청자: 코드리뷰 요청 드립니다~!
- 리뷰어: approve
- 요청자: 코드리뷰 요청 드립니다~!
- 리뷰어: [approve] a 변수명은 알아보기 쉽게 b로 바꾸면 좋을거 같아요.
(실제로 문제가 없는 경우는 제외)
#1 케이스와 정 반대의 모습이다. 역시 주니어 개발자에게 많이 발생하는 현상인데 코드를 모두 이해하지 않고 잘 작성 했겠지... 라는 생각으로 무조건적인 approve를 말한다.
위와 같은 케이스도 당연히 코드 리뷰라 할 수 없고, #1 케이스와 정 반대의 문제가 나타난다. 이 경우엔 리뷰 요청자가 모든 코드에 대한 책임을 지게 된다. good practice는 #1 케이스와 동일하다.
개발 시간이 부족해서 엉성하게 코드 리뷰를 한 경우도 포함 되는데 이에 대한 주제는 아래쪽에서 다뤄보겠다.
#3 Changed line +9,999...
변경된 파일의 양이 너무 많을때이다. 적절한 설명 없는 많은 양의 pr은 리뷰어에게 큰 부담이 되고 그만큼 놓치는 부분도 많게 된다.
적절한 양의 업무 분배도 중요하지만 개발을 하다 보면 피치 못할 사정으로 많은 양의 코드는 들어갈 때가 있는데 그럴 때는 항상 리뷰어에게 적절한 설명을 해 주어야 한다. 명심하자. 리뷰어가 당신이 작성한 똥을 이해하는데는 많은 시간이 걸린다!
👍 Good practice
pr description을 잘 작성한 분의 글을 발췌
코드에 대한 적절한 설명은 리뷰어가 즐겁게 코드 리뷰를 할 수 있게 되는 원동력이 된다.
github의 pull request template을 활용하는것도 좋다.
🤔 그래서 좋은 코드 리뷰 ‘문화’란?
모두가 같이 수평적으로 코드를 리뷰 하는 것을 말한다.
코드 리뷰는 문화라는 점을 강조하고 싶은데, 문화란 정책과 같이 정해질 수 없고, 모두가 문화를 지키기 위해 노력해야 한다는 것이다. 모두가 코드에 대해 책임감을 갖고 일을 한다면 그것이 좋은 코드 리뷰 문화라고 생각한다.
문화를 지키기 위해선 여러가지 노력이 필요하다.
- 위와 같은 bad practice 피하기.
- 업무를 산정할 때 적절한 단위로 산정하기
- 시간에 쫓기는 개발 하지 않기.
- ...
좋은 코드 리뷰 문화를 유지하기 위해선 개발자 뿐만 아니라 다른 직군의 동의도 필요하기 때문에 다른 직군에게 어필을 하는것도 중요하다. 😅
✈️ Beyond ‘코드’ 리뷰
개발 팀엔 개발자만 있는것이 아니다. 코드 리뷰 문화를 확장한다면 좋은 팀을 꾸릴 수 도 있다. 정책 리뷰, 디자인 리뷰, QA 리뷰 등등 누구나 리뷰를 요청하고 리뷰를 할 수 있다. 좋은 ‘리뷰’ 문화가 있는 팀이라면 좋은 팀이 될 수 있을 것이다. 앞으로는 좋은 ‘코드 리뷰’가 있는 팀 보다는 좋은 ‘리뷰’가 있는 팀을 선호하는 것은 어떨까? 🎉
도움을 받은 글 들