코드 리뷰가 ‘당연히 해야 하는 것’으로 받아들여진지도 시간이 꽤 흐른 것 같습니다. 숨고 테크팀에서도 모든 코드 변경점에 대해서 리뷰를 받아야만 제품에 포함될 수 있도록 하고 있어 코드 리뷰가 테크 팀원들에게 중요한 업무 중 하나로 자리하고 있습니다.
코드 리뷰는 개발자들이 서로의 작업에 대해 피드백을 주고받는 과정입니다. 그런데 이 과정이 본질적으로는 사람 간의 대화이다 보니 더 효과적으로 소통할수록 리뷰로 얻는 이득을 크게 누릴 수 있습니다.
그래서 모바일 챕터에서도 그 점을 이해하고 더 효율적으로 리뷰하기 위해 노력하면서 시행착오를 겪어나가고 있습니다. 그 와중에 숨고가 계속 성장하면서 모바일 챕터 동료들이 꾸준히 늘어나 코드 리뷰에 대한 생각을 다시 맞추어 볼 적절한 시점이 되어, 각자 겪었던 시행착오와 레퍼런스를 기반으로 코드 리뷰 가이드라인을 함께 작성했습니다. 이 글에서는 작성한 가이드라인을 공유해 보겠습니다.
코드에 대해서만 이야기하세요
피드백에서 작성자와 관련된 내용을 배제하세요. 작성자가 피드백을 받아들이는 데에 도움이 됩니다. 또한 ‘누가 원인이었나’와 같은 불필요한 논의를 방지할 수 있습니다.
상대방의 의견을 존중하세요
나는 동의하지 않는 의견일지라도, 상대방은 좋은 뜻으로 고민 끝에 의견을 표현했음을 기억하세요.
(자부심 있는 개발자라면 자신의 의견이 더 좋다고 믿기 쉽습니다. 내가 그 자부심 있는 개발자라면 나와 대화하는 다른 개발자 역시 나와 같음을, 상대방이 자부심 있는 개발자라면 그가 강하게 의견을 낼 때 그 안에 좋은 의도가 있음을 믿읍시다.)
상대방이 이해하기 쉽게 커뮤니케이션하세요
내가 아닌 상대방을 기준으로 설명해야 합니다.
더불어서, 코드와 PR을 작성하게 된 맥락을 설명한다면 리뷰어가 코드를 더 잘 이해할 수 있게 도울 수 있습니다. (내용이 충실한 이슈 티켓으로 설명을 대체해도 좋습니다.)
가급적이면 제안과 함께 피드백하세요
개선이 필요하다고 생각하는 코드에 대해, 막연하게 수정을 요구하기보다는 제안을 통해 동료를 도와주세요.
꼭 개선돼야 한다고 생각하지만 대안이 떠오르지 않을 때는 다른 동료에게 도움을 구해 함께 고민하는 것이 좋습니다.
적용 여부를 판단하는 건 PR 작성자의 몫입니다
개선이 필요하다고 생각하는 부분에 대해서 코멘트를 남기는 자유가 리뷰어에게 있듯이, 적용 여부에 대한 판단의 자유 역시 작성자에게 있습니다. 적용하지 않기로 결정했다면 제안자에게 그 이유를 설명하는 것이 좋습니다.
짧은 코드보다 이해하기 쉬운 코드를 우선하세요
사람이 이해하기 쉬운 코드여야 미래의 자신 및 동료들이 정확하고 빠른 개발을 할 수 있고, 모바일 챕터가 숨고의 비즈니스 요구사항을 더 잘 지원할 수 있습니다.
합의한 컨벤션을 따르세요
서로의 코드 스타일이 똑같을 수는 없습니다. 하지만 팀에서 합의한 컨벤션이 있는 경우라면 그것을 따르세요. 비효율적으로 보이는 컨벤션이 있다면 팀과 함께 논의하세요.
리뷰하는 코드를 내가 작성한 것처럼 만들려고 하지 마세요
누구도 나와 똑 닮은 모습으로 코드를 작성할 수 없으며, 그렇게 강요해서도 안 됩니다. 우리는 컨벤션을 따르지만 똑같지는 않을 것입니다. 개인 취향에 해당하는 내용을 피드백하지 마세요.
자신이 실천하지 않는 것을 강요하지 마세요
우리는 품질이 좋은 코드를 만들기 위해 지켜야 할 많은 일들에 대해 잘 알고 있지만 작업 효율과의 균형을 맞추어 각자 우선순위를 정하고 작업합니다. 이 우선순위가 팀원의 코드를 리뷰할 때에도 동일하게 적용되도록 하세요. 자신이 그런 피드백을 할 자격이 있는지 살펴봐야 합니다.
결정하지 말고 제안하세요
하나의 목표를 달성하는 데에 방법이 여러 가지 있을 수 있다는 것을 항상 기억하세요. 팀원이 해당 구현을 선택한 이유가 있었음을 염두에 두고 피드백하세요. 요구하지 말고 질문하세요.
칭찬하세요
좋은 코드를 리뷰하게 된다면 칭찬하세요. 할만한 피드백이 없는 경우에는 “LGTM” 혹은 “모든 것이 좋다”라고 이야기하는 것도 좋습니다.
개인의 관점에서 작성한 의견임을 나타내세요
피드백할 때 개인의 관점에서 작성한 의견임을 나타내세요. 다수의 공통된 의견처럼 표현하지 않도록 주의하세요.
Bad: 코드를 너무 복잡하게 짜셨네요.
Good: 이 부분의 코드가 어떤 동작을 하는지 제가 이해하기엔 좀 어렵습니다.
작은 단위로 PR을 만드세요
코드 리뷰는 집중이 필요한 작업입니다. 큰 PR은 리뷰어에게 그만큼 더 에너지를 소모하게 만듭니다. 동료들이 당신의 코드를 리뷰하는 일을 도전적으로 받아들이게 하지 마세요.
겸손해지세요
모든 사람들의 코드는 개선될 여지가 있습니다. 당신은 완벽하지 않으므로 잘못할 수 있다는 점을 받아들이세요. 당신의 전문성과 신뢰성을 흠이 없고 완전한 코드에서 찾지 마세요. 실수를 인정하는 것이 당신을 프로페셔널하고 정직한 인간미 있는 사람으로 보이게 합니다.
당신과 코드를 동일시하지 마세요
당신의 코드에 대한 비판은 사람으로서의 당신에 대한 비판이 아닙니다. 당신의 가치를 당신이 작성한 코드에 결부시키지 마세요. 코드에 몇몇 흠이 있어도 당신은 소중한 동료입니다.
우리는 모두 같은 편임을 기억하세요
리뷰어로부터 피드백을 받았을 때, 항상 당신과 리뷰어는 같은 편이라는 것을 기억하세요: 우리는 더 좋은 제품을 만들기 위해 리뷰 합니다.
이케아 효과를 주의하세요
이케아 효과는 소비자가 스스로 만든 제품에 불 균형적으로 더 높은 가치를 부여하는 인지 편향입니다.
우리는 자신이 작성한 코드에 더 가치를 부여한다는 사실을 기억하세요. 수정 또는 삭제해달라는 피드백을 받았을 때 편향적으로 생각하지 않도록 주의해야 합니다.
OIR 구조를 활용해 보세요
아래 세 가지 내용을 중심으로 피드백을 작성하는 것이 건설적인 논의를 하는 데에 도움이 될 수 있습니다.
- 보이는 것(Observation): 객관적이고 중립적인 방식으로 보이는 것을 설명하세요.
- 영향(Impact): 보이는 것이 어떻게 영향을 미칠지 설명하세요.
- 요청(Request): 제안을 설명하세요.
여기까지가 챕터 구성원이 함께 작성한 가이드라인 입니다. 이 외에도 더 효과적인 코드 리뷰를 위해 외부 사례를 참고해 여러 실험들을 진행하고 있습니다. 다음에 기회가 된다면 실험과 그 결과들에 대해서 공유해 보겠습니다.
참고
