성장하는 지름길 코드리뷰
1. 들어가며
2. 기존 시스템의 아쉬움
3. 새 코드리뷰 시스템 도입의 어려움
4. 리뷰환경 변화
5. 코드리뷰 도움이 되었던 Tip들
6. 앞으로 개선할 만한 것들
7. 마치며 (Why? CODE REVIEW)
안녕하세요. 크몽 플랫폼 팀에서 프론트엔드 개발을 하는 DALI입니다. 프론트엔드 개발팀에서 점차 리뷰 문화를 개선해나간 경험을 나눠보고자 합니다. 자 그러면 본격적으로 크몽 FE 팀에서 코드리뷰를 점진적으로 개선한 경험 시작해보겠습니다.
깃헙 PR 리뷰를 도입하기 이전에 코드리뷰 시간이 있긴 있었습니다. 일주일에 한 시간 모여서 한 작업자의 코드를 리뷰하는 시간이 있었지만, 비효율적이고 아쉬운 점이 많았습니다.
1. 일주일에 한 작업자의 코드만 살펴볼 수 있다.
2. 일주일 동안 커밋한 한꺼번에 많은 양의 코드를 짧은 시간 안에 컨텍스트를 파악하기 어렵다.
3. 코드 짠 사람의 설명에만 맞춰서 파악할 수밖에 없다.
4. 이마저도 회의나 다른 일정 때문에 다 같이 하기 쉽지 않았다.
이렇게 여러 큰 단점 들에서 한계를 느껴 Github PR을 이용한 리뷰 시스템을 도입하기로 결정하였습니다.
이미 Github을 이용한 리뷰 문화 도입하고 있는 개발팀들의 기술 블로그와 코드 리뷰 관련 글을 읽어보고, 몇 가지 룰 들을 정의하며 시작하게 되었습니다.
대부분 처음 경험해보는 것이라 어려움이 있지 않을까 했지만, 막상 회의시간에 PR이랑 코멘트 등 몇 가지를
공유해 보니 진행하는 데는 큰 어려움이 없어 보였습니다.
(9월 PR 이용한 리뷰 시작)
그러나 예상과 달리
리뷰를 하고 싶어도 팀원들에 PR이 한동안 아예 올라오지 않았습니다.
리뷰를 받고 싶어도 PR을 4~5개 날려도 피드백이 돌아오거나 리뷰 달리는 경우가 별로 없었습니다
팀원들에게 이제야 왜 안 안됐을까 이유를 요청을 드려봤습니다. (소 잃고 외양간 고치기?)
여러 의견 중에 대표적인 이유를 뽑자면
바빠 죽겠는데 새로운 것을 익히고, 적용할 여유가 없었습니다.
또 당시에는 지금보다 환경적으로 코드 리뷰하기를 잘하기에는 번거로운 환경 개선사항이 많았습니다.
그 당시 대표적인 문제들을 나열해 보자면
쌓여 있는 린트 에러
build 파일도 늘 push 해야 되었던 문제
dev에 PR을 안 날리고 자신의 브랜치에 따로 날렸던 점
리뷰를 처음 도입하는데 번거로운 점이 한두 개가 아니였습니다.
PR을 4~5개 날리는 동안 피드백을 지속해서 요청 안 하고 뭐 했나?
동료들이 PR 안 올리는 동안 왜 안 올리는지 고민? 직접적으로 들어봤었는지
하는 소통에 아쉬움을 느꼈고, 이에 대한 실마리를 문제 해결을 잘하는 팀원이 행동하는 것을 보고 찾게 되었습니다. 그분은 직접적으로 가서 소통하는 게 빠르다 싶으면 얼른 직접 가서 같이 문제를 해결합니다.
새로운 시스템 도입할 때 원래 에너지가 많이 드는 작업임을 알았고, 다음부턴 보다
능동적으로 소통하고 문제를 해결하자!
를 배웠습니다.
그래도 팀원들 모두 점차 중요성을 느끼며 리뷰 환경 개선에 관심을 두고 포기하지 않았고, 리뷰 환경도 대폭 개선이 되어 나갔습니다.
프론트엔드 팀원 2명이 추가되었습니다. 그럼으로써 피드백 인원 증가 및 개선에 같이 참여하며 동기부여 및 리소스 면에서 큰 힘이 되었습니다.
수정된 파일만 올라오지 않았기 때문에 리뷰하기 번거로웠던 문제가 해결되었습니다.
기존에 문서 하나 첨부하고 이 문서 참고해서 잘 작성하자 했었던 commit message rule을 세부적으로 다시 정의하였습니다. 많이 쓰는 커밋 룰 중의 하나인 type (scope)를 적용해서 commit 만 보고 어떤 commit 인지 파악하기 더 쉬웠습니다.
type(scope): description
사실 기본이지만, 룰을 정하고 피드백을 하기 전에는 commit 단위가 작업 단위별로 잘 안 이루어지고 통짜로 commit 하는 경우도 많았습니다.
commit 룰에 관한 피드백을 초반에 많이 가져가면서 자연스럽게 개선이 되었습니다.
리뷰 초반기에는 린트에 대한 코멘트가 상당 부분 차지하였습니다. VSCode와 lint setting 설정을 같이 맞춤으로서 lint 수정에 대한 코멘트를 줄일 수 있게 되었습니다.
(깃 훅으로 commit 하기 전에 체크하는 방법도 좋은 방법 같습니다.)
- PR 목적
- 작업 내역 체크리스트
- 스크린샷
- 테스트 서버
- QA Sheet , Ticket 번호 , 기획 or Zeplin 문서 첨부
- issues 고민거리 같이 나누고 싶은 것들
위와 같은 내용에 맞춰 작성함으로써, 리뷰어들이 작업내용을 파악하기 더 용이 해졌습니다. 올해 2월 즈음부터는 코드리뷰가 더 활기를 띠기 시작했고, 지금은 매일 여러 개의 PR과 리뷰를 서로 주고받고 있는 프론트엔드 팀입니다.
(얼마 전에 지인 개발자분이 우리 팀에서 리뷰 코멘트가 기본이 10개 이상 달리고 활발하다는 얘기가 나왔었는데 어 우리도 그러는데 하고 내심 뿌듯해했던 기억이 있네요. )
(저희 팀에서는 아직 규모가 작은 팀이라 리뷰어 지정은 따로 없이 전체 팀원에게 리뷰를 요청하고 받고 있습니다.)
다음으로는 저희가 리뷰 문화를 적용하면서 환경 개선한 점 이외의 유용했던 Tip들을 소개해드리려 합니다.
처음 파일 저장 시 자동으로 수정된 린트 관련 부분을 따로 commit 하여 commit내역들을 보기 좋게 관리하였습니다.
사소한 부분이지만 Assignee 잘 지정해서 여러 PR 중에 누가 올린 건지 확인하기 쉬웠고, 적절한 Label을 붙여줌으로써 PR을 파악하기 더 쉬웠습니다.
PR 관련 노티 슬랙 채널이 있긴 하지만, 코멘트 관련 노티에 묻혀서 알림 채널을 따로 안 보는 경우도 많았습니다. 그래서 PR을 올릴 때 팀원들과 주로 소통하는 채널에 따로 한 번 슬랙 워크플로우를 이용해서 알림을 주고 있습니다.
앞으로 Reminder 도구도 추가해서 활용하려 하고 있습니다.
팀원들에게 우선 빠르게 리뷰 요청을 시도 후. 여력이 안 될 시에는 선 Merge 후 리뷰를 받기로 룰을 정했습니다.
그리고 무엇보다 피드백을 서로 주고받는 것이 같이 성장하는 빠른 길이라는 것을 인지하고 적극적인 참여와 서로 배려하며 소통하는 것이 중요한 것 같습니다.
이밖에 알고 계신 코드리뷰 팁 있으시면 많이 공유해주시면 감사하겠습니다.
2명 이상 Approved 되어야만 merge 가능하도록 적용
Ci Cd 안에서 기본적인 린트 점검 및 테스트 코드 돌아가도록 적용
PR이 올라오면 해당 브랜치로 테스트 서버가 돌아가도록 적용
Pull Panda 같은 reminders 도구 적용
앞으로는 이런 점을 더 개선해보며 리뷰 문화를 개선해보고 싶습니다.
코드리뷰문화를 개선해보며 코드리뷰가 왜 필요한지 다시 정리해보았습니다.
1. 작업 사항 공유: PR로 작업 내용이나 동작을 공유하면서 서로 작업내역을 파악하기 더 용이합니다.
2. 안정성 및 코드 품질 향상: 같이 QA 해주고 설계나 리팩토링할 부분을 점검해줌으로써 더 안정적이고 깔끔한 코드가 됩니다.
3. 성장: 피드백 받으면서 팀원들 개개인의 능력을 더 향상할 수 있습니다.
4. 커뮤니케이션 능력 향상: 특히 리뷰로 지속적인 피드백과 질의응답을 하면서 커뮤니케이션 능력 + 팀워크에도 많은 도움이 됩니다.
이제 개발자로서 1년 넘게 일을 하다 보니, 개발자로서의 일이 얼마나 팀 플레이어 성향이 강한지 알게 되었고
코드리뷰(소통+ 피드백)의 중요성을 더더욱 느꼈습니다.
개발팀에 리뷰 문화는 선택이 아닌 필수라고 주장하고 싶습니다!
리뷰 문화를 개선하거나 도입하려는 팀에게 조금이나마 도움이 되기를 바랍니다.
긴 글 읽어주셔서 감사합니다.
우리 팀은 크몽과 딱 어울리는 당신을 기다리고 있어요. 우리 함께 크몽을 만들어요!
채용공고 *개발직군 상시 채용중!