Code Review in Google

2018-10-02 에 작성하고, 2020-03-09 14:21:00 에 업데이트한 문서입니다. ✅ — Code Review — 3 min read

Modern Code Review: A Case Study at Google

위 문서를 요약 - 번역합니다.

INTRODUCTION

Peer Code Review는 코드 작성자가 아닌 동료 개발자들이 직접 코드를 검사하는 방식으로, 소프트웨어 프로젝트의 질을 향상시키는 것으로 여겨졌습니다. 최근들어 많은 기관들이 좀더 가벼운 방식의 코드 리뷰를 받아들이고 있습니다.

1) informal (Fagan 방식의 정반대)

2) tool 기반

3) async

4) 코드 변경점만 리뷰하는 방식

코드 리뷰는 Google에서 필수 프로세스입니다. 구글의 코드리뷰과정은 10년 이상 개선되어왔고, 25,000명 이상의 개발자가 매일 20,000 번 이상의 코드 변경하는 과정에서 적용되고 있습니다.

Code Review Processes and Contexts

Code Inspection.

코드리뷰에서 가장 형식화된 과정중 하나입니다. 코드 검사의 목적은 작성자와 리뷰어들이 함께 모여 코드 변경점에 대해서 결함(defects)이 없는지 조사하는 것입니다.

Asynchronous review via email.

2000대 말에는, 대부분의 OSS가 비동기, 원격 코드 리뷰의 형태를 채택했습니다. 이는 메일링 리스트나 이슈트래킹 시스템을 사용하여 패치를 보내는 방식이었습니다.

Tool-based review.

패치 리뷰 과정을 좀더 짜임새 있게 만들기 위해서, OSS 등에서 여러 tool 이 등장했습니다. 이러한 툴은 리뷰 과정의 실행 과정을 돕습니다.

1) 패치를 작성한 사람이 코드 리뷰 툴에 패치를 제출합니다.

2) 리뷰어는 제안된 코드 변경점의 diff를 볼 수 있고

3) 특정 줄에 대해서 쓰레드를 만드는 형식으로 토론할 수 있습니다.

4) 작성자는 리뷰어의 코멘트에 대해서 변경점을 제안할 수 있습니다.

이러한 피드백 사이클은 모두가 만족할 때까지 혹은 패치가 버려질때까지 계속 됩니다. 이를 위해 Microsoft는 CodeFlow를 채택합니다. Google의 Chromium project는 Gerrit을 사용합니다. Gerrit은 리뷰어들의 명시적인 승인과 이 코드 변경이 빌드를 깨지 않는다는 확인 후에만 병합됩니다. Facebook의 코드리뷰시스템인 Phabricator는 리뷰어들이 변경점에 도전 하고 직접 커밋할 수 있도록 합니다. 물론 자동 정적 코드 리뷰 분석과 CI 툴도 제공합니다.

Pull-based development model.

Github의 pull request 과정에서는, 변경하고 싶은 게 있는 사람이 레포지토리를 fork 해서 fork 된 레포지토리에서 내용을 변경합니다. 이후에 이 변경점을 pull request 를 보내는데, pull request는 누구나 볼 수 있습니다.

Google에 던진 질문과 그에 대한 답

Google에서의 코드 리뷰 동기는 무엇인가?

Google에 코드리뷰를 최초로 도입한 사람(E라고 하자) 의 말에 따르면, 코드리뷰의 동기는 다른 사람들이 알아들을 수 있는 코드를 쓰도록 하기 위해서 였다고 합니다. E는 코드리뷰의 도입이 빠른 프로토타이핑에 적합한 코드에서, 프로덕션에서 사용할 수 있는 코드로의 전환을 알렸다고 합니다. 또한 코드리뷰는 각 코드 조각에 대해서 한명 이상의 사람이 친숙해지도록 하여, 지식이 계속해서 회사 내부에 머무를 수 있도록 했습니다.

인터뷰를 통해서, Google 개발자들이 코드리뷰를 통해 어떤 것을 기대하고 있는지 정리할 수 있었습니다.

education

코드 리뷰를 통해서 가르치거나 배우는 과정

maintaining norms

formatting이나 API 사용 패턴 등, 해당 단체가 채택하고 있는 취향을 유지 (특히 새로운 팀 멤버 등)

gatekeeping

소스코드, 디자인적인 선택 등에 대해 경계를 만드는 것

accident prevention

버그, defect, 코드품질 저하와 관련된 모든 이슈를 막기

Google에서는 코드 리뷰를 어떻게 하는가?

구글에서의 코드 리뷰는 두 컨셉과 연관되어 있습니다. ownership , 그리고 readablity 입니다.

`ownership`

구글의 코드베이스는 트리 형태를 띄고 있는데, 각 디렉토리가 특정 팀이 own 하는 방식입니다.

어떤 개발자든 해당 코드에 의문을 제기할 수 있으나, 커밋되기 전에 owner가 해당 변경점을 반드시 리뷰하고 변경사항을 승인해야합니다.

`Readability`

지속적인 코드 스타일과 관습들을 보장하기 위해 구글은 이 개념을 도입했습니다. 개발자들은 특정 언어의 readability 에 대한 자격을 받을 수 있습니다.

readability 리뷰어들에게 코드를 보내고, 리뷰어들이 이 사람이 코드 스타일 그리고 이 언어에 한해 가장 좋은 방식으로 접근하고 있다고 생각하면 해당 개발자에게 readability 자격을 부여합니다. 구글의 모든 코드는 이 readability 자격을 가진 사람이 작성하거나 리뷰어로 참가해야만 합니다.

구글의 코드리뷰 과정

Creating. 작성자가 코드를 변경, 추가, 삭제하고 준비되면 변경점을 생성한다.
Previewing. 작성자는 CRITIQUE를 사용하여 변경점의 diff를 보고, 자동 코드 분석기의 결과를 본다. 준비가 되면 작성자는 한명 이상의 리뷰어에게 변경점을 알린다.
Commenting. 리뷰어는 웹 상에서 diff를 보고, 코멘트를 남긴다. 만약 프로그램이 분석한 결과가 있다면 그 또한 리뷰어들이 볼 수 있다. unresolved 코멘트는 작성자가 반드시 다시 다뤄야할 아이템을 의미한다. resolved 코멘트는 반드시 작성자가 바꾸지는 않아도 되는 추가적인 코멘트를 포함한다.
Addressing Feedback. 작성자는 코멘트를 보고, 변경점을 업데이트하거나 코멘트에 답변한다. 변경점이 업데이트되면 작성자는 새로운 스냅샷을 업로드하고, 바뀐 점을 다시 리뷰한다.
Approving. 모든 코멘트가 다뤄지면, 리뷰어들은 변경사항을 승인하고, LGTM(Looks Good To Me)라고 마킹한다. 변경사항을 커밋하기 위해서, 개발자는 대개 최소 한명의 리뷰어의 승인을 받아야한다.

리뷰어 제안과 코드 분석 결과

CRITIQUE는 가장 적절한, 최소한의 리뷰어 셋을 자동으로 알아본다. 이 툴은 포함된 파일을 최근에 편집했거나 리뷰한 사람을 최우선으로 한다.

구글에서의 코드리뷰: 통계로 보기

리뷰주기 및 속도. 개발자들은 3 번 / 주 주기로 변경(중간값)하고, 80퍼센트의 개발자들은 7번 / 주 주기로 변경한다. 한 주에 코드리뷰하는 중간 값은 4번이고, 80퍼센트의 개발자들은 한 주에 10번 이하로 리뷰한다. 최초로 리뷰를 받기까지 작은 변경점인 경우에는 평균적으로 1시간 이하, 큰 변경점인 경우 평균적으로 5시간 걸린다.
리뷰 크기. 구글에서는 35%의 변경점이 한 파일만 변경한 것이고, 90% 이상이 10파일 이하로 변경한 것이다. 10% 이상이 한줄만 변경한 경우이고, 변경된 라인의 평균값은 24이다.
리뷰어와 코멘트의 수. 최적의 리뷰어 수는 의견이 분분하다. 구글에서는 25% 이하 가 1명 이상의 리뷰어가 있다. 그리고 99%가 최대 5명의 리뷰어가 있고, 평균 리뷰어의 수는 1이다.

Google 개발자들은 코드 리뷰를 어떻게 인식하는 가.

Distance.

인터뷰이들은 코드리뷰에서의 거리감을 두가지로 인식했다. 지리적 (리뷰어와 작성자의 물리적 거리) / 구조적(다른 팀 혹은 다른 역할군). 이 거리감이 리뷰 과정의 딜레이로 이어지거나 혹은 오해를 부르곤 했다.

인터뷰이들은 두가지 관점에서 코드리뷰 내의 소통방식인가 문제가 될수 있다고 생각했다. tone / power . tone은 작성자들이 코멘트에 대해 리뷰할 때 감정적이 될 수 있다는 점을 의미한다. 부정적인 톤으로 코멘트를 하는 경우 덜 유용하다는 점을 발견했다. power는 어떤 한 사람이, 다른 사람의 행동을 바꾸려고 코드리뷰를 이용할 때 일어난다. 일부러 승인을 미루거나 리뷰를 질질 끄는 등의 행위를 의미한다. tone 혹은 power를 사용하는 이슈는 개발자들을 불편하거나 좌절하게 만든다.

Review Subjects.

코드리뷰를 하는 도중 가장 많은 논란을 불러일으킨 부분은 design review 였다. 어떤 사람들은 리뷰 이전에 디자인이 결정되었기를 원하고, 어떤 이들은 리뷰 중에 디자인을 변경하기를 원한다. 서로 다른 기대감이 있기때문에 과정 중에 마찰이 생기곤 했다.

Context.

(작성자와 리뷰어간) 오해는 보통, 왜 이런 변경을 했는가 에 대해서 알지 못하기 때문에 생긴다. 변경한 이유가 프로덕션 상 급한 fix 인지, 아니면 있으면 좋은 개선점인지 모르기 때문이다. 기대가 다르면, 리뷰 프로세스가 늦어지게 되거나 (한쪽 혹은 둘다) 좌절감을 안게 된다.

Customization.

이는 툴 자체에 관한 이야기이다. 일부 팀은 코드 리뷰 조건이 다른데, CRITIQUE에서는 개별적인 커스터마이징을 제공하지 않기 때문에 불편한 부분이 있다.

구글 개발자들은, 전반적으로 코드리뷰에 대해서 어떻게 생각하는지에 대해서는 매우 긍정적으로 답했고, CRITIQUE 툴에 대한 만족도에서도 97% 의 개발자가 만족한다고 답했다.