PARA/03_Resources/R001_개발_레퍼런스(참고문서)/개발 환경과 도구/코드리뷰를 잘할 수 없을까.md

코드리뷰를 잘할 수 없을까

2024년 11월 22일

개요

코드리뷰는 꼼꼼하게 보려고하면 정말 한도끝도없이 긴 작업이다.
개인적으로 코드는 볼수록 좋아지고, 고칠수록 좋아진다고 생각하기 때문에 더 그렇다.

그러나 코드리뷰에 하루에 2시간 이상 쓰는 것은 명백히 미련한 짓이고,
1시간 이상 쓰는것도 사실상 어렵고 힘든 일이다.

새로운 직원이 합류하고 몇달동안 공들여 코드리뷰를 하면서 피로함을 많이 느꼈다.
마침 일도 많아지면서 더 그렇게 느꼈다.

이참에 코드리뷰를 효율적으로, 퀄리티있게 하는 방법을 찾아보고 업무 효율을 늘려보고자 한다.

시스코 코드리뷰 관련 글

현재 우리의 코드리뷰는 다음과 같은 문제가 있었다.

코드리뷰의 방향성이 명확하지 않으면, 리뷰어와 작성자 모두 혼란을 겪을 수 있다.
따라서 리뷰의 목적을 상황에 따라 명확히 정의하고, 이에 맞는 리뷰 방식을 선택해야 한다.

코드 퀄리티 향상
- 가독성, 유지보수성, 일관성, 설계 개선 등을 목표로 함.
- 장기적인 코드 품질 향상 및 팀의 코드 컨벤션 준수를 중점적으로 봄.
배포 전 버그 및 문제점 발견
- 동작상의 오류, 비즈니스 로직, 엣지 케이스 검증에 초점.
- 배포 안정성과 즉각적인 문제 해결을 우선.

코드리뷰의 분량이 많으면, 중요한 부분을 놓치거나 리뷰어의 피로도가 급격히 증가한다.
이를 방지하기 위해 PR의 크기를 줄이고, 리뷰가 가능한 단위로 작업을 나누는 습관을 팀에 정착시켜야 한다.

작고 자주 PR 보내기
- PR 크기를 300줄 이하로 제한하는 가이드라인 도입.
- 각 PR은 하나의 주요 변경사항만 포함하도록 유도.
단계별 PR 작성
- 대규모 작업은 여러 단계로 나누어 작성.
- 예: "Step 1: 데이터베이스 스키마 추가 → Step 2: 비즈니스 로직 구현 → Step 3: 프론트엔드 연결."
Draft PR 활용
- 초안 단계에서 Draft PR을 열어 큰 그림에 대해 초기 피드백을 받음.
- 리뷰어는 완성된 PR에서 불필요한 맥락을 다시 검토하지 않아도 됨.

위 내용을 팀원과 공유하면서 토론했다.
쟁점은

PR을 끊어서 조금씩 하는것은 비효율적이다.
- 또한 자잘한 커밋을 수십번 하고 PR직전에 정리하는 코드스타일 상 PR을 끊어서 올리는 것은 어렵다.
PR 분량이 많으면 코드 보기 어렵고 리뷰도 오래걸리기 때문에 끊어야 한다
이 두가지 의견 충돌이다.

우선 당장 마구마구 바꾸기는 어렵다고 생각해서 우선 PR쪼개는건 이후 다시 이야기하기로하고,
코드를 빠르게 이해하고 리뷰할 수 있도록 주요 로직에 코멘트 하는 정도만 먼저 해보기로 했다.

위 링크를 참고하여 작은 PR을 쓰자고 어필했다.

실제 PR 템플릿 작성 예시는 [[KnowledgeBase/Blog/잡다한 개발/코드리뷰 pull request 템플릿]]에서 확인할 수 있다.