이번에 네이버 부스트캠프 챌린지에 합격하면서 피어 세션을 진행합니다. 진행하면서 코드 리뷰에 대해 정의와 목적, 체크리스트 등을 작성해 코드 리뷰할 때 놓치는 부분이 없게, 근거를 세워 정확한 의도로 리뷰를 할 수 있게 이 글을 작성했습니다.
코드 리뷰란?
간단히 얘기해서, 본인이 아닌 다른 사람이 작성한 코드를 공유/검토하는 과정입니다.
이는 단순히 실수를 찾기 위한 과정이 아니라, 코드와 제품의 품질을 유지하고 개선하기 위한 중요한 절차입니다.
목적
다양한 글들을 읽어보니 아래 3개로 간추릴 수 있습니다.
- 코드 품질을 높임 : 효율적인 문법, 컨벤션-네이밍 등
- 코드 작성자의 실수를 방지 : 오타 등
- 팀원 간의 지식을 공유 : 작성자의 의도(Why), 해결 아이디어, 프로세스 작성 및 다이어그램 작성 등
이를 통해 더 나은 코드베이스를 유지하고, 개발자들이 서로의 작업을 이해할 수 있도록 돕습니다.
코드 리뷰 접근법
코드 리뷰의 효과적인 방법론을 이해하기 위해서는 작성자의 역할, 리뷰어의 접근, 협력적인 코드 리뷰 문화, 리뷰어 역할의 분산 등을 고려해야 합니다.
코드 리뷰의 본질
목적과 본질은 위에서 작성했지만, 단순히 실수를 예방하기보다는 코드 품질을 향상시키고 팀원들과 지식을 공유하는 것도 리뷰의 본질에 있어서 중요합니다.
이를 위해서는 코드 리뷰를 실수 찾기 게임으로 여기지 않고, 협력적이고 건설적인 과정으로 이해해야 합니다.
작성자의 역할
코드 작성자는 리뷰 받는 사람(Reviewee)를 뜻합니다.
작성자는 자신의 코드 작업을 리뷰어에게 명확하게 설명해, 리뷰어가 쉽게 이해할 수 있도록 해야 합니다.
다시 말해, 리뷰어가 작성자의 의도를 명확히 파악할 수 있게 해, 소통 비용이 늘어나는 리뷰가 아닌 실제로 코드 품질을 효율적으로 향상시킬 수 있는 피드백을 제공받을 수 있습니다.
리뷰어의 접근
리뷰어는 코드 리뷰를 통해 작성자의 코드를 나에게 대입해 실수 예방 및 코드 품질을 올리기 위한 방법론, 의도에 대해 바람직하다면 칭찬하는 접근법 등을 써야합니다.
- 코드의 핵심 영역을 검토 : 가장 핵심부터 파악
- 바람직한 변화를 칭찬 : 협력적인 의도를 보여주기 위해
- 바람직하지 않은 변화에 대한 수정 제안을 통해 협력적인 분위기를 조성
- 리뷰어 역할 분산 : 리뷰가 특정 사람에게 집중되지 않도록 함. 다양한 시각에서 코드가 검토될 수 있음.
이를 통해 코드 리뷰는 작성자에게 스트레스가 아닌, 성장의 기회로 작용하게 됩니다.
리뷰어는 작성자의 노력을 인정하고, 작성자는 리뷰어의 의견에 대해 인정하게 됩니다.
그렇게 된다면 서로의 학습이 원할하게 이루어져 협력적인 문화가 정착하고, 궁극적으로 문제 해결이 효율적으로 진행됩니다.
칭찬 예시
그렇게 말은 했지만 저도 칭찬을 잘 하지 못해 예시를 가져와봤습니다.
- "이 부분 너무 좋은 것 같습니다. 버그가 해결됐는데 가독성도 좋아졌어요."
- "다들 미뤄두기만 했던 걸 작업해주셔서 감사합니다. 테스트 코드를 좀 보완할 수 있을 것 같은데 제가 작업해서 PR로 보내볼게요."
위와 같은 과정을 구글 코드리뷰 프로세스를 살펴보며 구글은 어떻게 프로세스를 진행시켰는지 관찰해보겠습니다.
구글의 코드 리뷰 프로세스
Developer의 역할
- 명확한 설명: 변경 사항과 왜?에 대한 의도를 명확히 설명.
- 하나의 변경 사항을 담은 CL(Changelist) 잘 작성하기 : 어떤 변경이 있었는가? 왜 이러한 변경을 했는가?
- 첫 줄엔 간단히 요약한 문장, 그 다음엔 상세 변경 사항 및 의도 작성.
- 잘못된 CL : Fix bug
- 적합한 CL : RPC: Remove size limit on RPC server message freelist. Servers like FizzBuzz have very large messages and would benefit from reuse.
- 피드백 수용: 리뷰어의 피드백을 적극적으로 수용하고 필요 시 협력해 문제를 해결.
- 코드가 비판받을 때 이를 개인적인 공격으로 받아들이지 말고, 도움을 주려는 시도로 이해.
- 충분한 테스트: 충분한 자동화 테스트를 포함해 코드 제출.
- 문서화: 관련 문서를 업데이트.
Reviewer의 역할
구글은 리뷰어의 역할을 더 강조한 듯 보였습니다. 아래는 코드 리뷰 프로세스입니다.
- 디자인: 코드가 시스템에 적합하게 잘 설계되었는가?
- 여러 코드 조각 간의 상호 작용이 적절한지, 이 변경이 코드베이스에 적합한지, 시스템과 잘 통합되는지, 지금이 이 기능을 추가할 적절한 시기인지 검토.
- 기능: 코드가 의도한 대로 동작하는가? 사용자에게 적절한가?
- 엣지 케이스, 동시성 문제, 사용자 관점에서의 검토 등도 고려.
- UI 변경이 포함된 경우, 실제로 CL의 동작을 확인하는 것이 중요.
- 복잡성: 코드를 더 단순하게 만들 수 있는가? 다른 개발자가 쉽게 이해하고 사용할 수 있는가?
- 불필요한 일반화 또는 현재 필요하지 않은 기능 추가 등 과도한 엔지니어링을 방지. 지금 필요한 문제를 해결하는 데 집중.
- 더 넓은 맥락을 파악해
- 테스트: 코드에 올바르고 잘 설계된 자동화 테스트가 있는가?
- 복잡성을 피하기.
- 명명: 변수, 클래스, 메서드 등의 이름이 명확한가?
- 주석: 주석이 명확하고 유용한가?
- 스타일: 코드가 컨벤션 - 스타일 가이드를 따르는가?
- 문서화: 관련 문서가 업데이트되었는가?
위의 프로세스를 따라가봐야합니다. 그 과정에서 가져야할 리뷰어의 태도는 아래와 같습니다.
- 코드의 품질 향상: 코드를 통해 제품의 전체적인 품질을 향상시키기 위해 노력.
- 명확한 피드백 제공: 명확하고 건설적인 피드백을 제공해 작성자의 성장 추구.
- 어떤 방식을 제안할 지, 왜 그렇게 바꿔야하는지 명확하게 제공해야함.
- 협력적 태도: 작성자와 협력해 문제를 해결하고, 긍정적인 코멘트를 통해 리뷰 문화를 개선.
- Bad: "동시성에서 얻을 수 있는 이점이 전혀 없는데 왜 여기서 스레드를 사용했나요?"
- Good: “여기의 동시성 모델은 내가 볼 수 있는 실제 성능 이점 없이 시스템에 복잡성을 더하고 있습니다. 성능 이점이 없으므로 이 코드는 여러 스레드를 사용하는 대신 단일 스레드로 하는 것이 가장 좋습니다.”
- 시간 내 피드백 제공: 가능한 한 빠른 시간 내에 피드백을 제공해 작성자의 진행을 방해하지 않도록 주의.
최적의 리뷰어 선택
코드 리뷰를 효과적으로 진행하기 위해서는 최적의 리뷰어를 선택하는 것이 중요합니다. 최적의 리뷰어는 작성한 코드에 대해 가장 철저하고 정확한 리뷰를 제공할 수 있는 사람입니다. 보통 코드 소유자가 최적의 리뷰어이며, 경우에 따라 다른 사람들에게도 검토를 요청할 수 있습니다.
대면 리뷰 및 페어 프로그래밍
페어 프로그래밍을 통해 작성한 코드라면 해당 코드는 이미 리뷰된 것으로 간주됩니다. 또한, 대면 리뷰는 리뷰어가 질문하고 변경 사항의 개발자가 대답하는 방식으로 진행되어, 더욱 깊이 있는 검토가 가능합니다.
체크리스트
마지막 결론을 내려보겠습니다. 체크리스트를 통해 가시적으로 나타내봤습니다.
- 설명/주석: 수정 설명이 명확하게 작성되었는가? 변경 사항과 의도가 충분히 설명되었는가?
- 의도: 왜 이렇게 설계했는가?
- 기능: 코드가 의도한 대로 동작하는가? 사용자에게 적절한가?
- 복잡성: 코드를 더 단순하게 만들 수 있는가? 다른 개발자가 쉽게 이해하고 사용할 수 있는가?
- 테스트: 코드에 올바르고 잘 설계된 자동화 테스트가 포함되어 있는가?
- 네이밍: 변수, 클래스, 메서드 등의 이름이 명확한가?
- 주석: 주석이 명확하고 유용한가?
- 스타일: 코드가 스타일 가이드를 따르고 있는가?
- 문서화: 관련 문서가 업데이트되었는가?
- 리뷰어 선택: 최적의 리뷰어를 선택했는가?
- 피드백: 리뷰어가 협력적이고 건설적인 피드백을 제공하고 있는가?
- 분산: 코드 리뷰가 특정 사람들에게만 집중되지 않도록 분산되고 있는가?
참고
