코드리뷰 시 Pn 룰에 대한 논의

[s0o0bn]

코드리뷰 좋네요 ,,
혹시 pn룰에 대해 알고 계신가요?
https://techblog.woowahan.com/7152/
제가 전 프로젝트에서 도입했던 코드리뷰 방법론인데, 확실히 리뷰 파악하는 데 도움이 됐던 것 같아서 추천드립니다~

PR #9 에서 재영님의 코멘트를 보고 해당 방법론이 괜찮아 보여서 도입을 논의해보면 좋을 것 같습니다.
실제로 저도 데브코스 당시 멘토링 해주셨던 현직자 분이 팀에서 사용하는 코드리뷰 방식이라고, 저희 팀 리뷰 해주실 때 적용하셨습니다.

그때 멘토 분은 [May], [Should], [Good], [Question] 로 코멘트를 나눠 피드백을 주셨습니다.

위 방법론을 통해 코멘트 별로 중요도를 명확하게 구분할 수 있고 반영 여부를 파악할 수 있어 좋아 보입니다.
어떻게 생각하시는 지 궁금합니다.

[unikal1]

그렇다면 해당 방식은 어떨까요.
p1 : 반드시 변경(로직에 치명적인 오류, 오타 등 무조건 바꿔야 됨) - request change
p2 : 변경을 고려 (성능 개선 여지, 효율적인 방향으로의 리펙토링, 디테일 등) - comment
p3 : 고민의 여지 (효율성 약간의 개선, 그러나 큰 수고가 드는 경우 등) - approve

just ask : 해당 부분 로직에 대한 단순한 질문

다른 적용 사항들을 보면 p5 까지 세분화 되어 있긴 하지만 코드 리뷰어가 결국 한 명씩이니 만큼 3 + 1 로 가는건 어떨까요

[dioo1461]

700줄 이상으로 넘어가지 않게끔 PR 단위를 작게 유지하자는 말씀이신 것 같습니다~

[unikal1]

이번에 제가 작성한 pr을 보시면

이렇게 변경된 줄 수가 삭제를 포함하여 1359 인데, 너무 고봉밥이면 리뷰어 입장에서 코드를 보기 싫을 수 있으니 최대 700줄 정도로 줄이면 어떨까 하는겁니다.

[s0o0bn]

아아ㅏ ㅋㅋㅋㅋㅋㅋ 좋습니다.
그럼 최대한 이슈 단위를 작게 가져가야겠네요.

[unikal1]

네 ,다만 그만큼 pr 이 밀리는 것을 최소화해야 해서, 상황에 맞게 조절하면 좋을 것 같습니다. 가령, 바쁜 일정 등이 존재하면 의도적으로 PR 단위를 키우든지 하는 등으로요.

[s0o0bn]

넵 좋습니다.