이 문서는 Respectful Changes(
docs/cl_respect.md) 문서의 한국어 전체 번역입니다.
코드 작성자를 위한 가이드
_코드 리뷰어를 위한 대응 문서는
__존중하는 코드 리뷰_를 보라.
성공을 위한 준비
사전 작업을 하라
어려운 코드 리뷰가 원활하게 진행되도록, 코드를 작성하기 전에 예상
리뷰어들에게 연락하라. 문제와 접근 방식을 미리 설명하면 놀라움을 줄이고
초기 의견을 받을 기회를 제공한다. 이러한 교환에서 나온 결정과 그 뒤의
이유가 다른 사람들도 접근할 수 있도록 하라(예: 버그 또는 설계 문서를
통해).
리뷰어를 배려하라
거대한 변경 하나보다 짧은 변경들의 연속을 선호하거나, 리뷰 중 리베이스를
분리하기 위해 별도의 패치를 업로드하는 것처럼, 리뷰어의 시간이나 인지
부하를 덜어 주는 선택을 하라.
전제 조건을 충족하라
코드를 리뷰로 보내기 전에 리뷰할 준비가 되었는지 확인하라. 컴파일되어야
하고, 통과하는 적절한 테스트가 있어야 하며, 스타일 가이드를 존중해야 한다
(git cl format/lint 사용을 권장한다). 이를 검증하기 위해 셀프 리뷰를
수행하는 것을 고려하라. 이는 리뷰어의 시간을 존중하는 것이며, 때로는 리뷰
왕복 한 번을 줄여 줄 수 있다. 초기 리뷰를 받고 싶은 것이라면 그것도
괜찮지만, 그렇게 말해 달라.
의사소통은 어려울 수 있음을 기억하라
코드 리뷰의 맥락에서는 이해나 의견의 차이가 예상된다. 항상 역량과 선의를
가정하라. 짧은 회의(대면 또는 VC)를 제안하는 것을 주저하지 말라. 때로는
이메일 핑퐁보다 그런 방식으로 문제를 해결하는 것이 훨씬 빠르다.
리뷰 요청하기
리뷰어를 선택하라
리뷰를 직렬화할지 병렬화할지 생각해 보라. 코드베이스가 처음이라면, 기본적인
문제를 정리하기 위해 로컬 리뷰어 한 명과 1차 라운드를 진행하는 것이 좋은
생각이다. 요청하는 오너 수를 제한하려고 노력하되(섹션당 한 명만), 충분히
전문화된 사람을 선택해야 한다. 마지막으로, 시간대와 그것이 리뷰 사이클
시간에 미치는 영향을 염두에 두라. 적절한 리뷰어를 고르는 일은 경험과 함께
익숙해지지만, 여기에서 시작하라.
맥락을 제공하라
변경 설명은 리뷰어와 미래의 코드 고고학자 모두에게 당신의 변경이 남기는
첫인상이다. 좋은 설명은 두
가지를 목표로 한다. 첫째, 높은 수준의 관점을 한눈에 전달한다. 둘째, 깊이
살펴보는 데 필요한 모든 관련 정보에 대한 참조를 제공한다: 설계 문서, 버그,
테스트 지침. 버그#는 유용한 참조이지만, 그 자체만으로는 충분하지 않다.
설명에는 무엇을 그리고 왜를 요약하라. 이메일 메시지 안에서 리뷰를
어떻게 하면 되는지에 대한 지침을 추가로 제공할 수도 있다.
기대 사항을 명시하라
리뷰를 보낼 때는 리뷰어에게 당신의 기대 사항을 명확히 하라. 리뷰 측면에서
이는 리뷰의 종류(예: 높은 수준)를 지정하는 것뿐 아니라, 누가 무엇을 어떤
수준의 엄밀함으로 리뷰해야 하는지도 지정한다는 뜻이다. 일정 측면에서는
마감이 있는지 없는지를 말한다는 뜻이다. 촉박한 마감의 경우, 긴급성이
진짜인지 확신하라(힌트: 드물어야 한다). 그리고 그 이유와, 필요한 후속
리팩터링을 랜딩하겠다는 의도를 전달하라.
리뷰 중
응답성을 기대하라
코드를 리뷰받는 목적은 막힘을 해소하는 것이다. 영업일 기준 1일 이내에
리뷰어의 입력을 기대해야 한다. 다만 이는 변경의 크기, 복잡성, 긴급성 /
중요도, 그리고 시간대 차이에 따라 조정되어야 한다. 그 이상이 지나면,
리뷰어의 코드 리뷰 도구 닉네임(예: "jdoe (OOO til 4 Apr)"), 캘린더를
다시 확인하고 IM으로 핑하라. 그래도 안 되면 다른 리뷰어를 찾아라.
모든 댓글을 처리하라
커밋하기 전에 리뷰어들이 모든 댓글이 처리되었다고 느낀다는 확신을 가져라.
질문은 답변을 제공함으로써 처리된다. 제안은 세 가지 방법 중 하나로 처리할
수 있다: 즉시 채택하기("Done."), 후속 변경으로 미루기(버그 #가 있는
TODO), 또는 추가 정보로 반박하기. 더 많은 정보가 필요할 때마다, 해결책을
논의하기 전에 모두가 문제에 동의하는지 확인하고 문서 확장을 고려하라.
모든 리뷰어의 LGTM을 기다려라
일반적인 경험칙으로, 리뷰어가 당신의 CL에 댓글을 달았다면, 새 패치셋에서
그 댓글을 처리했더라도, 리뷰어가 그렇게 해도 된다고 OK를 준 경우(예: 리뷰어가
리뷰 작업을 다른 사람에게 위임할 때)가 아니라면 그들의 LGTM을 받기 전에는
CL을 제출하지 말라. CL을 긴급히 랜딩해야 하는데 리뷰어 중 한 명이 사용
불가능하다면(예: OOO), CL을 제출하고 리뷰어에게 메모를 보내라. 그 메모에는
왜 CL을 랜딩해야 했는지 이유를 반드시 포함하고, 그들의 의견을 고려했으며
후속 CL에서 그들의 추가 댓글에 신속히 대응할 준비가 되어 있음을 보여라.
잘못되어 가고 있다면 무엇을 해야 하는가
코드 리뷰가 당신을 기분 나쁘게 만들어서는 안 된다. 그런 상황에 처했거나
리뷰가 교착 상태에 있다고 느낀다면, 리뷰어를 우회하려고 시도하지 말고 한발
물러서라. 대면 회의나 VC가 때로는 리뷰의 막힘을 푸는 데 도움이 될 수 있다.
이것이 선택지처럼 느껴지지 않거나, 단순히 이에 대해 이야기할 필요가 있다고
느낀다면, 신뢰하는 사람에게 연락하라.
리뷰 후
코드 리뷰는 상당 부분 다른 사람들이 당신의 뒤를 봐 주는 일이다. 리뷰가
완료되면 "Thank you"라고 말하는 것을 주저하지 말라. 또한 코드 리뷰가
처음이라면, 무엇이 잘되었고 무엇이 잘되지 않았는지 되돌아보는 데 잠시
시간을 가져라.