📝 TurtleRun Project Code Review Guide

Code Review의 목적

TurtleRun 프로젝트에서 코드 리뷰를 진행하는 목적은 다음과 같습니다.

코드 리뷰로 달성하고자 하는 것들

1. 코드베이스의 변동 사항을 팀원 모두가 정확히 인지한다.
2. 동료가 작성한 코드를 통해 나의 성장을 도모하고, 피드백을 통해 동료의 성장을 이끈다.
3. 작업 결과물의 책임을 개인이 아닌 팀원 모두가 함께 나눈다.

첫째, 코드베이스의 변동 이력을 팀원 모두가 신속하게 파악할 수 있도록 하기 위함입니다.

팀의 규모와 관계없이 프로젝트 내에서 어떤 수정, 추가, 삭제가 이루어지고 있는지 제대로 파악하지 못하면, 각자의 작업에 팀의 구현 의도를 정확히 반영하기 어렵습니다.
‘코드베이스의 수정 추적’이라는 과업을 개인에게 위임하기보다는, 코드 리뷰라는 제도를 통해 부담 없이 자연스럽게 수행할 수 있습니다.

둘째, 팀의 성장을 도모하기 위함입니다.

각 팀원이 가진 개발 역량과 스타일은 각자의 경험에 따라 다를 수밖에 없습니다.
역량이 더 뛰어난 사람이 일방적으로 지식을 전달하거나 교육하는 방식은, 두 사람의 성장 한계가 교육 제공자의 역량에 머무르게 만듭니다.
코드 리뷰 공간에서는 서로의 작업물을 더 나은 방향으로 개선하려는 데 집중하게 되므로, 역량이 높은 사람도 새로운 통찰이나 미처 몰랐던 지식을 얻을 수 있고, 새로 합류한 팀원은 팀의 코드 스타일과 문제 접근 방식을 효율적으로 학습할 수 있습니다.

셋째, 작업에 대한 책임을 분산하기 위함입니다.

프로그래밍은 사람이 하는 일이기에 실수는 반드시 발생합니다.
코드 리뷰를 통해 영향도가 큰 실수를 사전에 차단할 수 있으며, 리뷰어 역시 작업자와 동등한 책임을 갖게 됩니다.
이로 인해 민감한 작업에 대한 부담을 줄이고, 예기치 못한 장애가 발생했을 때 작업자 개인이 아닌 팀 전체가 책임을 분담할 수 있습니다.

Code Review 가이드

백명석 님의 코드 리뷰 노하우 강의를 꼭 한 번 들어보길 추천합니다.

https://www.youtube.com/watch?v=TAPviNhFuSg

1. 리뷰어는 요청을 받은 후 최대한 빨리 리뷰를 시작합니다.

• 코드 리뷰는 코드 작성자의 작업 시간에 포함되므로, 리뷰 지연으로 인한 작업 지연이 없도록 합니다.
• 개인 작업에 앞서, 치명적인 장애 대응이 아닌 한 코드 리뷰를 가장 높은 우선순위로 처리합니다.
• 리뷰 요청을 받으면 첫 번째 리뷰 라운드는 다음날 자정 전까지 반드시 완료하며, 불가할 경우 작업자와 협의하거나 리뷰 요청을 거절합니다.

2. 코드의 수준을 1~2단계 상향시키는 것을 목표로 합니다.

• D 등급의 PR이 있다면, C~B 등급이 되도록 개선하는 것을 목표로 합니다.
• 완벽함보다는 충분히 좋은 코드를 만드는 데 집중합니다.
• 한 번에 너무 많은 코멘트는 작업자가 당황할 수 있으니 주의합니다.

3. 경어를 사용하고, 작업자를 직접 지칭하지 않습니다.

• ~~“너는 왜 맨날~”~~
• 코드 리뷰의 핵심은 “누가 이런 아이디어를 냈는지”가 아니라 “무엇이 코드를 더 나아지게 하는가”입니다.
• 저자의 방어적 반응을 유발하지 않는 언어를 사용합니다.
  • ex) “이건 OO님이 변수명에 오타를 내셨네요” → “저는 XX보다 YY라는 변수명이 더 나은 것 같은데 어떤가요?”
• 명령이 아닌 요청의 형태로 표현합니다.

4. 건설적인 피드백을 합니다.

• 코드 리뷰는 ‘생산성’ 향상을 위한 활동입니다.
• 코드 리뷰를 ‘비판’이 아닌 ‘학습’의 기회로 인식합니다.
• 의견이 아닌 원칙에 기반해 피드백합니다.
• 코드의 장점도 최소 1~2개는 꼭 언급합니다.

5. 교착상태를 적극적으로 해결합니다.

• 저자가 피드백 요청에도 본래 작업물을 고수한다면, 저자의 의견을 최대한 존중합니다.
• 불필요한 교착상태는 팀 관계를 악화시키고, 작업 비용을 증가시킵니다.
• 합의가 어려운 경우, 상위 테크 리더나 다른 동료에게 리뷰를 위임합니다.

6. 농담을 하지 않습니다.

• “이 코멘트는 더 나은 코드를 위한 제언 이외의 다른 의도는 전혀 없다.”라는 신뢰를 코드 리뷰 공간에서 구축하기 위함입니다.
• 가벼운 농담이 오가는 공간에서는 이러한 신뢰를 쌓기 어렵습니다.

7. 리뷰 요청자가 지켜야 할 것들

1. 하나의 PR은 500줄 내외의 수정사항으로 관리하고, 1000줄을 넘지 않도록 합니다.
2. Self review를 활용해 리뷰어의 이해를 돕기 위해 노력합니다.
3. 리뷰 코멘트에 대해 수정 내용이 포함된 커밋 태그를 답글로 남기고, 해당 conversation의 저자가 직접 처리하기 전에는 임의로 resolve하지 않습니다.
4. 리뷰어의 comment에 날카롭게 반응하지 않습니다.
5. PR이 approve되면, 요청자가 직접 PR을 merge합니다.