Modern Code Review: A Case Study at Google

文章标题：现代代码审查：谷歌案例研究
作者/机构：Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko (Google, Inc.); Alberto Bacchelli (University of Zurich)

A1 主要贡献

本文对谷歌的现代代码审查（Modern Code Review）实践进行了探索性调查。谷歌自公司早期便引入了代码审查，并在此后的数十年间，通过数百万次代码审查和代码变更不断地对其进行演进。本研究旨在揭示谷歌引入该实践的初衷，并分析其在当前状态下的运作情况。

核心问题与研究目标：开放的研究挑战是理解在现代代码审查这一新颖背景下，哪些实践是宝贵且有效的方法。本文旨在扩展Rigby和Bird的工作，聚焦于在谷歌——一个拥有数十年代码审查历史、每日处理海量审查的公司——所建立的审查实践与特性。研究目标分为三个方面：
1. RQ1：谷歌代码审查的动机是什么？ 探究引入代码审查的历史原因和当前开发者的期望。
2. RQ2：谷歌代码审查的实践是怎样的？ 分析审查流程、速度、频率、变更规模和审查者数量等，并与先前研究中的趋同实践进行比较。
3. RQ3：谷歌开发者如何看待代码审查？ 了解开发者对审查过程的看法，特别是遇到的挑战（流程中断）和整体满意度。

研究方法与创新点：本研究采用混合方法，结合了多种数据源，以提供一个对谷歌代码审查实践深入且纵向的单一案例分析。
- 数据源：
1. 对12名谷歌开发者进行半结构化访谈。
2. 向近期提交变更的工程师发起了内部调查，并收到44份回复。
3. 分析了谷歌代码审查工具在两年内记录的900万次审查的日志数据。

• 主要发现与贡献：
  1. 发现谷歌的审查流程明显比其他环境更轻量级，其特点是单一审查者、快速迭代、小型变更以及与代码审查工具的紧密集成。
  2. 尽管流程成熟，但由于代码审查周围复杂的交互，流程中断（breakdowns）依然存在。
  3. 开发者认为这个过程很有价值，证实了它在大规模下的良好运作，并且他们进行审查的原因也取决于作者和审查者之间的关系。
  4. 发现了代码审查工具在协作审查之外的用途，并证实了代码审查作为一种教育工具的重要性。

这项研究为实践者提供了可借鉴的经验，也为希望理解和支持这一新颖流程的研究人员提供了有力的案例。

A3 背景知识

2.1 代码审查流程与背景

代码检查（Code Inspections）。软件检查是最早被形式化的代码审查流程之一。这一高度结构化的流程包括规划、概述、准备、检查会议、返工和跟进等步骤【索引16，Design and code inspections to reduce errors in program development，M.E. Fagan，1976，IBM Systems Journal】。代码检查的目标是在同步的检查会议中发现缺陷，作者和审查者会共处一室检查代码变更。Kollanus和Koskinen的文献综述【索引25，Survey of software inspection research，Sami Kollanus and Jussi Koskinen，2009，The Open Software Engineering Journal】发现，关于代码检查的研究绝大多数是实证性的，并就其作为缺陷发现技术的总体价值以及阅读技术在调动检查员积极性方面的价值达成了共识。自2005年以来，随着互联网的普及和异步代码审查流程的发展，对代码检查的研究已逐渐减少。

通过电子邮件进行的异步审查。直到21世纪初，大多数大型开源软件（OSS）项目都采用了一种远程、异步的审查形式，依赖于发送到邮件列表和问题跟踪系统等沟通渠道的补丁。在这种模式下，项目成员评估贡献的补丁，并通过这些渠道要求修改。当一个补丁被认为质量足够高时，核心开发者会将其提交到代码库中。受信任的提交者可能会采用“先提交后审查”（commit-then-review）的流程，而不是进行提交前审查（pre-commit reviews）【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】。Rigby等人是该领域最早进行广泛研究的学者之一；他们发现这种类型的审查“除了相信同行能有效发现软件缺陷外，与代码检查几乎没有共同之处”【索引34，Peer Review on Open-Source Software Projects: Parameters, Statistical Models, and Theory，Peter C. Rigby, Daniel M. German, Laura Cowen, and MargaretAnne Storey，2014，IEEE Transactions on Software Engineering】。Kononenko等人分析了相同的场景，发现审查响应时间和接受率与社会因素相关，如审查者负载和变更作者的经验【索引26，Code review quality: How developers see it，Oleksii Kononenko, Olga Baysal, and Michael W Godfrey，2016，ICSE】，而这些因素在代码检查中是不存在的。

基于工具的审查。为了给审查补丁的过程带来结构，开源软件和工业界出现了多种工具。这些工具为审查过程的后勤工作提供支持：(1) 补丁的作者将其提交给代码审查工具；(2) 审查者可以看到提议的代码变更的差异（diff）；(3) 审查者可以与作者和其他审查者就特定代码行展开线程式讨论；(4) 作者可以提出修改以解决审查者的评论。这个反馈循环持续进行，直到所有人都满意或补丁被放弃。不同的项目调整了其工具以支持其流程。微软使用CodeFlow，它跟踪每个人（作者或审查者）的状态以及他们所处的流程阶段（已签核、等待中、审查中）；CodeFlow并不阻止作者在未经批准的情况下提交变更【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】，并支持在评论线程中进行聊天【索引4，Expectations, outcomes, and challenges of modern code review，Alberto Bacchelli and Christian Bird，2013，ICSE】。谷歌的Chromium项目（以及其他几个开源项目）依赖于外部可用的Gerrit【索引17，https://www.gerritcodereview.com/，2016】；在Chromium中，变更只有在获得审查者明确批准并通过自动化验证确认不会破坏构建后，才能合并到主分支中【索引12 ，Chromium developer guidelines，chromium 2016，https://www.chromium.org/developers/contributing-code】。在Gerrit中，未被指派的审查者也可以发表评论。VMware开发了开源的ReviewBoard，它将静态分析集成到审查过程中；这种集成依赖于变更作者手动请求分析，并已被证明能提高代码审查质量【索引5 ，Reducing Human Effort and Improving Quality in Peer Code Reviews Using Automatic Static Analysis and Reviewer Recommendation，Vipin Balachandran，2013，ICSE】。Facebook的代码审查系统Phabricator【索引29，Meet Phabricator, The Witty Code Review Tool Built Inside Facebook，phabricator 2016，https://techcrunch.com/2011/08/07/ohwhat-noble-scribe-hath-penned-these-words/】，允许审查者“接管”一个变更并自行提交，并为自动静态分析或持续构建/测试集成提供了钩子 。

在基于工具的审查背景下，研究人员已经调查了代码变更接受度或响应时间与变更代码及作者特征之间的关系【索引41，Review participation in modern code review，Patanamon Thongtanunam, Shane McIntosh, Ahmed E Hassan, and Hajimu Iida，2017，Empirical Software Engineering】，以及审查者之间的一致性【索引22，The Impact of a Low Level of Agreement Among Reviewers in a Code Review Process，Toshiki Hirao, Akinori Ihara, Yuki Ueda, Passakorn Phannachitta, and Ken-ichi Matsumoto，2016，IFIP International Conference on Open Source Systems】。此外，也进行了定性调查，以根据工业界【索引11，Characteristics of useful code reviews: an empirical study at Microsoft，Amiangshu Bosu, Michaela Greiler, and Christian Bird，2015，MSR】和开源软件开发者【索引26，Code review quality: How developers see it，Oleksii Kononenko, Olga Baysal, and Michael W Godfrey，2016，ICSE】的观点来定义什么是好的代码审查。

基于拉取请求（Pull-based）的开发模型。在GitHub的拉取请求（pull request）流程【索引18，GitHub pull request process，githubpull 2016，https://help.github.com/articles/using-pull-requests/】中，想要进行变更的开发者会fork一个现有的git仓库，然后在自己的fork中进行修改。当拉取请求被发出后，它会出现在相应项目的拉取请求列表中，对任何能看到该项目的人都是可见的。Gousios等人定性地调查了拉取请求集成者【索引21 ，Work Practices and Challenges in PullBased Development: The Integrator’s Perspective，Georgios Gousios, Andy Zaidman, Margaret-Anne Storey, and Arie van Deursen，2015，ICSE】和贡献者【索引20，Work Practices and Challenges in Pull-Based Development: The Contributor’s Perspective，Georgios Gousios, Margaret-Anne Storey, and Alberto Bacchelli，2016，ICSE】的工作实践和挑战，发现了与其他基于工具的代码审查的相似之处。

2.2 代码审查中的趋同实践

Rigby和Bird的开创性工作。Rigby和Bird发表了首个也是最重要的工作，试图识别跨越多种代码审查流程和环境的趋同实践【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】。他们考察了使用基于邮件审查的开源项目、使用Gerrit的开源项目、一个使用基础代码审查工具的AMD项目，以及使用CodeFlow的微软。他们分析了这些项目的流程和可用数据，描述了多个方面，如迭代开发、审查者选择和审查讨论。他们确定了现代代码审查的五种实践，所有被考察的项目都趋向于这些实践（见表1）。本文将使用这些实践的ID来指代它们，例如CP1。他们发现，在快速、轻量级的流程（CP1、CP2、CP3）、少数人参与（CP4）以及进行集体问题解决（CP5）方面存在一致性。

A2 方法细节

3.1 研究问题

研究的总体目标。本研究的总体目标是调查谷歌的现代代码审查实践，这是一个涉及数千名开发者，并经过十多年不断完善的流程。为此，我们进行了一项探索性调查，围绕三个主要研究问题展开。

RQ1：谷歌代码审查的动机是什么？ Rigby和Bird发现动机是现代代码审查的趋同特征之一（CP5）。本文研究在谷歌，驱动代码审查的动机和期望是什么。具体来说，我们既考虑了引入现代代码审查的历史原因（因为谷歌是首批使用现代代码审查的公司之一），也考虑了当前的期望。

RQ2：谷歌代码审查的实践是怎样的？ Rigby和Bird发现的其他四个趋同实践涉及流程本身的执行方式，包括流程（CP1）、速度和频率（CP2）、分析的变更大小（CP3）以及审查者数量（CP4）。我们在谷歌分析了这些方面，以调查对于一个拥有更长代码审查历史、明确文化和更大审查量的公司，这些发现是否仍然成立，相比于先前研究中分析的公司【索引4，Expectations, outcomes, and challenges of modern code review，Alberto Bacchelli and Christian Bird，2013，ICSE；索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】。

RQ3：谷歌开发者如何看待代码审查？ 最后，在我们的最后一个研究问题中，我们有兴趣了解谷歌开发者如何看待在他们公司实施的现代代码审查。这种探索对于更好地理解实践（因为认知驱动行为【索引39，The methodology of behavior study，William Isaac Thomas and Dorothy Swaine Thomas，1928，The child in America: Behavior problems and programs】）和指导未来研究是必要的。我们关注两个方面：开发者在特定审查期间经历的审查流程中断（breakdowns），以及尽管存在这些挑战，开发者是否对审查感到满意。

3.2 研究环境

研究环境概述。我们简要描述我们的研究环境，作为我们方法论的背景。关于谷歌代码审查流程和工具的全面描述，请参见第5.1节。

谷歌的开发工作流。谷歌的大多数软件开发都在一个单一的源代码仓库中进行，通过一个内部版本控制系统访问【索引30，Why Google Stores Billions of Lines of Code in a Single Repository，Rachel Potvin and Josh Levenburg，2016，Commun. ACM】。由于代码审查在谷歌是强制性的，每一次对谷歌源代码控制系统的提交都会首先通过使用Critique进行代码审查。Critique是一个内部开发的、中心化的、基于Web的代码审查工具。在谷歌的单一仓库中的开发工作流，包括代码审查过程，都非常统一。与第2节中描述的其他工具一样，Critique允许审查者查看提议的代码变更的差异，并与作者和其他审查者就特定代码行展开线程式讨论。Critique提供了广泛的日志记录功能；所有开发者与工具的交互都被捕获（包括打开工具、查看差异、发表评论和批准变更）。

3.3 研究方法

混合方法。为了回答我们的研究问题，我们采用了定性与定量相结合的混合方法【索引13，Research design: Qualitative, quantitative, and mixed methods approaches (3rd ed.)，J.W. Creswell，2009，Sage Publications】，结合了来自多个数据源的数据：与参与谷歌软件开发的员工进行的半结构化访谈、来自代码审查工具的日志，以及对其他员工的调查。我们使用访谈作为收集关于进行代码审查动机多样性（而非频率【索引23，The logic of qualitative survey research and its position in the field of social research methods，Harrie Jansen，2010，Forum Qualitative Sozialforschung, Vol. 11】）数据的工具（RQ1），并引出开发者对代码审查及其挑战的看法（RQ3）。我们使用Critique日志来量化和描述当前的审查实践（RQ2）。最后，我们使用调查来确认从访谈中浮现出的多样化代码审查动机（RQ1），并引出开发者对该流程的满意度。

访谈。我们与选定的谷歌员工进行了一系列面对面的半结构化访谈【索引13，Research design: Qualitative, quantitative, and mixed methods approaches (3rd ed.)，J.W. Creswell，2009，Sage Publications】，每次访谈大约持续1小时。最初的可能参与者池是通过滚雪球抽样法选出的，从论文作者认识的开发者开始。从这个池中，我们选择参与者以确保在团队、技术领域、工作角色、在公司工作的时间长度以及在代码审查过程中的角色方面具有多样性。访谈脚本（见附录【索引1，Appendix to this paper，2017，https://goo.gl/dP4ekg】）包括关于代码审查动机的感知、最近审查/编写的变更以及最佳/最差审查经历的问题。在每次访谈前，我们都会审查参与者的审查历史，并找出一个变更在访谈中讨论；我们根据交互次数、参与对话的人数以及是否存在看起来令人惊讶的评论来选择这些变更。在访谈的观察部分，参与者被要求在审查待处理的变更时进行有声思维，并提供一些明确的信息，例如开始审查的切入点。访谈持续进行，直到达到饱和状态【索引19 ，The discovery of grounded theory: Strategies for qualitative research，Barney G Glaser and Anselm L Strauss，2009，Transaction Books】，即访谈提出的概念大致相似。总的来说，我们与12名在谷歌工作时间从1个月到10年（中位数为5年）的员工进行了访谈，他们来自软件工程和网站可靠性工程领域，包括技术负责人、经理和个人贡献者。每次访谈有三到四人参与：参与者和2-3名访谈者（其中两名是本文作者）。访谈由一名访谈者现场转录，另一名则负责提问。

访谈数据的开放编码。为了识别从访谈数据中浮现出的广泛主题，我们进行了一轮开放编码【索引27，Qualitative data analysis: An expanded sourcebook，Matthew B Miles and A Michael Huberman，1994，Sage】。两名作者讨论了访谈记录以建立共同主题，然后将其转化为一个编码方案。另一名作者随后对讨论记录进行了封闭编码以验证这些主题。我们对其中一次访谈重复此过程，直到就方案达成一致。我们还追踪了这些主题在何种情境（审查者与作者之间的关系）下被提及。问题设计和分析过程的结合意味着我们可以在结果中讨论稳定的主题，但不能有意义地讨论其发生的相对频率【索引23，The logic of qualitative survey research and its position in the field of social research methods，Harrie Jansen，2010，Forum Qualitative Sozialforschung, Vol. 11】。

审查数据分析。我们通过使用Critique生成的日志，分析了关于代码审查过程的定量数据。我们主要关注与Rigby和Bird发现的趋同实践相关的指标【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】。为了便于比较，我们不考虑没有任何审查者的变更，因为我们感兴趣的是那些经过了明确代码审查过程的变更。我们将“审查者”定义为任何批准代码变更的用户，无论他们是否被变更作者明确要求进行审查。我们使用一种基于名称的启发式方法来过滤掉由自动化过程进行的变更。我们只关注发生在谷歌主代码库中的变更。我们还排除了在研究时尚未提交的变更，以及我们的差异工具报告源文件行数变化为零的变更，例如仅修改二进制文件的变更。

数据集规模。在谷歌，一个普通工作日大约有20,000个符合上述过滤条件的变更被提交。我们的最终数据集包括从2014年1月到2016年7月，由超过25,000名作者和审查者创建的约900万个符合这些标准的变更，以及从2014年9月到2016年7月从所有变更中收集的约1300万条评论。

调查。我们创建了一份在线问卷，并发送给98位最近提交了代码变更的工程师。该代码变更已经被审查过，因此我们定制了问卷，询问受访者对他们特定最近变更的代码审查的看法；这一策略使我们能够减轻回忆偏见【索引35，Bias in analytic research，David L Sackett，1979，Journal of chronic diseases】，同时收集全面的数据。调查包括三个关于所收到审查价值的李克特量表问题，一个关于审查对其变更影响的多选题（基于访谈中出现的期望），并提供一个可选的“其他”回答，以及一个开放式问题，征求受访者对所收到的审查、代码审查工具和/或整个流程的看法。我们收到了44份有效回复（45%的回复率，这在软件工程研究中被认为是高的【索引31，Conducting on-line surveys in software engineering，Teade Punter, Marcus Ciolkowski, Bernd Freimut, and Isabel John，2003，Empirical Software Engineering】）。

3.4 有效性威胁与局限性

研究方法的有效性威胁与局限性。我们描述了由我们的研究方法带来的工作结果的有效性威胁和局限性，以及我们为减轻这些威胁所采取的措施。

内部有效性 - 可信度。关于审查数据的定量分析，我们使用启发式方法来过滤掉机器人编写的变更，但这些启发式方法可能会允许一些机器人编写的变更；我们通过只包括那些有真人审查者的机器人编写的变更来减轻了这个问题。关于定性调查，我们使用开放编码来分析受访者的回答。这种编码可能受到进行编码的作者的经验和动机的影响，尽管我们试图通过让多名编码员参与来减轻这种偏见。决定参与我们访谈和调查的员工是自由决定的，因此引入了自我选择偏见的风险。因此，对于那些选择不参与的开发者来说，结果可能会有所不同；为了试图减轻这个问题，我们结合了访谈和调查的信息。此外，我们使用了滚雪球抽样法来确定要访谈的工程师，这存在抽样偏见的风险。尽管我们试图通过访谈不同工作角色和职责的开发者来减轻这种风险，但我们访谈的开发者可能共享一些不适用于整个公司的其他因素。为了减轻主持人接受度偏见，参与定性数据收集的研究人员不属于Critique团队。社会期望偏见可能影响了回答，使其更倾向于符合谷歌文化；然而，在谷歌，人们被鼓励在发现工作流程问题时进行批评和改进，从而减少了这种偏见。最后，我们没有访谈研究科学家或与专业审查者（如安全审查）互动的开发者，因此我们的结果偏向于普通开发者。

普适性 - 可转移性。我们设计这项研究的明确目标是了解特定公司内部的现代代码审查。因此，我们的结果可能不适用于其他情境，我们更感兴趣的是在经过多年和数百万次审查的完善后，仍然存在的实践和中断的多样性。鉴于多家公司和开源项目的底层代码审查机制的相似性，有理由认为，如果一个审查流程达到了相同的成熟度并使用可比的工具，开发者会有类似的经历。

4.1 一切是如何开始的

代码审查的起源和初衷。谷歌的代码审查是由一位早期员工很早引入的；本文的第一作者采访了这位员工（下文简称E），以更好地理解代码审查的最初动机及其演变。E解释说，引入代码审查的主要动力是强迫开发者编写其他开发者能够理解的代码；这被认为是重要的，因为代码必须成为未来开发者的老师。E表示，在谷歌引入代码审查标志着从一个为快速原型设计而优化的研究代码库，向一个必须考虑未来工程师阅读源代码的生产代码库的转变。代码审查也被认为能够确保每一段代码都至少有不止一个人熟悉，从而增加知识保留在公司内部的机会。

代码审查的额外收益。E重申了一个概念，即尽管审查者能发现错误是很好的，但在谷歌引入代码审查的首要原因是为了提高代码的可理解性和可维护性。然而，除了最初的教育动机外，E解释说，内部开发者很快就清楚了三个额外的好处：检查风格和设计的一致性；确保充分的测试；以及通过确保没有单个开发者可以在没有监督的情况下提交任意代码来提高安全性。

4.2 当前的期望

代码审查的四大核心期望。通过对我们的访谈数据进行编码，我们确定了谷歌开发者对代码审查的四个关键期望主题：教育（education）、维护规范（maintaining norms）、把关（gatekeeping）和事故预防（accident prevention）。教育涉及从代码审查中进行教学或学习，这与引入代码审查的初衷一致；规范指的是组织对某个可自由选择的偏好（例如，格式化或API使用模式）；把关关系到围绕源代码、设计选择或其他工件建立和维护边界；而事故则指引入错误、缺陷或其他与质量相关的问题。

代码审查的历史追踪价值。这些是审查过程中的主要主题，但代码审查也被用于回顾性地追踪历史。开发者在审查过程结束后仍然重视它；代码审查使得能够浏览代码变更的历史，包括发生了哪些评论以及变更是如何演变的。我们还注意到开发者使用代码审查历史来理解错误是如何被引入的。本质上，代码审查使得未来可以对变更进行审计。

调查验证。在我们的调查中，我们进一步验证了这一编码方案。我们询问作者认为代码审查评论的价值何在；他们可以从四个主题中选择一个或多个，和/或写下自己的回答。之前确定的四个主题中的每一个，在特定代码审查的背景下，都被8到11名受访者选中，这为上述编码方案与开发者对代码审查价值的感知相符提供了额外的信心。

与先前研究的对比。尽管这些期望可以与之前在微软发现的期望相对应【索引4，Expectations, outcomes, and challenges of modern code review，Alberto Bacchelli and Christian Bird，2013，ICSE】，但正如我们的参与者所解释的，谷歌的主要焦点在于教育以及代码的可读性和可理解性，这与引入审查的历史动力是一致的。因此，这个焦点与Rigby和Bird发现的焦点（即一个集体解决问题的活动）【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】并不一致。

期望与工作关系的相关性。如前所述，在对访谈记录进行编码时，我们还追踪了主题被提及的审查情境。我们发现，这些不同主题的相对重要性取决于作者和审查者之间的关系（图1）。例如，维护规范主要出现在工程师与不同资历的人（项目负责人、专家可读性审查者或“新”团队成员）之间，而与他们的同级同事或其他团队的互动中则较少出现，在后一种情况下，把关和事故预防是首要的。教育的好处被广泛重视，并涵盖了多种不同的关系。

5.1 描述审查流程

核心概念：所有权与可读性。谷歌的代码审查与两个概念紧密相连：所有权（ownership）和可读性（readability）。我们首先介绍这两个概念，然后描述审查流程的流转，最后总结内部审查工具CRITIQUE与其它审查工具相比的独特之处。

所有权（Ownership）。谷歌的代码库以树状结构组织，每个目录都由一组人明确拥有。虽然任何开发者都可以对代码库的任何部分提出变更，但在变更被提交之前，必须由该目录（或父目录）的所有者进行审查和批准；即使是目录所有者，也期望在提交代码前让他们的代码得到审查。

可读性（Readability）。谷歌定义了一个名为“可读性”的概念，这是在很早的时候为了确保代码库内代码风格和规范的一致性而引入的。开发者可以获得特定语言的可读性认证。要申请可读性，开发者需要将变更发送给一组可读性审查者；一旦这些审查者确信该开发者理解了该语言的代码风格和最佳实践，该开发者便被授予该语言的可读性。每一个变更必须由拥有所用语言可读性认证的人员编写或审查。

代码审查流程。审查的流程与Critique紧密耦合，工作流程如下：

1. 创建（Creating）：作者开始修改、添加或删除一些代码；准备好后，他们会创建一个变更。
2. 预览（Previewing）：作者接着使用Critique查看变更的差异，并查看自动代码分析器（例如，来自Tricorder【索引36，Tricorder: building a program analysis ecosystem，Caitlin Sadowski, Jeffrey van Gogh, Ciera Jaspan, Emma Söderberg, and Collin Winter，2015，ICSE】）的结果。当他们准备好后，作者会将变更发送给一个或多个审查者。
3. 评论（Commenting）：审查者在Web UI中查看差异，边看边起草评论。如果存在程序分析结果，审查者也可以看到。未解决的评论代表了变更作者必须明确处理的行动项。已解决的评论包括可能不需要变更作者采取任何行动的可选或信息性评论。
4. 处理反馈（Addressing Feedback）：作者现在处理评论，可以通过更新变更或回复评论。当变更更新后，作者上传一个新的快照。作者和审查者可以查看任意两个快照之间的差异，以了解发生了什么变化。
5. 批准（Approving）：一旦所有评论都得到处理，审查者会批准该变更并标记为‘LGTM’（Looks Good To Me）。要最终提交一个变更，开发者通常必须得到至少一位审查者的批准。通常，只需要一位审查者就能满足前述的所有权和可读性要求。

流程的轻量级特性。我们试图量化审查的“轻量级”程度（CP1）。我们通过检查一个变更的作者多少次发出了一组解决先前未解决评论的评论，来衡量审查中的来回次数。我们假设一次迭代对应于作者解决一些评论的一个实例；零次迭代意味着作者可以立即提交。我们发现，超过80%的变更最多只涉及一次解决评论的迭代。

审查者推荐。为了确定审查变更的最佳人选，Critique依赖一个工具来分析变更并推荐可能的审查者。这个工具会找出满足变更中所有文件审查要求所需的最少审查者集合。需要注意的是，通常只需要一位审查者，因为变更通常是由拥有相关文件所有权和/或可读性的人编写的。该工具优先推荐最近编辑和/或审查过相关文件的审查者。新团队成员会被明确添加为审查者，因为他们尚未建立起审查/编辑历史。未被指派的审查者也可以对变更发表评论（并可能批准）。通常只有在变更涉及特定团队范围之外的文件时，才需要工具支持来寻找审查者。在团队内部，开发者知道该把变更发给谁。对于可以发送给团队中任何人的变更，许多团队使用一个系统，该系统以轮询方式将发送到团队电子邮件地址的审查分配给配置好的团队成员，同时考虑到审查负载和休假情况。

代码分析结果的整合。Critique将代码分析结果与人工评论一起显示（尽管颜色不同）。分析器（或审查者）可以提供建议的编辑，这些编辑可以通过Critique提出并应用到变更中。为了在提交前审查变更，谷歌的开发流程还包括提交前挂钩（pre-commit hooks）：这是一种检查，如果失败，需要开发者明确覆盖才能提交。提交前检查包括基本的自动化风格检查和运行与变更相关的自动化测试套件等。所有提交前检查的结果在代码审查工具中都是可见的。通常，提交前检查是自动触发的。这些检查是可配置的，以便团队可以强制执行项目特定的不变量，并自动将邮件列表添加到变更中，以提高认知度和透明度。除了提交前检查的结果，Critique还通过Tricorder【索引36，Tricorder: building a program analysis ecosystem，Caitlin Sadowski, Jeffrey van Gogh, Ciera Jaspan, Emma Söderberg, and Collin Winter，2015，ICSE】显示各种自动化代码分析的结果，这些分析可能不会阻止变更的提交。分析结果涵盖了从简单的风格检查，到更复杂的基于编译器的分析过程，以及项目特定的检查。目前，Tricorder包含110个分析器，其中5个是用于数百个额外检查的插件系统，总共分析超过30种语言。

5.2 量化审查流程

与趋同实践的量化对比。我们复制了Rigby和Bird进行的导致发现CP2-4的定量分析，以便将这些实践与谷歌已经趋同的特征进行比较。

审查频率与速度。Rigby和Bird发现，快节奏、迭代的开发方式也适用于现代代码审查：在他们研究的项目中，开发者以非常一致的短时间间隔工作。为了发现这一点，他们分析了审查的频率和速度。

谷歌的审查频率与速度。在谷歌，就频率而言，我们发现开发者创作变更的中位数约为每周3次，80%的作者每周创作少于7次变更。同样，开发者每周审查变更的中位数为4次，80%的审查者每周审查少于10次变更。在速度方面，我们发现，对于小变更，开发者等待初步反馈的中位时间不到一小时，对于非常大的变更，则约为5小时。整个审查过程的总体（所有代码大小）中位延迟时间不到4小时。这明显低于Rigby和Bird报告的批准中位时间【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】，AMD为17.5小时，Chrome OS为15.7小时，微软的三个项目分别为14.7、19.8和18.9小时。另一项研究发现，微软的批准中位时间为24小时【索引14，Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down，Jacek Czerwonka, Michaela Greiler, and Jack Tilford，2015，ICSE (SEIP)】。

审查规模。Rigby和Bird认为，快速的审查时间只能通过审查更小的变更来实现，并随后分析了审查的规模。在谷歌，超过35%的被考虑变更只修改了一个文件，约90%的变更修改了少于10个文件。超过10%的变更只修改了一行代码，修改行数的中位数为24。这个中位变更规模明显低于Rigby和Bird报告的公司，如AMD（44行）、Lucent（263行），以及微软的Bing、Office和SQL Server（介于这些边界之间），但与开源项目中的变更规模一致【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】。

审查者与评论数量。最佳审查者数量在研究人员中一直存在争议，即使是在深入研究的代码检查领域也是如此【索引37，Inspecting the History of Inspections: An Example of Evidence-Based Technology Diffusion，F. Shull and C. Seaman，2008，IEEE Software】。Rigby和Bird调查了所考虑的项目是否趋向于相似数量的参与审查者。他们发现这个数字是两个，值得注意的是，无论审查者是明确被邀请的（如微软项目，中位数邀请多达4名审查者）还是变更是被公开广播以供审查【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】。

谷歌的审查者与评论数量。相比之下，在谷歌，少于25%的变更有超过一个审查者，超过99%的变更最多有五个审查者，审查者数量的中位数为1。较大的变更平均倾向于有更多的审查者。然而，即使是非常大的变更，平均也需要少于两个审查者。

评论数量与审查者关系。Rigby和Bird还发现“当有超过2名审查者活跃时，关于变更的评论数量增加极少”【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】，并得出结论认为两名审查者能发现最佳数量的缺陷。在谷歌，情况则不同：更多的审查者会导致变更上平均有更多的评论。此外，每次变更的平均评论数量随着变更行数的增加而增长，对于大约1250行的变更，达到每次变更12.5条评论的峰值。大于此规模的变更通常包含自动生成的代码或大量的删除，导致平均评论数量较低。

访谈数据中的五大主题。对我们的访谈数据进行分析后，浮现出五个主要主题。前四个主题涉及流程方面的中断：

距离（Distance）。受访者从两个角度感知代码审查中的距离：地理距离（即作者和审查者之间的物理距离）和组织距离（例如，不同团队或不同角色之间）。这两种距离都被认为是导致审查过程延迟或误解的原因。

社交互动（Social interactions）。受访者认为代码审查中的沟通可能从两个方面导致问题：语气（tone）和权力（power）。语气指的是作者有时对审查评论很敏感；对评论的情感分析提供了证据，表明带有负面语气的评论不太可能有用【索引11，Characteristics of useful code reviews: an empirical study at Microsoft，Amiangshu Bosu, Michaela Greiler, and Christian Bird，2015，MSR】。权力指的是利用代码审查过程来诱导他人改变行为；例如，拖延审查或扣留批准。审查中语气或权力的问题会使开发者对审查过程感到不舒服或沮丧。

审查主题（Review subject）。访谈中提到了关于代码审查是否是审查某些方面（特别是设计审查）最合适情境的分歧。这导致了期望不匹配（例如，一些团队希望在第一次审查前大部分设计已完成，而另一些团队则希望在审查中讨论设计），这可能在参与者之间和流程内部引起摩擦。

背景（Context）。受访者让我们看到，由于不了解引起变更的原因，可能会产生误解；例如，一个变更的理由是紧急修复生产问题，还是一个“锦上添花”的改进。由此产生的期望不匹配可能导致延迟或沮丧。

最后一个主题涉及工具本身：

定制化（Customization）。一些团队对代码审查有不同的要求，例如，关于需要多少审查者。这是一个技术性的中断，因为在Critique中并非总是支持任意的定制，这可能会导致围绕这些策略的误解。基于反馈，Critique最近发布了一项新功能，允许变更作者要求所有审查者都签核。

6.2 满意度与时间投入

开发者满意度调查。为了理解所识别问题的严重性，我们利用部分调查来探究代码审查在总体上是否被认为是有价值的。

调查结果。我们发现（见表2），在谷歌内部，代码审查被广泛认为是有价值和高效的——所有受访者都同意代码审查是有价值的这一说法。这一情绪也得到了我们对Critique进行的内部满意度调查的呼应：97%的开发者对其感到满意。

具体变更下的满意度。在特定变更的背景下，情绪则更加多样化。最不满意的回复与非常小的变更（1个词或2行）或为了实现其他目标而必需的变更相关，例如，通过源代码的变更来触发一个过程。

反馈量的感知。然而，大多数受访者认为他们的变更收到的反馈量是适当的。8名受访者将评论描述为没有帮助，其中3人提供了更多细节，称被审查的变更是小的配置变更，代码审查对此影响较小。只有2名受访者表示评论发现了错误。

审查时间投入。为了将满意度的答案置于具体情境中，我们还调查了开发者花在审查代码上的时间。为了准确量化审查者花费的时间，我们跟踪了开发者与Critique的互动（例如，打开一个标签页、查看一个差异、评论、批准一个变更）以及其他工具，以估算开发者每周花在审查代码上的时间。我们将开发者的互动序列分组为时间块，将“审查会话”视为与同一个未提交变更相关的一系列互动，由变更作者以外的开发者进行，且每次连续互动之间不超过10分钟。我们汇总了从2016年10月开始的五周内所有审查会话的总小时数，然后计算了每个用户每周的平均值，过滤掉了我们没有全部5周数据的用户。我们发现，开发者平均每周花费3.2小时（中位数为2.6小时）审查变更。这与开源项目自报的每周6.4小时相比要低【索引10，Impact of peer code review on peer impression formation: A survey，Amiangshu Bosu and Jeffrey C Carver，2013，ESEM】。

A4 实验环境

• 数据集：

  • 审查数据：源自谷歌内部代码审查工具Critique的日志。包含了从2014年1月到2016年7月，由超过25,000名作者和审查者创建的约900万个已审查的变更。
  • 评论数据：从2014年9月到2016年7月，从所有变更中收集的约1300万条评论。
  • 访谈数据：与12名谷歌员工进行的半结构化访谈记录。
  • 调查数据：对98名近期提交代码变更的工程师发起的在线问卷，收到44份有效回复。

• 模型架构：

  • 本研究为案例研究，不涉及特定的机器学习或预测模型。

• 硬件配置：

  • 未明确说明，但所有操作均在谷歌的内部基础设施上进行。

• 软件配置：

  • 版本控制：谷歌内部的单一代码库版本控制系统。
  • 代码审查工具：谷歌内部开发的、基于Web的中心化工具Critique。
  • 代码分析工具：集成了谷歌内部的程序分析生态系统Tricorder。
  • 数据分析：使用内部工具对Critique的日志数据进行定量分析。

A4 实验结果

本研究通过对访谈、调查和审查日志数据的分析，得出以下关键结果：

RQ1：代码审查的动机

• 历史动机：代码审查最初被引入谷歌，首要目标是确保代码的可理解性和可维护性，以作为未来工程师的“老师”，而不仅仅是为了发现缺陷。其他附加好处包括知识传递、保证风格和设计一致性、确保充分测试以及提高安全性。
• 当前期望：
  • 开发者当前对代码审查的期望主要围绕四个主题：教育、维护规范、把关和事故预防。
  • 审查历史也被用作未来审计和理解bug引入的工具。
  • 发现1：与之前研究认为的“集体解决问题”不同，谷歌代码审查的期望并不以此为中心，而是更侧重于教育和代码质量。发现缺陷虽受欢迎但不是唯一焦点。
  • 发现2：对特定审查的期望取决于作者和审查者之间的工作关系（如图1所示），例如，与项目负责人审查时更关注教育和规范，而与其他团队合作时则更关注把关。

RQ2：代码审查的实践

• 流程特征：

  • 谷歌的流程与所有权（Ownership）和可读性（Readability）两个核心概念绑定。
  • 工具（Critique）提供审查者推荐和集成的静态分析结果（来自Tricorder）。
  • 发现3：谷歌的流程符合轻量级和灵活的趋同实践（CP1），但通过明确的所有权和可读性要求，以及工具中集成的审查者推荐和代码分析，与其他系统形成了对比。

• 量化指标：

  • 速度与频率（CP2）：审查速度极快，整体中位延迟时间低于4小时，远快于其他公司（14-24小时）。开发者每周产出和审查的变更数量稳定。
  • 变更规模（CP3）：变更规模非常小，中位数仅为24行代码，与开源项目类似，远小于其他企业。
  • 审查者数量（CP4）：审查者数量的中位数为1，这与其他项目中普遍认为的2名审查者最优的结论不同。
  • 发现4：与先前研究的项目相比，谷歌的代码审查趋向于一个审查速度更快、变更规模更小的流程。并且，通常一名审查者即被认为是足够的，而非两名。

RQ3：开发者的感知

• 代码审查中的中断（Breakdowns）：尽管流程成熟，开发者仍会遇到问题，主要源于复杂的交互，分为五类：

  1. 距离：地理或组织上的距离导致延迟和误解。
  2. 社交互动：评论的语气和权力动态可能导致不适。
  3. 审查主题：对审查范围（如是否应包含设计讨论）存在分歧。
  4. 背景：缺乏对变更原因的了解导致期望不匹配。
  5. 工具定制化：工具无法满足特定团队的定制化流程需求。

• 满意度：

  • 尽管存在上述挑战，开发者对代码审查的整体价值评价极高。调查显示，100%的受访者认为谷歌的代码审查是有价值的（见表2）。97%的开发者对Critique工具感到满意。
  • 开发者每周平均花费3.2小时进行代码审查，时间投入相对较低。

• 发现5：尽管经过多年优化，谷歌的代码审查仍面临主要与人际交互复杂性相关的中断。然而，开发者仍然坚定地认为这是一个有价值的过程，并每周投入约3小时参与其中。

A7 补充细节

7.1 一个真正轻量级的流程

谷歌流程的轻量级特性。现代代码审查作为繁琐代码检查的轻量级替代品而生【索引4，Expectations, outcomes, and challenges of modern code review，Alberto Bacchelli and Christian Bird，2013，ICSE】；Rigby和Bird在其跨系统调查中确实证实了这一特性（CP1）【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】。在谷歌，代码审查已经趋向于一个更轻量级的流程，开发者认为这既有价值，又能很好地利用他们的时间。

与其它项目的对比。谷歌的中位审查时间远短于其他项目【索引14，Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down，Jacek Czerwonka, Michaela Greiler, and Jack Tilford，2015，ICSE (SEIP)；索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE；索引34，Peer Review on Open-Source Software Projects: Parameters, Statistical Models, and Theory，Peter C. Rigby, Daniel M. German, Laura Cowen, and MargaretAnne Storey，2014，IEEE Transactions on Software Engineering】。我们推测这些差异是由于谷歌关于代码审查的文化（严格的审查标准和对快速周转时间的期望）。此外，审查者数量存在显著差异（谷歌为一人，而大多数其他项目为两人）；我们认为有一位审查者有助于使审查变得快速和轻量级。

小变更的重要性。低审查时间和少审查者数量可能是代码审查成为开发者工作流程中强制性部分的结果；它们也可能源于小的变更。开源项目的中位变更大小在11到32行之间变化【索引34，Peer Review on Open-Source Software Projects: Parameters, Statistical Models, and Theory，Peter C. Rigby, Daniel M. German, Laura Cowen, and MargaretAnne Storey，2014，IEEE Transactions on Software Engineering】，取决于项目。在公司中，这个变更大小通常更大【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】，有时高达263行。我们发现谷歌的变更大小更接近开源软件：大多数变更都很小。变更的大小分布是代码审查过程质量的一个重要因素。先前的研究发现，随着变更大小的增加，有用评论的数量减少【索引11，Characteristics of useful code reviews: an empirical study at Microsoft，Amiangshu Bosu, Michaela Greiler, and Christian Bird，2015，MSR；索引14，Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down，Jacek Czerwonka, Michaela Greiler, and Jack Tilford，2015，ICSE (SEIP)】，审查延迟增加【索引8，The influence of non-technical factors on code review，Olga Baysal, Oleksii Kononenko, Reid Holmes, and Michael W Godfrey，2013，WCRE；索引24，Will my patch make it? and how fast?: Case study on the linux kernel，Yujuan Jiang, Bram Adams, and Daniel M German，2013，MSR】。大小也影响开发者对代码审查过程的看法；一项对Mozilla贡献者的调查发现，开发者认为与大小相关的因素对审查延迟的影响最大【索引26，Code review quality: How developers see it，Oleksii Kononenko, Olga Baysal, and Michael W Godfrey，2016，ICSE】。谷歌承认变更大小与审查质量之间的相关性，并强烈鼓励开发者进行小的、增量的变更（大型删除和自动化重构除外）。这些发现和我们的研究支持了审查小变更的价值，以及需要研究和工具来帮助开发者创建这样小的、自包含的代码变更以供审查【索引6，Helping developers help themselves: Automatic decomposition of code review changesets，Mike Barnett, Christian Bird, João Brunet, and Shuvendu K Lahiri，2015，ICSE；索引15，Untangling fine-grained code changes，Martín Dias, Alberto Bacchelli, Georgios Gousios, Damien Cassou, and Stéphane Ducasse，2015，SANER】。

7.2 实践中的软件工程研究

谷歌实践与研究的结合。谷歌代码审查中的一些实践与软件工程研究中提出的实践是一致的。例如，一项关于微软代码所有权的研究发现，由次要贡献者所做的变更应受到更严格的审查以提高代码质量【索引9，Don’t touch my code!: examining the effects of ownership on software quality，Christian Bird, Nachiappan Nagappan, Brendan Murphy, Harald Gall, and Premkumar Devanbu，2011，FSE】；我们发现这个概念在谷歌通过要求所有者批准来强制执行。此外，先前的研究表明，通常一个变更的一名审查者会承担检查代码是否符合规范的任务【索引4，Expectations, outcomes, and challenges of modern code review，Alberto Bacchelli and Christian Bird，2013，ICSE】；可读性使这个过程更加明确。在下文中，我们关注Critique的特性，这些特性使其成为“下一代代码审查工具”【索引26，Code review quality: How developers see it，Oleksii Kononenko, Olga Baysal, and Michael W Godfrey，2016，ICSE】。

审查者推荐。研究人员发现，对被审查代码有先验知识的审查者会给出更有用的评论【索引4，Expectations, outcomes, and challenges of modern code review，Alberto Bacchelli and Christian Bird，2013，ICSE；索引11，Characteristics of useful code reviews: an empirical study at Microsoft，Amiangshu Bosu, Michaela Greiler, and Christian Bird，2015，MSR】，因此工具可以增加对审查者选择的支持【索引11，Characteristics of useful code reviews: an empirical study at Microsoft，Amiangshu Bosu, Michaela Greiler, and Christian Bird，2015，MSR；索引26，Code review quality: How developers see it，Oleksii Kononenko, Olga Baysal, and Michael W Godfrey，2016，ICSE】。我们看到审查者推荐是工具支持的，优先考虑那些最近编辑/审查过相关文件的人。这证实了最近的研究，即频繁的审查者对模块的演进做出巨大贡献，应与频繁的编辑者一同被考虑【索引40，Revisiting code ownership and its relationship with software quality in the scope of modern code review，Patanamon Thongtanunam, Shane McIntosh, Ahmed E Hassan, and Hajimu Iida，2016，ICSE】。在谷歌的实践中，找到合适的审查者似乎不成问题，事实上，实现的推荐模型很直接，因为它可以编程地识别所有者。这与其他提出的工具形成对比，后者识别审查过相似名称文件的审查者【索引43，Automatically recommending peer reviewers in modern code review，Motahareh Bahrami Zanjani, Huzefa Kagdi, and Christian Bird，2016，IEEE Transactions on Software Engineering】或考虑诸如评论数量等特征【索引42，Who should review my code? A file location-based code-reviewer recommendation approach for modern code review，Patanamon Thongtanunam, Chakkrit Tantithamthavorn, Raula Gaikovina Kula, Norihiro Yoshida, Hajimu Iida, and Ken-ichi Matsumoto，2015，SANER】。在谷歌，还有一个重点是处理审查者的工作量和临时缺席（与微软的一项研究一致【索引4，Expectations, outcomes, and challenges of modern code review，Alberto Bacchelli and Christian Bird，2013，ICSE】）。

静态分析集成。一项对88名Mozilla开发者的定性研究【索引26，Code review quality: How developers see it，Oleksii Kononenko, Olga Baysal, and Michael W Godfrey，2016，ICSE】发现，静态分析集成是代码审查最常被请求的功能。自动化分析允许审查者专注于变更的可理解性和可维护性，而不是被琐碎的评论（例如，关于格式化）分心。我们在谷歌的调查向我们展示了在代码审查工具中集成静态分析的实际意义。Critique集成了为分析编写者提供的反馈渠道【索引36，Tricorder: building a program analysis ecosystem，Caitlin Sadowski, Jeffrey van Gogh, Ciera Jaspan, Emma Söderberg, and Collin Winter，2015，ICSE】：审查者可以选择点击分析生成的评论上的“请修复”，作为作者应该修复该问题的信号，作者或审查者都可以点击“无用”，以标记在审查过程中没有帮助的分析结果。具有高“无用”点击率的分析器会被修复或禁用。我们发现这个反馈循环对于维持开发者对分析结果的信任至关重要。

超越协作审查的审查工具。最后，我们发现了强有力的证据，表明Critique的用途超出了代码审查的范畴。变更作者使用Critique来检查差异和浏览分析工具的结果。在某些情况下，代码审查是变更开发过程的一部分：审查者可能会发出一个未完成的变更，以决定如何完成实现。此外，开发者还使用Critique来检查已提交变更的历史，即使这些变更早已被批准；这与Sutherland和Venolia所设想的将代码审查数据用于后续开发有益的用途是一致的【索引38，Can peer code reviews be exploited for later information needs?，Andrew Sutherland and Gina Venolia，2009，ICSE】。未来的工作可以研究代码审查工具这些意想不到且可能具有影响力的非审查用途。

7.3 知识传播

通过代码审查实现知识转移。知识转移是Rigby和Bird工作中出现的一个主题【索引33，Convergent software peer review practices，Peter C Rigby and Christian Bird，2013，FSE】。为了衡量代码审查带来的知识转移，他们基于先前通过变更文件数量来衡量专业知识的工作【索引28，Expertise browser: a quantitative approach to identifying expertise，Audris Mockus and James D Herbsleb，2002，ICSE】，测量了变更、审查的不同文件数量，以及这两个集合的并集。他们发现，由于代码审查，开发者了解了更多的文件。

量化知识传播的效果。在谷歌，知识转移是代码审查教育动机的一部分。我们试图通过查看评论和编辑/审查的文件来量化这种效果。随着开发者在谷歌工作的经验积累，他们变更上的平均评论数量会减少（图2）。

经验与评论数的关系。在谷歌工作不到一年的开发者，每次变更的评论数通常是其他人的两倍多。先前的工作发现，作者认为审查者带有问题的评论没有用，而无用评论的数量随着经验的增加而减少【索引11，Characteristics of useful code reviews: an empirical study at Microsoft，Amiangshu Bosu, Michaela Greiler, and Christian Bird，2015，MSR】。我们推测这种评论减少是由于审查者随着对代码库的熟悉而需要问的问题变少，并证实了代码审查的教育方面可能随时间推移而得到回报的假设。

任职年限与文件接触量的关系。此外，我们可以看到，谷歌工程师编辑和审查的不同文件数量，以及这两个集合的并集，都随着资历的增加而增加（图3），并且看到的文件总数明显大于仅编辑的文件数。对于这张图，我们按开发者在公司工作的时间（以3个月为增量）对他们进行分组，然后计算他们编辑和审查的文件数量。未来的工作可以更有趣地去理解审查文件如何影响开发者的熟练度（fluency）【索引44，Developer Fluency: Achieving True Mastery in Software Projects，Minghui Zhou and Audris Mockus，2010，FSE】。

A5 结论

我们的研究发现，代码审查是谷歌开发工作流程中一个重要的方面。各种角色的开发者都认为它带来了多重好处，并提供了一个开发者可以相互教授代码库知识、维护团队代码库完整性，以及建立和演进确保代码库可读性和一致性的规范的情境。开发者表示他们对代码审查的要求感到满意。绝大多数变更是小型的，只有一个审查者，并且除了授权提交外没有其他评论。在一周内，70%的变更在发出初次审查后不到24小时内就被提交。这些特性使得谷歌的代码审查比其他采用类似流程的项目更轻量级。此外，我们发现谷歌在其实践中融入了多项研究思想，使得当前研究趋势的实际应用变得可见。