이 포스트는 CC BY 라이센스로 작성된 thoughtbot의 guides 중 Code review를 번역한 글이다. 짧은 만큼 상식적인 느낌도 많이 드는데 숙지하고 평소 습관으로 만들 수 있으면 좋겠다.
코드 리뷰
코드를 리뷰하고 내 코드를 리뷰 받는 방법에 대한 가이드.
모두에게 해당
- 대다수 프로그래밍에서 내려진 결정은 각각의 견해에 따른다는 사실을 받아들인다. 어느 쪽이 더 좋은지 장단점을 의논하고 빠르게 결정을 내린다.
- 질문한다. 대신 답을 강요하지 않는다. (“이
:user_id라는 네이밍에 대해 어떻게 생각하나요?”) - 명확하게 해달라고 묻는다. (“제가 이해하지 못했어요. 다시 설명해줄 수 있어요?”)
- 코드의 소유권에 대해 특정하는 것을 피한다. (“내가 작성한”, “내 코드가 아닌”, “당신이 작성한”)
- 개인적인 특징은 언급하는 것으로 보일 수 있는 단어를 피한다. (“바보”, “멍청한”). 모든 사람이 매력적이고 똑똑하며 선의가 있는 것으로 여겨야 한다.
- 명시적으로 한다. 사람들은 온라인에서 당신의 속내를 항상 쉽게 이해할 수 있는 것은 아니란 점을 유념한다.
- 겸손해야 한다. (“확신하기 어렵다. 한번 살펴보겠다.”)
- 과장하지 않는다. (“항상”, “절대”, “끊임없이”, “아무것도”)
- 빈정대지 않는다.
- 실제처럼 행동해야 한다. 당신에게 해당하지 않는 이모지, 움짤 gif 또는 유머를 사용하더라도 그 사람들을 비꼬아서는 안된다. 만약 그들이 그런 행동을 한다면 침착하게 대응한다.
- “이해할 수 없다” 또는 “대안:” 식의 코멘트를 너무 많이 사용한다면 대화가 필요하다. 오프라인에서 대화한 내용을 요약해 후속 코멘트로 남긴다.
내 코드를 리뷰 받을 때
- 리뷰어의 추천에 감사해야 한다. (“리뷰 고맙다. 그렇게 변경하도록 하겠다.”)
- 개인적인 부분으로 받아들이지 않는다. 리뷰의 대상은 코드지 당신이 아니다.
- 왜 코드가 존재하는지 설명한다. (“이 부분을 이렇게 짠 이유는 이런 이유 때문이다. 내가 클래스/파일/메소드/함수명을 이렇게 바꾸면 더 명확해질 수 있을까?”)
- 변경점과 개선점을 꺼내 미래의 티켓/스토리로 둔다.
- 티켓/스토리에 코드 리뷰를 링크한다. (“리뷰를 위한 준비가 되었음: https://github.com/organization/project/pull/1”)
- 초기 피드백을 받을 때는 독립적인 커밋으로 만들어 브랜치로 푸시한다. 브런치가 머지되기 전까지 커밋을 뭉쳐버리지 않는다. 리뷰어는 초기 피드백에 기반을 둬 작성한 각각의 업데이트를 읽는 것이 가능해야 한다.
- 리뷰어의 관점에서 이해하도록 노력한다.
- 모든 코멘트에 응답하도록 노력한다.
- 지속적인 통합(TDDium, TravisCI 등)이 브랜치에서 모든 테스트가 통과되기 전까지 브랜치로 머지하지 않고 기다린다.
- 코드를 머지하는 일은 프로젝트에 영향을 준다. 그러므로 자신의 코드에 확신이 있을 때 머지한다.
코드를 리뷰할 때
왜 이 코드가 필요한지 이해한다. (버그, 사용자 경험, 리팩토링.) 그러고 나서:
- 어느 아이디어가 강점이라 생각되는지, 혹은 그 반대인지 소통한다.
- 문제를 해결할 때까지 코드를 단순화하는 것으로 방향을 찾아라.
- 논의가 철학적이거나 학문적으로 흐를 때는 그 주제를 금요일 오후 기술 토의처럼 오프라인으로 가져와서 논의한다. 그 후 코드 작성자가 대안적인 구현으로 최종 결정을 내리도록 한다.
- 대안적인 구현을 제공할 때는 작성자가 이미 그 구현을 고려했을 것으로 가정한다. (“custom validator를 여기서 사용하는 것에 대해 어떻게 생각하나요?”)
- 작성자의 관점을 이해하도록 노력한다.
- :thumbsup: 또는 “머지 준비됨 Ready to merge”와 같은 코멘트와 함께 풀 리퀘스트를 수락한다.
코멘트 스타일
리뷰어는 스타일 가이드라인에 따라 코멘트를 남긴다. 예시는 다음과 같다:
[스타일](https://github.com/thoughtbot/guides/blob/master/style/README.md):
> 연관 라우팅을 이름 알파벳 순으로 정렬.
응답할 때는 다음과 같은 스타일로 코멘트를 작성한다:
앗, 좋은 지적이네요. 감사합니다. Fixed in a4994ec.
만약 이 가이드라인에 동의하지 않는다면 토론하기 전에 가이드 리포지터리에 이슈를 먼저 만들길 바란다. 합당하다면 가이드라인에 덧붙여질 것이다.