효과적인 코드 리뷰 방법에 대한 가이드

💡 해당 문서에서는 효과적인 코드리뷰 방법에 대한 가이드를 제공합니다.

개요

효과적인 코드리뷰 방법을 습득하여 나와 내 팀, 그리고 기술 조직이 더 잘 성장할 수 있도록 노력해봅시다.

 

코드 리뷰의 이점

• 코드 리뷰를 통해 소프트웨어 버그를 예방할 수 있습니다.
• 코드 리뷰는 작성자 외의 누군가가 변경을 살펴볼 수 있는 첫 번째 기회입니다.
• 코드 리뷰를 통해 일관된 코드베이스를 갖출 수 있습니다.
• 코드 리뷰는 소프트웨어 엔지니어에게 코드는 ‘자신의 것’이 아니라 협업을 통해 만들어지는 ‘조직의 공동 소유물’임을 인식시켜 줍니다.
• 코드 리뷰를 통해 지식을 공유할 수 있습니다.

 

---

코드 리뷰 모범 사례

공손하고 전문가답게

리뷰어

• 리뷰어들은 작성자가 선택한 방식을 존중하고 오직 그 방식에 결함이 있을 때만 대안을 제시해야 합니다.
• 작성자가 다른 대안 중 특별히 더 우수한 게 없음을 설명할 수 있다면 리뷰어들은 작성자의 취향을 받아들여야 합니다.
• 작성자가 선택한 방식에서 결함을 찾게 되면 작성자와 리뷰어 모두 배움의 기회로 생각하면 됩니다.
• 리뷰어는 작성자의 방식에 대해 성급히 결론짓지 않게 주의해야 합니다. 그 방식이 잘못되었다고 가정하기 전에 그렇게 처리하게 된 이유가 무엇인지부터 물어보는 게 좋습니다.
• 리뷰어는 신속하게 피드백 해야 합니다. 24시간 내에 코드 리뷰가 불가능 할 것 같은 경우 리뷰어는 ‘변경을 확인은 했고, 최대한 조속히 검토해보겠다’라고 응답해주는 게 좋습니다.

작성자

• ‘나'와 ‘나의 코드'를 동일시하지 말고, 내가 제안한 변경은 혼자의 것이 아닌 팀의 소유임을 잊지 마세요.
• 여러분이 선택한 방식에 대해 제기된 질문들에 흥분하지 말고 왜 그렇게 처리했는지 설명할 준비를 미리 해둬야 합니다.
• 코드를 이해하기 쉽고 유지보수가 쉽게 만드는 일도 작성자의 책임임을 기억하세요.
• 코드 리뷰 과정에서 리뷰어가 단 댓글은 모두 할 일(Todo item)로 취급해야 합니다.
• 댓글을 의문 없이 수용할 필요는 없습니다만, 적어도 고민은 해봐야 합니다.
• 동의하지 않는 댓글이라면 리뷰어에게 그 사실과 이유를 알려주세요. 그리고 양측 모두 대안을 제시할 기회를 준 다음에야 완료 처리해야 합니다.
• 리뷰어의 의견과 다르지만 토론을 매끄럽게 이어나가고 싶을 때 유효한 방법이 하나 있습니다. 대안을 제시하고 리뷰어에게 한번 더 살펴봐달라고 부탁하는 것입니다.
• 코드리뷰는 작성자와 리뷰어 모두에게 배움의 기회임을 기억하세요. 이 점만 잊지 않으면 의견 충돌도 감정싸움으로 번지지 않을 것입니다.
• 여러분이 소유한 코드베이스를 외부의 누군가가 변경하려는 경우에도 제안자의 견해에 수용적인 자세로 응해야 합니다.
• 제안된 변경이 코드베이스를 개선해주는 한 여러분은 ‘마땅히 개선해야 할 점을 제안해줘서 감사합니다’라며 제안자에게 감사를 표해줘야 합니다.

작게 변경하기

작성자

• 리뷰어에게나 작성자에게나 코드 리뷰는 단 하나의 문제만을 다루는 게 가장 이상적입니다.
• Pull Request 작업 단위가 크면 리뷰하는 데도 그만큼 시간이 걸리니 작은 변경은 작성자가 기다려야 하는 시간을 줄여주는 효과도 있습니다.
• 작은 변경이라 하면 일반적으로 변경되는 코드가 약 200줄 이하라는 뜻입니다.
• 작은 변경은 리뷰어의 부담을 줄여줍니다.

변경 설명 잘쓰기

작성자

• Pull Request 설명의 첫 줄은 어떤 종류의 변경인지를 잘 요약해야 합니다.
• 구체적으로 무엇을 왜 변경하는지 알려주는 자세한 설명도 필요합니다.
• 만약 리뷰어가 코드를 이해하지 못한다면 비록 올바르게 동작하는 코드일지라도 구조를 개선하거나 주석을 더 잘 달아놔야 한다는 신호일 수 있습니다.
• 코드 리뷰를 거치면서 처음 코드와 달라지는 점은 변경 설명과 코드 주석에도 반영해야 합니다.
• 코드 리뷰는 지금 당장만이 아니라 후대를 위해 현재 하고 있는 일을 기록하는 행위입니다.

리뷰어는 최소한으로

• 소프트웨어 업계 차원에서는 물론 엔지니어 개개인도 다른 영역의 엔지니어들로부터 더 많은 피드백을 받아보려는 (그리고 그들 모두가 동의해주길 바라는) 경향이 있습니다. 하지만 리뷰어가 한 명 추가될 때 마다 새로운 시각이 한 스푼씩 더해지며, 결국 수확 체감(diminishing returns)으로 이어집니다. 리뷰어를 추가해서 얻는 가치보다 비용이 훨씬 빠르게 증가하여 금세 역전됩니다.

가능한 한 자동화하기

• 코드 리뷰 프로세스 중에서 자동화할 수 있는 요소가 있다면 자동화 하세요. 기계적인 작업을 찾아서 도구에 맡기면 투자한 만큼 거두게 될 것입니다.
• 자동화는 코드 리뷰 프로세스에 도움됨은 물론이고 리뷰어가 코딩 컨벤션이나 포맷팅보다 더 중요한 문제에 집중하도록 도와줍니다.

---

참고 문서

구글 엔지니어는 이렇게 일한다 - YES24

abseil / Software Engineering at Google