코드 리뷰 가이드

이 포스트는 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.

만약 이 가이드라인에 동의하지 않는다면 토론하기 전에 가이드 리포지터리에 이슈를 먼저 만들길 바란다. 합당하다면 가이드라인에 덧붙여질 것이다.