코드 리뷰 정책 소개
코드 리뷰 문화가 잘 정착되지 않으면, 코드 리뷰에 들어가는 비용만 들어가고, 개발속도가 느려지는 단점들을 야기할수 있습니다. 이 글에서는 효율적인 코드 리뷰 문화를 위한 여러가지 코드리뷰 정책들을 소개합니다.
코드 리뷰는 코드를 검토받는 작성자와 코드를 검토하는 리뷰어(reviewer)의 커뮤니테이션입니다. 코드리뷰를 통해서 개발자들과의 지식 공유, 코드의 품질등 다양한 장점을 얻을 수 있습니다. 그러나 이는 이상적인 경우이고, 코드 리뷰를 진행하다보면, 여러 문제점들에 직면하게 됩니다.
- 리뷰어와 작성자의 생각의 충돌
- 공격적인 코드 리뷰
- 작성자의 방어적인 태도
- 늦은 코드 리뷰로 인해 지연되는 개발
이러한 문제점들을 극복하기 위해서 여러가지 해결책들이 나왔습니다. 그 중에서 제가 사용해본 정책은 뱅크샐러드에서 만든 리뷰 정책입니다.
Pn 룰
코드 리뷰가 글로 의견을 전하기 때문에, 감정이나 어투가 느껴지지 않아서 생각이 잘못 전달되는 경우가 많습니다. 가벼운 농담이 진지한 이야기로 전해지는 상황도 종종 보입니다.
Pn 룰은 코드 리뷰어가 리뷰의 레벨을 정해주면서, 자신의 리뷰가 어떤 내용인지를 전하는데 도움을 주는 정책입니다.
-
P1: 꼭 반영해주세요 (Request changes)
P1은 PR의 내용이 치명적인 오류를 발생시킬수 있는 가능성을 가지고 있는 등 코드 수정이 반드시 필요하다고 판단될때 사용됩니다. 작성자는 P1 태그가 있을 경우, 코드 수정이나 의사소통을 통해서 리뷰어를 설득해야합니다.
-
P2: 적극적으로 고려해주세요 (Request changes)
P2는 수용하거나, 수용할 수 없다면 토론을 통해 해결해야 합니다.
-
P3: 웬만하면 반영해 주세요 (Comment)
P3는 리뷰어는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나, 나중에 반영할 계획을 설명하면 됩니다.
P2와 다른 점은. Request changes 가 아닌 Comment 와 함께 사용되어서, 이번 PR에 반드시 반영하지 않아도 됩니다. -
P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
작성자는 P4에 대해서는 해당 의견에 대해서 고민해보는 정도면 충분합니다.
-
P5: 그냥 사소한 의견입니다 (Approve)
작성자는 P5에 대해서는 아무련 의견을 달지 않고 무시해도 괜찮습니다.
제가 사이드 프로젝트에서 적용한 Pn룰의 예시입니다.
Pn룰을 이모지를 사용해서 하는 방식도 있는데, 해당 정책은 사용해보지 않아서, 링크로 첨부합니다.
D-n 룰
코드 리뷰 요청이 한번에 여러개가 들어왔을 때, 어떤 코드 리뷰가 중요하고 급한지 몰라서 아무 순서로 리뷰한 경험이 있을겁니다.
D-n 룰은 PR이 Merge되어야 하는 기한을 공유하여, 리뷰들이 시간 내에 반영될 수 있도록 도와줍니다.
-
D-0
긴급한 수정 사항으로, 오류가 발생하거나, 빌드가 실패하는 등 긴급한 수정이 필요할때 사용합니다.
-
D-N
N일 이내로 리뷰해달라고, 요청합니다. 팀마다 정책이 다르지만, 제 사이드 프로젝트에서는 주로 D-7을 사용했습니다.
D-n 룰은 봇을 활용하여, 매일 자동으로 세팅되게 설정할 수 있습니다. Slack이랑 연동하여 활용하면 코드 리뷰를 잊지 않고, 일정에 맞춰서 진행하는데 도움이 됩니다.