코드 리뷰 문화를 리뷰해 봐요(PR Reminder Bot 개발 이야기)
- GDG Devfest 2023 Seoul (opens in a new tab) @구글 스타트업 캠퍼스
- 일시 : 2023년 12월 2일(토) 14:00 ~ 17:00
- 발표자 : 김만수
Overview
코드 리뷰의 효과
- 품질 검수
- 서비스 안정성 향상
- 지식 공유 & 구성원 성장
Bus Factor? → 프로젝트가 정상적으로 돌아가기 위해 없어서는 안 될 사람의 수 → 이건 당연히 크면 좋다
코드 리뷰를 통해 한 명에게 맥락이 몰리는 현상을 방지할 수 있다
코드 리뷰의 수준?
- 고수준 : 직접적으로 프로덕트에 문제가 생길 수 있는 포인트 (버그, 성능 저하, 장애, 보안 등)
- 저수준 : 더 나은 프로덕트를 위한 개선 포인트 (코드 컨벤션, ,주석 개선 등)
→ 팀마다 상황이 다 다르니, 지속적인 소통을 통해 전략적인 프로세스 수립 필요
Husky - Git Hook을 활용해 pre-commit 과정에서 Test 실패 여부랑 Lint 검사 등을 해줌
🐶 husky | 🐶 husky (opens in a new tab)
→ 이걸 자동화를 해두니까 코드리뷰의 ‘목적’에 조금 더 집중할 수 있게 됨
문제
요구 사항과 변경점에 대한 이해 과정에서 생기는 병목
스크럼 단위로 분리된 조직에서 각 스크럼별로 이해도가 다르고 작업했던 분야 자체가 다르다면, 해당 파트의 코드를 이해하기 위한 비용이 매우 높음.
→ Reviewer는 Assignee가 가지고 있는 이해도를 따라가야하는데, 그것 자체가 심리적, 물리적으로 엄청난 로드를 불러 일으킴
사이즈가 큰 PR
큰 PR → LGTM 👍
(PR 크기가 줄어들어야 빠른 코드 리뷰가 가능해진다)
후순위로 밀리는 Review
동기 커뮤니케이션 vs 비동기 커뮤니케이션
→ Text 기반의 비동기 커뮤니케이션은 쌓여가는 PR의 개수가 많아진다.
Git Branch Policy에 의해 특정 브랜치에서 Merge를 하기 위해선 최소 1개 이상의 Approve가 필요하고, 그런 정책이 중간중간에 생기는 여러 병목 현상 때문에 속도 자체가 너무 늦어진다.
그래서 PR이 계속 쌓이고… 속도도 느려지고… 문제로 작용하게 된다.
해결
Reviewer가 적은 노력으로도 코드 리뷰를 잘 할 수 있도록 Author의 배려와 노력이 필요
→ 그래서 PR Template을 새로 만들었다
(사진)
PR 라벨 세팅 (D-n 룰)
- D-n 룰 : 리뷰를 언제까지 마쳐야하는지 알 수 있음 (Assignee → Reviewer)
- Label : 어떤 종류인지? 이런 것들
- P-n 룰 (Priority Level 룰 ) : 리뷰가 반영되어야하는 수준 (Reviewer → Assignee)
⇒ 그래서 공통적으로 중요한 건? 심리적인 부분!
D-Day Label을 매일 아침마다 수동으로 변경하면 새로운 인터럽트가 될 것 같은데, 자동으로 변경할 수 없을까?
→ Octokit.js 도 있고, PyGitHub 도 있는데 PyGitHub 채택
→ 왜? 회사 백엔드 기술스택에 Python이 주로 사용되고 있고, 그냥 써보고 싶어서 채택했음
PR Reminder Bot 탄생!
GitHub Actions → Slack API 를 이용해서 노티
하루에 두 번 리마인드 (아침 9:30, 오후 5:30)
기술 블로그에 내용 있으니 참고 ㄱㄱ