코드 리뷰는 작성자 이외의 사람이 코드를 검토하는 프로세스로, 주로 코드를 코드베이스에 반영하기 전에 수행한다. 코드 리뷰는 버그가 코드베이스로 침투하기 전에 잡아낸다처럼 확실하고 쉽게 납득되는 이점을 제공한다.
9.1 코드 리뷰 흐름
코드 리뷰는 소프트웨어 개발 단계 곳곳에서 이루어질 수 있다. 구글에서는 변경을 코드베이스에 커밋하기 전에 수행한다. 코드 리뷰의 최종 목표는 다른 엔지니어로부터 해당 변경을 적용해도 된다는 합의를 이끌어내는 것이다. 합의한 엔지니어는 좋아보임(LGTM)이라는 태그를 달아 의사를 표현한다.
구글이 코드리뷰 절차) 234p
코드는 부채다
코드는 존재만으로 어느 순간 누군가 유지보수해야 할 대상이 되어 버린다.
새로운 기능이 필요한 상황은 아주 흔하다. 하지만 개발을 시작하기 앞서 정말 새로운 기능이 맞는지 주의 깊게 살펴봐야 한다.
중복 코드는 작성하는 시간 자체도 낭비지만 그 코드가 아예 존재하지 않을 때보다 관리 비용이 날이 갈수록 더 늘어나곤 한다. 이상적으로는 중복 확인이 먼저 이루어져야 한다.
코드 리뷰 전에는 내린 설계를 번복하거나 재논의하는 자리여서는 안된다. 설계를 결정하는 데는 보통 시간이 걸린다. 설계 후보를 수차례 제안하고, API 리뷰 회의에서 토론하고, 프로토타입을 만들어보기도 한다. 따라서 코드 리뷰 과정 자체를 기존 결정을 다시 논의할 기회로 보아서는 안 된다.
9.2 코드 리뷰 @ 구글
구글에서는 어떤 변경이든 승인을 얻으려면 다음의 세가지 측면에서 리뷰를 통과해야 한다.
- 다른 엔지니어로부터 정확성과 이해 용이성을 평가 받는다. 의도한 작업을 코드가 적절히 수행하는지를 본다.
- 변경되는 코드 영역을 관리하는 코드 소유자로부터 변경 코드가 적절하다는 승인을 받는다.(코드베이스에 변경을 반영하려면 해당 디렉터리 소유자의 승인이 반드시 필요하다.)
- 가독성 승인을 받는다.
9.3 코드 리뷰의 이점
잘 설계된 코드 리뷰 프로세스와 코드 리뷰를 중요하게 다루는 문화가 주는 대표적인 이점으로
- 코드가 정확한지 확인해준다.
- 변경된 코드를 다른 엔지니어도 잘 이해한다.
- 코드베이스가 일관되게 관리된다.
- 팀이 소유권을 더 강하게 느낀다.
- 지식이 공유된다.
- 코드 리뷰 자체의 기록이 남는다.
9.3.1 코드 정확성
리뷰어는 일차적으로 변경된 코드의 정확성을 확인해주며 코드 리뷰가 주는 가장 확실한 이점이다. 한 연구에서 결함을 프로세스 초반에 잡아낼수록 나중에 발견해 고칠 때보다 시간이 덜 든다고 한다. 코드 리뷰에 들이는 시간은 테스트, 디버그, 회귀 테스트에 투입되는 시간을 줄여준다.
물론 코드 리뷰 프로세스 자체를 단순화하여 가볍게 유지해야 한다.는 거시 핵심이다. 무겁거나 확장하기 어렵다면 코드 리뷰를 지속할 수 없다.
정확성 평가가 주관적으로 흘러가지 않도록 하기 위해서 일반적으로 변경 작성자가 선택한 방식을 존중해야 한다. 리뷰어는 자신이 선호한다는 이유로 다른 안을 주장해서는 안 된다. 대안을 제시하는 것은 가능하지만 이해하기 쉽거나 기능을 개선하는 대안인 경우에만 그리해야 한다.
그리고 코드 정확성 검사는 도구를 사용하여 자동으로 수행할 수 있으나 이는 일반적으로 해당 변경이 의도대로 작동함을 보여준다. 하지만 새로운 코드가 이해하기 쉽고 세월이 흘러 코드베이스가 커져도 여전히 의미가 통할것이다. 라는 측면은 단순히 코드가 논리적으로 정확하다거나 이해되는지만 살피는 것으로 부족하다.
9.3.2 코드 이해 용이성
코드 리뷰는 일반적으로 작성자외의 누군가가 변경을 살펴볼 수 있는 첫 번째 기회이다. 코드는 작성되는 횟수보다 읽히는 횟수가 몇 배는 많으므로 이해하기 쉽게 작성하는 게 매우 중요하다. 코드의 정확성과 이해 용이성 검토는 다른 엔지니어가 LGTM을 주기 위해 평가하는 주요 기준이 된다.
9.3.3 코드 일관성
규모가 커지면 내가 작성한 코드를 결국은 다른 사람이 이용하게 되고 다른 사람이 유지보수하게 된다. 따라서 코드는 일정한 표준을 따라야 하며 그래야 조직 안에서 이해되고 유지보수될 수 있다. 너무 복잡해져서도 안 된다. 코드가 단순해야 다른 사람들이 이해하기 쉽고, 유지보수하기도 쉽다.
코드 리뷰 중 LGTM을 받은 상태와 가독성 승인을 분리한 이유는 유지보수성 때문이다.
코드는 일관되고 단순해야지 사람들이 쉽게 이해할 수 있고 리팩터링 도구가 더 쉽게 다룰 수 있다.
9.3.4 심리적, 문화적 이점
코드 리뷰는 문화적으로 중요한 이점을 제공한다. 소프트웨어 엔지니어에게 코드는 자신의 것이 아니라 협업을 통해 만들어지는 조직의 공동 소유물임을 인식시켜주는 효과이다. 코드리뷰는 작성자가 다른 사람의 피드백을 받아들이고, 또 더 큰 이익을 위해 적절히 타협하도록 이끌어준다.
자신의 코드에 대한 비판적 피드백이 달갑지 않은 것 역시 당연하다. 코드 리뷰는 이럴때 감정적으로 번질 수 있는 논쟁을 건전하게 만들어준다. 코드 리뷰가 제대로 작동한다면 작성자가 당연하게 여기던 가정이 틀릴 수 있음을 사전에 규정된 중립적인 방식으로 지적할 수 있다.
또 다른 심리적 이점은 검증이다. 뛰어난 엔지니어조차 가면 증후군을 겪거나 자기비판이 심할 수 있다. 코드 리뷰는 그들의 작업 결과를 검증하고 인정해주는 효과가 있다. 그리고 작성자들에게 자신의 코드를 한번 더 들여다보게 하는 효과가 생긴다. 코드 리뷰라는 장치가 없다면 수많은 사람이 자연스럽게 절차를 무시하려 들 것이다. 사소한 결함은 나중에 해결하겠다는 안일함으로 말이다.
9.3.5 지식 공유
리뷰 프로세스는 제안, 신기술 소개, 조언을 통해 리뷰어가 변경 작성자에게 도메인 지식을 전파하도록 이끌어준다. 코드 리뷰중 피드백을 주고 받는 과정에서 양방향 정보 교환이 이루어진다. 작성자는 물론 리뷰어도 새로운 기술이나 패턴을 배울 수 있다는 뜻이다.
리뷰를 통한 지식 공유는 지역, 국가, 프로젝트 경계에 구애받지 않고 코드베이스 구석구석의 모든 엔지니어에게 빠르게 전파된다.
9.4 코드 리뷰 모범 사례
9.4.1 공손하고 전문가답게
구글은 신뢰와 존중 문화를 조성하기 위해 심혈을 기울인다. 코드 이해 용이성과 요건을 충족시키려면 단 한 명의 엔지니어만 LGTM이라고 선언해줘도 충분하다. 하지만 리뷰하는 엔지니어들은 해당 변경이 이번 한 번의 리뷰만 통과하면 코드베이스에 반영될 수 있음을 잘 알고 있어 절대 가볍게 LGTM을 남발하지 않는다.
리뷰어들은 작성자가 선택한 방식을 존중하고 오직 그 방식에 결함이 있을 때만 대안을 제시해야 한다. 그리고 구글에서는 코드 리뷰 피드백이 24시간 내에 올 거라 기대하기 때문에 신속하게 피드백을 해주어야 한다.
9.4.2 작게 변경하기
코드 리뷰 프로세스를 날렵하게 가져가기 위해 가장 중요한 모범 사례를 보면 변경을 작게 만드는 것이다. 리뷰어나 작성자에게나 코드 리뷰는 단 하나의 문제만을 다루는 게 가장 이상적이다. 구글은 거대한 변경을 지양하며, 리뷰어는 큰 변경에 대해서는 거부할 권한이 있다.
구글에서는 코드 리뷰가 대부분 작게 이루어지기 때문에 거의 모든 변경이 단 한 사람으로부터만 리뷰를 받는다. 이렇게 하지 않으면 프로세스 자체를 확장할 방법이 없다.
9.4.3 변경 설명 잘쓰기
변경 설명의 첫 줄은 어떤 종류의 변경인지를 잘 요약해야 한다. 첫 줄이 변경 전체를 요약해주지만, 구체적으로 무엇을 왜 변경하는지 알려주는 자세한 설명 역시 필요하다.
만약 리뷰어가 코드를 이해하지 못한다면 비록 올바르게 동작하는 코드일지라도 구조를 개선하거나 주석을 더 잘 달아놔야 한다는 신호일 수 있다.
9.4.4 리뷰어는 최소한으로
구글에서 이루어지는 대부분의 코드 리뷰는 정확히 한 명의 리뷰어만으로 진행된다. 리뷰어가 한 명씩 추가될 때마다 새로운 시각이 한 스푼씩 더해지며, 결국 수확 체감으로 이어진다. 첫 번째 LGTM이 가장 중요하며 두 번째부터는 크게 신경 쓸 만큼의 가치가 없다는 걸 발견했다. 리뷰어를 추가해서 얻는 가치보다 비용이 훨씬 빠르게 증가한다.
9.4.5 가능한 한 자동화하기
코드 리뷰는 사람이 주도하는 프로세스라서 사람이 주는 피드백이 중요하다. 하지만 프로세스 중 자동화할 수 있는 요소가 있다면 자동화하자, 기계적인 작업을 찾아서 도구에 맡기면 투자한 만큼 거두게 될 것이다.
자동화는 코드 리뷰 프로세스에 도움됨은 물론이고 리뷰어가 포맷팅보다 더 중요한 문제에 집중하도록 도와준다.
9.5 코드 리뷰 유형
9.5.1 그린필드 코드 리뷰
그린필드 리뷰는 완전히 새로운 코드를 대상으로 하는 가장 드문 유형의 코드 리뷰이다. 대상 코드가 오랜 기간 존속될 수 있는지를 평가하기에 가장 중요한 기회이다.
9.5.2 동작 변경, 개선, 최적화
구글에서 이루어지는 대부분의 변경은 코드베이스 안의 기존 코드를 수정한다고 볼 수 있다. API 수정, 기존 구현 개선, 성능 최적화 등이 이루어진다. 이 경우에도 그린필드 리뷰의 지침이 그대로 적용된다. 꼭 필요한 변경인지, 코드베이스를 개선하는지를 살펴야 한다. 가장 바람직한 변경의 멋진 예로 죽은 코드나 낡은 코드 제거가 있다. 이는 코드베이스를 전반적으로 건실하게 만드는 아주 멋진 방법이다.
9.5.3 버그 수정과 롤백
버그 수정시 다른 문제까지 묶어 처리하고픈 마음을 꾹 눌러야 한다. 여러 주제가 섞이면 리뷰할 게 많아지고, 회귀 테스트나 롤백을 훨씬 어렵게 만든다. 버그 수정은 온전히 그 버그를 잡는 데만 집중하자.
또 잠재적으로 롤백을 유발할 수 있는 모든 변경은 가능한 한 작고 원자적이어야 한다. 그래야 혹시 롤백으로 인해 해당 코드를 사용하던 다른 모듈이나 프로젝트들이 망가지는 문제를 막을 수 있다.
9.5.4 리팩터링과 대규모 변경
구글에서는 많은 변경이 자동으로 생성된다. 변경의 작성자가 사람이 아니라 기계라는 뜻이다. 기계가 생성한 변경도 리뷰가 필요하다. 어느 리뷰와 다를바 없지만 댓글을 다는 것은 지양하라고 안내한다.
9.6 마치며
코드리뷰는 구글에서 가장 중요하고 핵심적인 프로세스에 속한다. 따라서 작은 변경, 빠른 피드백과 반복 같은 모범 사례가 엄격히 지켜져야 한다. 그래야 개발 만족도와 생산 속도가 유지된다.
9.7 핵심정리
- 코드 리뷰는 지식을 조직 전체에 공유하는 데 중요한 역할을 한다.
- 코드 리뷰 프로세스를 확장하려면 자동화가 아주 중요하다.
- 코드 리뷰 자체가 변경 이력이 되어 준다.