주로 책 "구글 엔지니어는 이렇게 일한다" 를 기반으로 작성되었습니다.
TL;DR
- 항시 코드 변경에 대해서는 다른 사람의 검토를 받고 읽는 대상에게 최적화해라
- 코드 리뷰는 지식을 공유하는 자리임을 인식해라
- 자동화 가능한 부분은 자동화 해라
- 정확성, 이해 용이성, 가독성 관점에서 리뷰해라
- 변경은 작게, 피드백은 빠르게
구글의 코드 리뷰 문화
코드 리뷰의 승인
- 다른 엔지니어(동료 리뷰어 및 해당 기능을 이해하고 있는 사람)로부터 정확성과 이해 용이성을 평가받는다. - 의도한 작업을 코드가 잘 수행하는지.
- 변경되는 코드 영역을 관리하는 코드 소유자로 부터 변경 코드가 적절하다는 승인을 받는다. - 구글에서는 코드 베이스가 트리 구조로 되어있고, 모듈별 혹은 디렉터리별 소유자들이 할당되어 있다.(
OWNERS 파일을 두어 소유자의 이름을 기록 ) 가독성 승인을 받는다. - 변경 코드가 해당 언어의 스타일과 모범 사례를 잘 따르고 조직에서 기대하는 방식으로 작성되었는지 검사. 해당 언어의 가독성 인증자 풀에서 선정하여 리뷰 요청
가독성 제도 - 코드 리뷰를 통한 표준 멘토 제도
구글에서 가독성 제도는 단순한 코드 가독성 이상을 의미합니다.
프로그래밍 언어 모범 사례를 전파하기 위한 구글 전사 차원의 '표준 멘토링 프로세스'를 지칭한다.
그리고 언어 관용어, 숙어, 코드 구조, API 설계, 공통 라이브러리의 올바른 사용법, 문서화, 테스트 커버리지 등의 전문 지식을 광범위하게 다룬다.
- 코드는 작성되는 횟수보다 훨씬 많이 읽힌다.
- 구글에서는 가독성을 위해서 문서로 정리된 일관된 표준 및 모범 사례를 제공한다. - 즉 가독성 제도는 이 표준들을 시행하고 전파하는 메커니즘
- 따라서, 일관성을 강화하고 정보 섬을 없애면서 코드베이스 전체를 일관되게 만들어 낸다.
- 이러한 전체적인 일관성을 가지게 되면 코드의 하는 일에 대해서만 집중하게 된다.
가독성 인증
구글에서 가독성 자격증은 일반적으로 언어별로 주어진다. 가독성 자격증을 받은 엔지니어 = 특정 프로그래밍 언어를 사용하여 구글의 모범 사례와 코딩 스타일에 맞는 명확하고 관용적이고 유지보수하기 쉬운 코드를 일관되게 작성하는 사람. 가독성 자격증을 얻고자 하는 엔지니어는 가독성 인증 프로세스를 통해 코드 변경에 대한 지속된 피드백을 통해 인증 프로세스를 무사히 졸업하면 정식으로 가독성 자격증을 수여 받는다.
코드 리뷰의 이점
- 코드 정확성
- 코드 이해 용이성
- 코드 일관성
- 심리적, 문화적 이점
- 지식 공유
- 코드 리뷰 자체의 기록화
코드 정확성
- 버그를 걸러내는 과정
- 리뷰어는 해당 변경에 적합한 테스트가 갖추어져있는지, 설계는 적절한지. 정확하게 동작하고 효출적인지 판단
- 정확성 평가는 주관적으로 흘러가지 않도록 일반적으로 작성자의 방식(설계 및 기능측면)을 존중해야한다
- 리뷰어가 선호한다는 이유로 다른 방식을 주장해서는 안된다.
- 대안을 제시하는것은 이해가 더 쉽거나(덜 복잡하거나) 기능을 개선하는(더 효율적인) 대안일 경우에만!
- 구글에서는 코드가 완벽하다 합의될 때까지 기다리는 것이 아니라 기존 코드를 개선한다고 인정되면 변경을 승인하도록 가이드한다
- 코드 리뷰는 결함에 대처하는 방어수단 중 하나 일뿐이고, 완벽 할 필요까지는 없다
코드 이해 용이성
- 작성자는 코드 변경을 본인 이외의 사람이 보는 것이므로 이해하기 쉽게 작성하는 것이 매우 중요
- 또한 리뷰어는 다른 관점으로 피드백을 제공하는 일
- 리뷰어는 코드가 잘 이해되지 않는다면, 질문을 던져보는 것이 좋다
- 작성자는 비판이 있다고 꼭 기존 접근법이나 로직을 바꿔야 하는것은 아니지만, 주석을 추가하거나 기존 로직에 대해 고민하여 이해가 쉽도록 해야 할 필요는 있다
코드 일관성
- 규모가 커질게 되면 작성된 코드는 다른 누군가가 이용하게 되고 다른 사람이 유지보수 하게 된다 (즉 수많은 사람이 본인이 작성한 코드를 읽고 이해해야 한다)
- 반대로 본인이 다른 사람이 작성한 코드를 리팩토링해야 할 수 있다
- 코드가 일관된 표준을 따르면 쉽게 이해되고 유지보수 될 수 있다 (코드는 단순해야 한다)
- 따라서, 가독성 승인은 이러한 유지보수성을 위해 존재한다
- 때로는 일관성을 위해 기능성을 희생해야 할 수도 있다
심리적, 문화적 이점
- 코드리뷰는 작성자에게 자신이 작성한 코드에 대해 자신의 것 이 아닌, 조직의 공동 소유물 임을 인식하게 해주는 효과를 지닌다
- 코드리뷰가 없다면 자연스럽게 각자의 취향대로 설계 및 코드를 작성하게 된다
- 작성자는 다른 사람의 피드백을 받아들이고, 더 큰 이익을 위해 적절히 타협하도록 이끈다
- 코드에 대한 토론장을 만드는 효과
- 코드리뷰는 자신의 코드에 대한 비판적인 피드백에 대해 자칫 감정적으로 번질 수 있는 논쟁을 건전하게 만들어 준다 (당연히 리뷰어는 비난을 해서는 안된다)
- 심리적으로는 작성자의 결과물에 대한 검증과 인정을 해주는 효과
- 코드 작성시 스스로 한번 더 들여다보게 하는 효과
- 코드리뷰가 없다면 사소한 결함은 나중에 해결하겠다는 안이함을 가질 수 있지만, 이런 문제를 스스로 해결하게끔 해준다
지식 공유
- 코드 리뷰는 제안, 신기술 소개, 조언을 통해 도메인 지식을 전파하는 효과를 지닌다 (
FYI ) - 또한 리뷰어도 변경에 대한 특정 방식을 선택한 이유를 물어보면서 자연스렵게 정보 교환 및 지식 공유가 된다
- 코드 리뷰는 엔지니어들끼리 서로 교류하며 다양한 코딩 기법에 대한 정보를 교환 하는 중요한 수단이다 (일례로 대규모 리팩터링을 통해 새로운 패턴을 알리는 자리로 자주 활용)
- 코드 리뷰 자체의 기록으로 과거 변경에 대해서 좀 더 자세히 알 수 있다
코드 리뷰 모범 사례
코드 리뷰를 무리 없이 확장할 수 있도록 프로세스를 날렵하게 유지하는 방법
공손하게 전문가 답게
- 일반적을 리뷰어들은 작성자가 선택한 방식을 존중하고 오직 그 방식에 결함이 있을 때만 대안을 제시해야 한다
- 대안을 제시하는 단계는 코드 리뷰가 아니라 설계 단계에서 충분히 이루어져야 한다!
- 작성자가 다른 대안 중 특별히 우수한 게 없음을 설명한다면 취향을 받아들여야 한다
- 리뷰어가 결함이 있음을 발견하면 배움의 기회로 받아들여라. (모든 논평은 철저하게 전문적으로!)
- 리뷰어는 작성자의 방식에 대해 성급히 결론을 짓지 않게 주의해라
- 작성자의 방식이 잘못되었다고 가정하기 전 그렇게 처리된 이유를 물어봐야 한다.
- 리뷰어는 신속하게 피드백한다.
- 구글의 경우 24시간 내에 피드백이 오도록 한다
- 그 안에 피드백을 하지 못할거 같다면, '변경을 확인했고, 최대한 조속히 검토해보겠다' 와 같은 응답을 해줘야 한다
- 너무 단편적인 피드백은 삼가해라.
- 작성자도 전문가답게 코드를 작성해야 한다
- 본인이 선택한 방식에 대해 제기된 질문에 대해 설명할 준비를 해두어야 한다
- 코드를 이해하기 쉽고 유지보수 쉽게 만들어야 할 책임이 있다
- 리뷰어의 댓글을 모두
TODO item 으로 취급해야 한다- 모든 의견을 의문 없이 수용할 필요는 없지만 고민은 해봐야 한다
- 동의하지 않는 의견일 시 그 사실과 이유에 대해 공유할 필요가 있다
- 양측 모두 대안을 제시할 기회를 준다
- 작성자와 리뷰어 모두 배움의 기회임을 명심한다
작게 변경하기
- 코드 리뷰 프로세스를 날렵하게 만들어주는 가장 중요한 방식은 변경을 작게 만드는 것이다
- 즉 코드 리뷰는 단 하나의 문제만을 다루는 게 가장 이상적이다
- 리뷰어는 큰 변경에 대해서는 거부할 권한이 있다
- 큰 변경은 작성자, 리뷰어 모두에게 큰 시간을 뺏는 행위이다
- 큰 기능에 대해서는 작은 변경들로 나누도록 하자
- 초기의 작은 리뷰는 잘못된 길로 멀리갔다가 돌아오는 비용을 낮춰준다
변경 설명 잘쓰기
- 어떤 종류의 변경인지 자세히 설명한다.
- 코드 내에도 주석과 같은 방식으로 설명을 달아서 설명해야 할 필요도 있다
- 일반적으로 주석은 일부 코드가 존재하는 이유를 설명할 때 유용하며 일부 코드가 수행하는 작업을 설명 해서는 안 된다. (예외: 정규 표헌식 or 복잡한 알고리즘과 같은 코드)
- 코드 리뷰 과정에서도 처음 코드와 달라지는 점은 변경 설명과 주석에도 반영해야 한다
리뷰어는 최소한으로
- 구글에서의 대부분의 코드 리뷰는 한 명의 리뷰어만으로 진행 : 정확성 승인, 소유자 승인, 가독성 승인을 한 사람이 수행할 수 있게 허용해두었다
- 리뷰어가 추가 될때마다 결국에는 수확 체감으로 이어진다
- 물론 때에 따라서는 여럿이 검토하는 것이 좋은 변경도 있다 : 각 리뷰어들이 다른 관점에서 바라보도록 역할 조율 필요
가능한 한 자동화
- 코드 리뷰는 결국 사람이 주도하는 프로세스이다
- 하지만, 자동화할 수 있는 요소는 자동화를 해라
- 테스트, 린터, 포맷터
코드는 부채다
존재만으로 어느 순간 누군가가 유지보수해야 할 대상이 된다.
건강한 코드 리뷰 문화
- 코드는 주관적으로 작성해서는 안되고 객관적 일관적으로 작성하자
- 모든 변경에 다른 사람의 검토를 받고 읽는 대상에게 최적화하자
- 변경에 대해서 잘 설명하자
- 코드 리뷰는 지식을 공유하는 자리임을 인식
- 자동화 가능한 부분은 자동화 해라
- 정확성, 이해 용이성, 가독성 관점에서 리뷰
- 변경은 작게, 피드백은 빠르게
- 라인 수에 초점을 맞추기보다는 하나의 PR은 하나의 책임을 가지도록 하자
Ref