코드리뷰 가이드

codeReviewGuide.md

코드 작성자

리뷰요청

• 변경사항에 대한 요약은 짧고 간결한 문장으로 적습니다.

• 변경사항에 대한 상세설명은 최대한 자세하게 적습니다.

  • 어떤 문제를 해결했는지

  • 왜 이게 최선의 해결책인지

  • 해결책에 기술적인 결점이 있는지, 어떤 조언과 도움이 필요한지

  • 이해를 도울 수 있는 참고링크가 있다면 첨부

• PR 과 커밋 단위를 작게 쪼갭니다.

• 한 PR 의 변경파일은 되도록이면 10개를 넘지 않도록 합니다. 한 PR 에 들어가는 커밋의 개수에는 제한을 두지 않지만, 리뷰하는 사람의 집중력을 배려해주세요.

• 하나의 커밋에는 하나의 의도만 들어가게 합니다. 가령, 주요 변경사항과 관련 없는 린트 픽스는 별도의 커밋으로 추가합니다.

• 코드는 코드일 뿐 내가 아닙니다. 나의 코드가 아니라 우리팀의 코드입니다. 우리의 코드를 더 좋게 만들고자 하는 공동의 노력이라고 생각하고, 열린마음으로 코멘트를 주고받습니다.

머지

• 코드 작성자 이외의 팀원이 전부 승인한 후 머지하는 것을 원칙으로 하되, 그럴 수 없는 상황이라면 최소 1명이 승인한 후 머지합니다.

• 부득이 리뷰 없이 셀프머지하는 경우에는 팀의 슬랙채널에 셀프머지한 PR 링크와 그 이유를 공유합니다.

리뷰어

• 칭찬할 부분을 발견하면 칭찬합니다.

• 수정할 부분을 발견하면 둥글게 피드백합니다.

• 최대한 구체적이고 객관적으로 리뷰합니다.

• 가능하면 정량적인 근거를 함께 제시합니다.

• 지나치게 마이너한 수준의 리뷰나 개인의 취향에 맡길 수 있는 부분이라면 코멘트하지 않습니다.

• 리뷰하기 전에 스스로 찾아보거나 테스트해볼 수 있는 부분을 먼저 시도해봅니다.

• 리뷰요청을 받으면 24시간 이내로 리뷰합니다. 그럴 수 없는 상황이라면 코드작성자에게 양해를 구합니다.

• 리뷰의 의도를 명확하게 합니다.

  • 반드시 변경을 요청하는 목적인지

  • 느슨하게 제안을 하는 목적인지

  • 관련된 추가정보를 공유하려는 목적인지

  • 질문하려는 목적인지

참고링크

• 코드 리뷰에서 중점적으로 볼 점 (https://soojin.ro/review/looking-for)

• 좋은 CL(changeList, 변경사항) 작성법 (https://soojin.ro/review/cl-descriptions)

• 구글 코드리뷰 가이드 (https://github.com/google/eng-practices/blob/master/review/index.md)

• 코드리뷰는 문화다 (https://cimfalab.github.io/deepscan/2016/08/code-review-1)