이 문서는 Respectful Code Reviews(
docs/cr_respect.md) 문서의 한국어 전체 번역입니다.
코드 리뷰어를 위한 가이드
_코드 작성자 쪽의 대응 문서는
__존중하는 변경_을 보세요.
해야 할 일
역량과 선의를 가정하라
우리는 유능한 사람들을 끌어들입니다. 그리고 그것은 그들이 틀렸을 때조차도, 그 원인이 능력 부족이 아니라 정보 부족일 가능성이 가장 높다는 뜻입니다. “나쁜” CL은 보통 한쪽 당사자가 다른 쪽 당사자가 알지 못하는 정보를 가지고 있다는 뜻입니다.
직접 대화하라
의견 차이가 있다면, 무슨 일이 벌어지고 있는지 정리하기 위해 짧게 직접/화상/IM 대화를 하세요. 오래 지연되는 이메일 왕복 대신, 얼굴을 맞댄 한 번의 대화에서 작은 “아, 그건 몰랐네요”들을 모두 처리하는 편이 훨씬 쉽습니다. 다른 리뷰어와 의견이 다를 때는 “직접” 대화가 두 배로 중요합니다. 그리고 그 결과를 반드시 리뷰에 기록해 주세요.
이유를 설명하라
어떤 코드가 잘못되었다는 것이 여러분에게는 명백할 수 있지만, 작성자에게는 아마 명백하지 않을 것입니다. 그렇지 않았다면 그렇게 작성하지 않았을 테니까요. 그러니 “이건 틀렸습니다”라고 말하지 마세요. 대신 적어도 올바른 방식이 어떤 모습인지 설명하세요. 더 좋게는, 왜 일을 다르게 해야 하는지 설명하세요. 그리고 아주 조금이라도 확신이 없다면, “제가 뭔가 놓치고 있을 수도 있지만…”이라는 문장이 도움이 됩니다. 기억하세요. 역량을 가정해야 합니다.
이유를 물어보라
작성자가 왜 어떤 방식으로 일을 하고 있는지 분명하지 않다면, 왜 특정 변경을 했는지 자유롭게 물어보세요. 모르는 것은 괜찮으며, “왜”라고 묻는 것은 앞으로 이 질문에 답하는 데 도움이 될 서면 기록을 남깁니다. (그리고 때로는 “궁금해서 그런데, 왜 그렇게 하기로 결정하셨나요?”라는 질문이 작성자가 자신의 결정을 다시 생각해 보도록 도울 수 있습니다.)
끝을 찾아라
깔끔한 것을 좋아한다면, 코드 리뷰를 완벽해질 때까지 계속 반복해서 살펴보고 싶은 유혹이 생기며, 그러다 필요 이상으로 길어질 수 있습니다. 하지만 받는 사람에게는 영혼이 말라가는 일입니다. “LGTM”은 “내 불멸의 영혼을 걸고 이것은 절대 실패하지 않을 것이라고 보증한다”는 뜻이 아니라, “내가 보기에는 좋아 보인다”는 뜻임을 명심하세요. 좋아 보이면 넘어가세요. (철저하지 않아도 된다는 뜻은 아닙니다. 판단의 문제입니다.) 그리고 더 큰 리팩터링이 필요하다면, 그것들은 새 CL로 옮기세요.
합리적인 시간 안에 답하라
시간대와 서로 다른 근무 시간을 염두에 두고, 리뷰 요청자가 오랫동안 기다리게 하지 마세요. 약 24시간 안에 리뷰를 볼 수 없다면, CL에 그렇게 말하는 짧은 댓글을 남겨 주세요(그리고 언제 볼 수 있는지도 함께). 그리고 그 시간을 놓쳤다면, 리뷰 요청자가 IM으로 알림을 보낼 때 예의를 갖춰 주세요.
며칠 이상 휴가 중이거나 그 밖의 이유로 OOO가 될 예정이라면, Chromium 코드 리뷰 도구에서 닉네임을 이를 나타내도록 설정해 주세요(예: “(OOO until )” 추가). 여러분에게 코드 리뷰를 보내는 모든 사람이 여러분의 캘린더를 볼 수 있는 것은 아니라는 점을 기억하세요!
긍정적인 점을 언급하라
“모든 결함을 찾아내자”는 마음가짐에 빠지기는 매우 쉽지만, 긍정적인 점을 인정하는 것은 일을 예의 있게 유지하는 데 도움이 될 뿐 아니라, 받는 사람의 하루를 밝게 해 줍니다. 억지 미소를 지을 필요는 없지만, 좋은 결정이 있거나 누군가 정말 지저분한 일을 맡았다면, 그것을 인정해 주는 것은 좋은 일입니다. 반대로, 리뷰어들에게 “감사합니다”라고 말하는 것도 때때로 좋은 일입니다.
하지 말아야 할 일
사람을 망신 주지 말라
“어떻게 이걸 못 볼 수 있죠”는 매우 도움이 되지 않는 말입니다. 동료들이 최선을 다하지만 가끔 실수도 한다고 가정하세요. 그것이 우리가 코드 리뷰를 하는 이유입니다. 그런 실수들을 찾아내기 위해서입니다. 결함 없는 CL은 멋지지만, 결함 있는 CL이 일반적입니다.
극단적이거나 매우 부정적인 언어를 쓰지 말라
리뷰 중인 변경에 대해서든 주변 코드에 대해서든, “제정신인 사람이라면 절대 이렇게 하지 않을 겁니다”나 “이 알고리즘은 끔찍합니다” 같은 말을 하지 마세요. 그런 말은 리뷰 요청자를 위축시켜 여러분이 원하는 대로 하게 만들 수는 있지만, 장기적으로는 도움이 되지 않습니다. 그들은 자신이 무능하다고 느끼게 되고, 그들이 개선하는 데 도움이 될 정보도 별로 담겨 있지 않습니다. “좋은 시작이지만, 조금 더 다듬을 수 있겠습니다” 또는 “여기는 약간 정리가 필요합니다”가 더 나은 표현입니다. 사람이 아니라 코드를 논의하세요.
도구 사용을 discouraged하지 말라
사람들이 자동 포매터를 사용한다면, 일관된 코드베이스를 보장하기 위해 포매팅의 권한을 기꺼이 내려놓는다는 점에 감사하세요. 그 위에 여러분 자신의 선호를 강제하기 전에 신중히 생각하세요. 사람들이 사소한 변경의 버그를 찾기 위해 try bot을 사용한다면, 그것을 discouraged하지 마세요. 더 많은 문제를 해결할 여지를 만들기 위해 기계 시간을 쓰고 있다는 점에 감사하세요.
bikeshed하지 말라
이 결정이 장기적으로 정말로 중요한지, 아니면 여러분이 주관적인 선호를 강제하고 있는 것인지 항상 스스로에게 물어보세요. 옳다는 느낌은 좋지만, 그 게임에서는 두 참가자 중 한 명만 이길 수 있습니다. 중요하지 않다면, 서로 의견이 다르다는 데 동의하고 넘어가세요.