코드 리뷰는 소프트웨어 개발에서 없어서는 안 될 요소이다. 특히 성장하기 위해 매우 중요하다. 코드 리뷰의 가장 큰 목적은 코드베이스의 가독성과 유지보수성 개선인데 이것은 리뷰 프로세스가 뒷받침해줘야 가능한 이야기이다.
구글의 자체 시스템인 Critique를 예로 삼아 어떻게 해야 성공적인 코드리뷰 도구를 도입할 수 있는지를 알아보자. Critique는 리뷰어와 작성자에게 코드 리뷰용 화면과 댓글 기능을 제공한다. 또 변경에 점수를 매겨 코드베이스에 체크인할 코드를 선별하는 게이트키핑도 지원한다.
19.1 코드 리뷰 도구 원칙
Critique 도구가 성공적인 이유는 코드 리뷰는 개발자 워크플로의 핵심이다라는 구글 개발 문화가 Critique에 녹아 있기 때문이다.
- 간결성 - Critique의 UI는 불필요한 선택을 줄여 코드 리뷰를 쉽게 진행할 수 있는 매끄러운 인터페이스를 제공한다.
- 신뢰 제공 - 변경들을 구글 직원 모두가 보고 리뷰할 수 있도록 공개함으로써 신뢰를 높일 수 있다.
- 익숙한 소통 방식 - 사용자가 댓글로 원하는 내용을 어떻게 수정하는 게 좋을지 제안할 수 있도록 하였다.
- 워크플로 통합 - Critique은 다른 소프트웨어 개발 도구들에 통합할 수 있는 통합 포인트를 다양하게 제공한다.
19.2 코드 리뷰 흐름
코드 리뷰는 소프트웨어 개발 단계 곳곳에서 이루어진다. Critique 리뷰는 변경이 코드베이스에 커밋되기 전에 진행한다.(프리커밋 리뷰)
- 변경 생성 - 작성자가 코드베이스의 변경을 생성하고, 스냅샷을 Critique에 업로드 -> 자동 코드 분석 실행
- 리뷰 요청 - Critique이 디프(변경으로 인해 달라질 코드)와 코드 분석 결과를 보여준다. 작성자가 만족한다면 리뷰어에게 리뷰 요청을 한다.
- 댓글 달기 - 리뷰어가 Critique에서 변경 사항을 열어보고 댓글 초안 작성’미해결’ -> 선택사항, 정보차원의 댓글은 ‘해결’
- 변경 수정 및 댓글에 답하기 - 작성자가 피드백을 확인하여 변경을 수정하고 새로운 스냅샷을 업로드(최소한 미해결 댓글에는 모두 대응해야 한다.)
- 변경 승인 - 리뷰어가 변경의 모습이 맘에 들면 변경을 승인하고 ‘좋아 보임’이라고 표시한다.
- 변경 커밋 - 변경이 승인되었음을 Critique이 알려주면 작성자가 커밋 프로세스를 시작할 수 있다.
19.2.1 알림 기능
위 단계를 하나씩 통과할 때마다 Critique은 다른 지원 도구들에서 이용할 수 있게끔 알림 이벤트를 보내준다. 이 알림 덕분에 Critique은 코드 리뷰라는 본연의 기능에 집중하면서도 개발자 워크플로에 녹아들 수 있다.
19.3 1단계: 변경 생성
Critique에서 변경 디프를 보여주면 작성자에게는 리뷰어 역할을 스스로 해볼 기회가 주어진다. 또 가벼운 수정은 Critique 안에서 해결할 수 있고, 적절한 리뷰어를 추천해주기도 한다.
19.3.1 디프, 차이점 보여주기
코드 리뷰 프로세스의 핵심은 코드 변경사항 자체를 이해하는 것이다. 좋은 코드 리뷰 도구라면 반드시 변경의 디프를 효과적으로 보여줘야 한다.
[Critique이 제공하는 기능]
- 구문강조
- 상호참조
- 공백 무시 옵션 제공
- 인트라라인 디프(줄바꿈이나 공백과 상관없이 문자 수준으로 분해해 차이를 보여줌)
- 이동 검출(코드 덩어리가 단순 이동만 한 경우에 ‘이동했음’ 이라고 표시됨)
사용자는 디프를 다양한 모드로 바꿔가며 볼 수 있다. Critique은 변경에 의해 달라지는 아티팩트의 디프도 제공할 수 있게끔 커스텀 도구도 다양하게 지원한다.
19.3.2 분석 결과
변경의 스냅샷을 업로드하면 코드 분석이 시작된다. Critique은 변경 페이지에 분석 결과를 함께 보여준다.
분석기 설명 (522p)
19.3.3 긴밀한 도구 통합
구글은 Piper를 토대로 다음과 같은 다양한 도구를 만들었다.
- Cider - 클라우드에 저장된 소스 코드를 편집하는 온라인 IDE
- Code Search - 코드베이스의 코드를 검색하는 도구
- Tricoder - 정적 분석 결과를 보여주는 도구
- Rapid - 일련의 변경을 포함하는 바이너리들을 묶어 배포하는 릴리스 도구
- Zapfhahn - 테스트 커버리자 계산 도구
Critique을 개발자 작업 공간에 긴밀이 통합할 수 있던 이유는 작업 공간이 어디서든 접근할 수 있는 FUSE 기반 파일 시스템에 저장되어 있는 덕분이다.
19.4 2단계: 리뷰 요청
변경의 상태가 맘에 들면 같은 양식을 작성해 리뷰를 요청한다. 이때 리뷰어를 선정해야 한다. 구글은 코드 리뷰 요청 메일을 발송할 때 별칭을 이용하곤 한다. 별칭을 이용하면 GwsQ라는 도구가 별칭별 설정을 보고 적절한 리뷰어를 할당해준다.
Critique 역시 변경을 승인하기에 충분한 수의 리뷰어 목록을 제안해주는 기능을 제공한다. 리뷰어 선정시 고려되는 요인으로는
- 수정되는 코드의 소유자는?
- 해당 코드를 가장 잘 아는 사람은?
- 리뷰할 여건이 되는 사람은?
- GwsQ 별칭 설정
19.5 3~4단계: 변경 이해하고 댓글 달기
19.5.1 댓글 달기
댓글 달기는 Critique 사용자가 변경 살펴보기에 이어 두 번째로 많이 하는 작업이다. 리뷰는 누구나 달 수 있고, 개인별 상태를 통해 리뷰 진행 상황을 추적할 수 있다. (526p)
19.5.2 변경의 상태 이해하기
Critique은 변경이 3~4단계를 반복하는 과정에서 정확히 어디 위치하는지를 명시해주는 메커니즘을 몇 가지 제공한다.
‘누구 차례’ 기능
리뷰 프로세스의 속도를 높이려면 내가 무언가를 해야 할 차례가 되었을 때 바로 알 수 있어야 한다. Critique은 변경별로 관심 집합을 관리하여 다음 차례가 누구인지 정의하는 데 도움을 준다.
관심 집합은 변경의 진행을 막고 있는 사람들로 구성된다.
대시보드와 검색 시스템
528p
19.6 5단계: 변경 승인(변경에 점수 매기기)
구글에서 변경에 점수 매길 때 고려하는 요소
- LGTM - 리뷰어가 변경을 컴토한 결과 우리 표준에 부합하며 미해결 댓글 해결 후 커밋해도 좋다라며 찍는 도장이다.
- 승인
- 미해결 댓글 수
LGTM이 하나 이상, 충분한 수의 승인, 미해결 댓글이 0개라면 작성자가 변경을 커밋할 수 있다.
등급 체계는 코드 리뷰 문화에 긍정적인 영향을 줬다. 리뷰어가 변경을 거부하려면 반드시 유용한 피드백을 함께 줘야 한다.
19.7 6단계: 변경 커밋
Critique은 변경 커밋 버튼을 제공하여, 터미널에서 별도 명령을 실행할 필요가 없도록 해준다.
19.7.1 커밋 후: 변경 이력 추적
Critique의 핵심은 소스 코드를 변경해 리포지터리로 커밋하기 전에 리뷰를 하는 것이다. 하지만 변경 이력을 둘러보는 도구로도 많이 쓰인다. 구글에서는 누구든 파일의 변경 이력을 볼 수 있다. 개발자들은 코드가 어떻게 진화되었는지 배우고 코드 리뷰 데이터를 취합하여 학습 자료를 만들어 내기도 한다.
19.8 마치며
Critique은 매끄러운 리뷰 경험을 선물하기 위해 다양한 기능을 구현하고 다른 도구들을 통합했다. 코드 리뷰에 쓰는 시간은 코드를 생산하지 못하는 시간이기 때문에 리뷰 프로세스를 최적화하면 그만큼 회사의 생산성이 개선된다.
19.9 핵심 정리
- 신뢰와 소통이 코드 리뷰 프로세스의 핵심이다.
- 다른 도구와의 긴밀한 통합이 멋진 코드 리뷰 경험을 선사하는 핵심이다.
- 관심 집합 명시 같은 작은 워크플로 최적화로도 인터페이스가 더 명확해지고 사용자들에게 더 살갑게 다가갈 수 있다.