원문 사이트
https://github.com/thoughtbot/guides/tree/main/code-review
공통사항
- 많은 프로그래밍 결정이 의견임을 인정하세요. 선호하는 장단점을 논의하고 신속하게 해결책을 도출하세요.
- 좋은 질문을 하되 요구하지 마세요. ("이 이름을
:user_id로 짓는 것은 어떨까요?") - 좋은 질문은 판단을 피하고 작성자의 관점에 대한 가정을 피합니다.
- 설명을 요청하세요. ("이해가 안 되는데 설명해 주시겠어요?")
- 코드의 선택적 소유권을 피하세요. ("내 것", "내 것이 아니다", "당신 것")
- 개인적 특성을 지칭하는 것으로 보일 수 있는 용어는 사용하지 마세요. ("dumb", "stupid"). 모든 사람이 지적이고 선의가 있다고 가정합니다.
- 명확하게 표현하세요. 온라인에서 사람들이 항상 내 의도를 이해하는 것은 아니라는 점을 기억하세요.
- 겸손하게 행동하세요. ("잘 모르겠습니다 - 찾아보겠습니다.")
- 과장된 표현을 사용하지 마세요. ("항상", "절대", "끝없이", "아무것도")
- 비꼬는 표현을 사용하지 마세요.
- 진실을 유지하세요. 이모티콘, 움직이는 GIF 또는 유머가 본인에게 맞지 않는다면 억지로 사용하지 마세요. 이모티콘을 사용해야 한다면, 유머러스하게 사용하세요.
- "이해하지 못했습니다" 또는 "다른 해결책:"이라는 댓글이 너무 많으면 채팅, 화면 공유, 직접 대면 등의 방식으로 동시에 대화하세요. 토론 내용을 요약하는 후속 댓글을 게시합니다.
- 새로운 것을 배웠다면 감사의 마음을 전하세요. ("몰랐던 사실인데 공유해 주셔서 감사합니다.")
코드 리뷰 요청자
- 검토자의 제안에 감사하는 마음을 표현하세요. ("좋은 지적입니다. 변경해 보겠습니다.")
- 온라인에서 감정과 의도를 전달하기는 어려울 수 있다는 점에 유의하세요(https://thoughtbot.com/blog/empathy-online).
- 코드가 존재하는 이유를 설명합니다. ("이런 이유 때문에 그런 것입니다. 이 클래스/파일/메서드/변수의 이름을 바꾸면 더 명확해질까요?")
- 일부 변경 사항과 리팩터링을 추출하여 향후 티켓/스토리에 추가합니다.
- 티켓/스토리에서 코드 리뷰로 연결합니다. ("검토 준비 완료: https://github.com/organization/project/pull/1")
- 이전 피드백을 기반으로 한 커밋을 브랜치에 격리된 커밋으로 푸시합니다. 브랜치를 병합할 준비가 될 때까지 스쿼시하지 마세요. 리뷰어는 이전 피드백을 기반으로 개별 업데이트를 읽을 수 있어야 합니다.
- 리뷰어의 관점을 이해하려고 노력하세요.
- 모든 댓글에 응답하려고 노력하세요.
- 지속적 통합(TDDium, Travis CI, CircleCI 등)에서 브랜치에서 테스트 스위트가 초록색으로 표시될 때까지 브랜치 병합을 기다린다.
- 코드와 코드가 프로젝트에 미치는 영향에 대해 확신이 들면 병합하세요.
- 최종 편집 권한은 풀리퀘스트 작성자에게 있습니다.
코드 리뷰어
변경이 필요한 이유를 이해합니다(버그 수정, 사용자 경험 개선, 기존 코드 리팩터링). 그런 다음
- 어떤 아이디어가 마음에 드는지, 어떤 아이디어가 마음에 들지 않는지 소통하세요.
- 문제를 해결하면서 코드를 간소화할 수 있는 방법을 찾아보세요.
- 토론이 너무 철학적이거나 학문적으로 변하면 금요일 오후의 정기적인 기술 토론으로 오프라인 토론을 전환하세요. 그 동안에는 작성자가 대체 구현에 대한 최종 결정을 내리도록 하세요.
- 대체 구현 방법을 제시하되, 작성자가 이미 고려하고 있다고 가정합니다. ("여기에 사용자 지정 유효성 검사기를 사용하는 것에 대해 어떻게 생각하세요?")
- 작성자의 관점을 이해하려고 노력하세요.
- 풀 리퀘스트에 👍 또는 "병합 준비 완료" 댓글로 서명하세요.
- 게이트키퍼가 아니라 피드백을 제공하기 위해 여기에 있다는 것을 기억하세요.
- '제안 추가' 기능을 사용하여 변경 사항을 제안할 때:
- 어떤 줄을 추가/제거할 것을 제안하는지 명확하게 전달하세요.
- 가능한 경우 제안한 변경 사항을 테스트하여 제대로 작동하는지 확인합니다.
- 테스트할 수 없는 경우에는 풀 리퀘스트 작성자에게 제안을 테스트하지 않았다는 사실을 알립니다.
- 작성자에게 변경을 제안하는 이유를 알릴 수 있는 컨텍스트를 제공하세요.
스타일 코멘트
검토자는 누락된 스타일 가이드라인에 대해 코멘트를 달아야 합니다. 코멘트 예시:
→ 유용한 경로를 이름별로 알파벳순으로 정렬하세요.
스타일 댓글에 대한 응답 예시:
→ 이런. 잘 발견했습니다, 감사합니다. a4994ec에서 수정되었습니다.
가이드라인에 동의하지 않는 경우 코드 리뷰 내에서 토론하지 말고 가이드 리포지토리에 이슈를 개설하세요. 그 동안 가이드라인을 적용하세요. 표준과 같은 lint를 설정하여 코드 형식을 자동으로 지정하는 것이 도움이 되는 경우가 많습니다. 이렇게 하면 개인적인 스타일 선호도에 대한 논쟁보다는 PR에 대해 더 의미 있는 대화를 나눌 수 있습니다.
도움이 되는 다른 글
구글 코드 리뷰 가이드 :
