关于javascript:现代代码审查Google案例研究

摘要

应用基于工具的轻量级代码查看代码更改（又名古代代码审查）已成为宽泛的标准，利用于各种开源和产业零碎。在本文中，咱们对 Google 的古代代码审查进行了探索性钻研。Google 很早就引入了代码审查并通过多年的倒退；咱们的钻研揭示了为什么 Google 引入了这种做法并剖析了以后的状态，通过数十年的代码变更和数百万条代码审核。通过 12 次访谈，对 44 位受访者的考察以及剖析的 900 万条已审核变更的审核日志，咱们考察了 Google 进行代码审查的动机，以后做法，以及开发人员的满意度和挑战。

1. 引言

对等代码审查，是除了作者以外的开发者们对源代码进行手动查看，被认为是对进步软件我的项目品质的一种有价值的工具。在 1976 年，Fagan 正式制订了高度结构化的代码审查流程——代码查看。多年来，钻研人员提供了无关代码查看的劣势的证据，特地是在发现缺点上，但麻烦的是费时，这种办法的同步性特点妨碍了它在实践中的推广。现今，大多数组织都采纳更轻量级的代码审查实际来限度查看效率低下。古代代码审查是（1）非正式（与 Fagan 格调相同），（2）基于工具的，（3）异步，（4）聚焦于审查代码更改。

一个凋谢的钻研挑战是：在这种新鲜的背景下，理解哪些实际代表了贵重而无效的审查办法。Rigby 和 Bird 定量分析了来自跨畛域软件我的项目以及组织的代码审查数据，发现五个高度趋同的方面，他们猜测其余的我的项目也有这个规律性。Rigby 和 Bird 的剖析基于有价值的宽泛的观点（剖析了多个来自不同的环境的我的项目）。对于由 Basili 提倡的常识实证体系的倒退，同样重要的是要思考对单个案例进行剖析的集中和纵向的观点。本文扩大了 Rigby 和 Bird 的工作，着重于审查实际和特色，次要是：在 Google 成立，一家公司领有数十年的代码审查的历史和大量的每日审查借鉴。本文能够（1）对从业人员规定进行代码审查和（2）吸引钻研人员想理解和反对这一新鲜过程的人。

从 Google 十分晚期的历史开始，代码审查就曾经成为软件开发中必不可少的一部分；因为它很早就引入了，曾经成为了 Google 文化的一个外围局部。在 Google，代码审查的过程和工具通过重复欠缺了十多年，利用在每天寰球数十个办公室中，超过 25,000 名开发人员的超过 20,000 行源代码的更改。

咱们以探索性考察模式进行剖析聚焦于代码审查的三个方面，并扩大了 Rigby 和 Bird 的成绩：（1）驱动代码审查的动机，（2）以后实际，以及（3）开发人员对代码审查的感触，专一于特定审查遇到的挑战（审核过程中的中断）和满意度。咱们的钻研办法联合了来自多个数据源的输出：对 Google 开发人员进行 12 次半结构化的访谈；一个外部考察，发送给了最近做个变更审查的工程师，并收到 44 条回复；一组来自两年间的 Google 代码审查工具产生的 900 万条评论的数据。

咱们发现：相比其余状况，Google 的流程显著更轻松，基于一位审阅者，疾速迭代，小更改，以及集成严密代码审查工具。因为围绕代码审查产生的交互是简单的，中断审查依然存在。不过，开发人员认为此过程很有价值，确信当规模很大的时候，能够很好地发挥作用，并且，进行这个过程有若干起因，也取决于作者与审查者之间的关系。最初，咱们发现对于应用代码审查工具，不仅能够合作审查，而且还有个一个很重要的发现：代码审查能够作为一种教学工具。

2. 背景和相干工作

咱们形容了文献钻研中的审查过程，而后咱们具体介绍这些交融代码审查的做法流程。

2.1 代码审查过程和情景

代码查看。软件查看是第一个正式的代码审查流程。这个高度结构化的过程波及打算，概述，筹备，查看会议，返工和跟进。代码查看的指标是在同步查看会议中发现缺点，作者和审稿人坐在同一会议室内来查看代码更改。Kollanus 和 Koskinen 汇编了无关代码查看的最新文献考察钻研。他们发现绝大多数对于代码查看的钻研实质上是经验性的。代码查看作为一种发现缺点的技术的整体价值和促使检查者读代码的价值存在共识。总体而言，与 Internet 的遍及和异步代码审查流程的增长，自 2005 年以来，代码查看的钻研有所降落。

通过电子邮件进行异步审查。直到 2000 年代前期，大多数大型 OSS 我的项目都采纳一种近程异步审查的模式，这依赖于补丁发送的通信渠道，如邮件列表和问题跟踪零碎。在这种状况下，我的项目成员评估奉献的补丁程序并通过这些渠道申请批改。当补丁被认为品质足够高时，外围开发人员会将其提交给代码库。受信赖的提交者可能具备提交到审查过程，而不是进行提交前的审查。Rigby 等人，是最早在这种环境下进行宽泛工作的人之一；他们发现，这种类型的审查“与 [代码查看] 简直没有共同点，只是置信同行会无效地发现软件缺陷”。Kononenko 等人，剖析了这种状况，并且发现审查响应工夫和接受程度和社会因素相干，例如，审查者的工作量和扭转作者的教训，这些是代码查看所无奈反映的。

基于工具的审查。为了使修补程序审查的过程构造更加正当，OSS 和工业设置中呈现了几种工具。这些工具反对审阅过程的长久工作：（1）补丁的作者将其提交给代码审阅工具，（2）审阅者能够看到倡议代码与更改的差别，（3）能够与作者和其余审稿人就特定的话题展开讨论，而后（4）作者能够提出修改意见，以解决评审者的意见。此反馈周期将继续到每个人都称心或补丁被抛弃为止。不同的我的项目应用了他们的工具来反对他们的过程。Microsoft 应用 CodeFlow，该工具跟踪每个人（作者或审阅者）的状态以及他们在过程中的地位（签名，期待，审阅）；CodeFlow 不会阻止作者未经批准而提交更改，并反对在评审线程中聊天。Google 的 Chromium 我的项目（以及其余几个 OSS 我的项目）依赖于内部可用的 Gerrit；在 Chromium 中，只有通过审阅者的明确批准并主动确认更改不会毁坏构建，更改才会合并到 master 分支中。在 Gerrit 中，未调配审查者也能够发表评论。VMware 开发了开源的 ReviewBoard，它将动态剖析集成到审查过程中。这种集成依赖于变更作者手动申请剖析，并且曾经证实能够进步代码审查的品质。Facebook 的代码审查零碎 Phabricator，使审查者能够“接管”更改并自行提交，并提供了挂钩以进行主动动态剖析或继续的构建 / 测试集成。

在基于工具审查的背景下，钻研人员考察了代码更改承受或响应工夫与更改后的代码和作者的特色之间的关系，以及审阅者之间的协定。依据工业和 OSS 开发人员的意见，还进行了定义什么形成良好的代码审查。

基于分叉模式的开发模型。在 GitHub 上，拉申请的过程中，开发人员想要对现有的 git 仓库进行更改，就要对其 fork 进行更改。在收回拉申请后，会呈现在拉申请的列表中展现我的项目中的问题，任何能够看到该项目标人都能够看到。Gousios 等人对拉申请集成者和贡献者的实际和碰到的问题进行了定性钻研，发现与基于工具的代码审查有相似的办法。

2.2 代码审查中的交融实际

Rigby 和 Bird 提出了第一项也是最重要的工作，这些工作试图跨几个代码审查过程和上下文确定交融的实际。他们思考了应用基于电子邮件审查的 OSS 我的项目，应用 Gerrit 的 OSS 我的项目，应用根本代码审查工具的 AMD 我的项目以及应用 CodeFlow 的 Microsoft。他们剖析了这些我的项目的过程和数据，以形容多个角度，例如迭代开发，审查者抉择和审查探讨。他们确定了所有已思考我的项目都交融到的五种古代代码审查实际（表 1）。咱们将应用其 ID（例如 CP1）来援用这些做法。基本上，他们在疾速，轻量级过程（CP1，CP2，CP3）方面达成了统一，很少有人参加（CP4）进行小组问题解决（CP5）。

3. 方法论

本节形容了咱们钻研的问题和背景；它还概述了咱们的钻研办法及其局限性。

3.1 钻研的问题

这项钻研的总体目标是考察 Google 的古代代码审查，这一过程波及成千上万的开发人员，并且通过了十多年的改良。为此，咱们进行了探索性考察，围绕三个次要钻研问题进行了结构设计。

RQ1：Google 进行代码审查的动机是什么？Rigby 和 Bird 发现动机是古代代码审查的交融特色之一（CP5）。在此能够理解，动机和冀望推动了 Google 的代码审查。特地是，咱们既思考了引入古代代码审查的历史起因（因为 Google 是最早应用古代代码审查的公司之一），也思考了以后的冀望。

RQ2：Google 的代码审查实际是做什么？ Rigby 和 Birdregard 依据流程（CP1），速度和频率（CP2），剖析变更的大小（CP3）和审阅者数量（CP4）来执行流程自身。咱们对 Google 的这些方面进行了剖析，以考察与以前的钻研相比，对于具备更长代码审查历史，明确文化和大量审查记录的公司来说，同样的发现是否成立。

RQ3：Google 开发人员如何对待代码审查？最初，在咱们的最初一个钻研问题中，咱们有趣味理解 Google 开发人员如何对待其公司中已施行的古代代码审查。为了更好的了解实际（因为感知驱动口头）和领导将来的钻研，这个摸索很必须。咱们聚焦于两方面：一些特定的审查，比方：开发人员有中断审查的经验；在面临一些挑战时开发人员对审查是否称心。

3.2 钻研的背景

咱们简要形容了对于咱们方法论的钻研背景。无关 Google 代码审查过程和工具的具体阐明，请参见第 5.1 节。

Google 的大多数软件开发都在一个整体的源代码存储库中（mono-repo），通过外部版本控制系统拜访。因为 Google 代码审查是必须的，因而，每次向 Google 源代码控制系统提交代码，都先要应用 CRITIQUE 进行代码审查，CRITIQUE 是一个外部开发的，集中的，基于 Web 的代码查看工具。开发工作流程基于 Google 的整体代码库，包含代码审查过程，是十分对立的。就像第 2 节中形容的工具一样，CRITIQUE 容许审查者看到提议更改代码和开始探讨前明确的代码行处。CRITIQUE 提供了大量的登录性能；记录开发者应用该工具的交互（包含关上工具，查看差别，创立评论和承受更改）。

3.3 钻研的办法

为了答复咱们的钻研问题，咱们采纳定性和定量相结合的办法，该办法联合了以下几种起源的数据：在与 Google 从事软件开发工作的员工进行的半结构化访谈，来自代码审查工具的日志以及对其余员工的考察。咱们应用访谈作为一种工具来收集无关进行代码审查（RQ1）动机的多样性（与频率绝对比）的数据，并激发开发人员对代码审查及其挑战（RQ3）的了解。咱们应用 CRITIQUE 的日志来量化和形容以后的审查实际（RQ2）。最初，咱们应用考察来确认访谈（RQ1）中呈现的代码审查的多种动机，和激发开发人员对过程的满意度的因素。

谈判。咱们与选定的 Google 员工进行了一系列面对面的半结构化访谈，每次访谈大概须要 1 个小时。最后的可能参加者是应用滚雪球采样法来抉择的，首先是论文作者所晓得的开发人员。从此库中，抉择参与者以确保团队的扩散，技术畛域，工作角色，公司外部的工夫长度以及在代码审核过程中的角色。访谈脚本包含无关代码审查的动机，最近审查 / 撰写的变更，以及最佳 / 最差审查经验的问题。在每次访谈之前，咱们都会回顾参与者的审查历史，并找到要在访谈中会探讨的更改；咱们抉择这些更改，是依据互动次数，参加对话的人数，以及是否有很多令人诧异审查点评。在访谈的察看局部中，要求参与者在审阅行将产生的变更时思考，并提供一些明确的信息，例如开始审阅的切入点。访谈始终继续到达到饱和，并且访谈提出了大抵类似的概念。总体而言，咱们对从 Google 工作 1 个月到 10 年（均匀 5 年），软件工程和站点可靠性工程的员工进行了 12 次面试。他们包含技术主管，经理和集体贡献者。每次访谈波及三到四个人：参与者和 2 - 3 个受访者（其中两个是本文的作者）。采访由一名采访者实时转录，而另一名采访者提出问题。

采访数据的凋谢编码。为了确定采访数据中呈现的宽泛主题，咱们进行了一次凋谢编码。两位作者探讨了访谈笔录，以确立独特的主题，而后将其转换为编码方案。而后，另一位作者对探讨的正文进行了关闭编码，正文是对确认的主题。咱们对其中不止一个采访进行了迭代，直到咱们就该打算达成协议。咱们还跟踪了上下文（审稿人与作者之间的关系）中提到的这些主题。问题设计和剖析过程的联合意味着咱们能够探讨后果中的稳固主题，但不能有意义地探讨产生的绝对频率。

审查数据的剖析。咱们定量的剖析数据，数据是代码审查过程中应用 CRITIQUE 产生的日志。咱们次要关注 Rigby 和 Bird 发现的交融实际（CP）相干的指标。为了不便比照，咱们不思考没有审查者的更改，因为咱们对有明确代码审查过程的更改感兴趣。咱们将“审阅者”视为批准代码更改的任何用户，而不管更改作者是否明确要求他们进行审阅。咱们应用基于名称的启发式的办法来自动化流程产生的更改。咱们专门关注 Google 次要代码库中产生的更改。咱们还排除了在钻研时尚未落实的更改，以及咱们的差别工具报告的源码零行变动量的更改，例如，仅批改二进制文件的更改。在 Google，均匀每个工作日，提交了约 20,000 个合乎上述过滤条件的更改。咱们的最终数据集包含 2014 年 1 月至 2016 年 7 月，由 25,000 多名作者和审阅者创立的合乎这些规范的大概 900 万项更改，以及从 2014 年 9 月至 2016 年 7 月之间的所有更改中收集的大概 1300 万条审查评论。

考察。咱们创立了一个在线调查表，并发送给了 98 位最近提交了代码更改的工程师。代码更改曾经过审核，因而咱们定制了调查表，以询问受访者如何对待代码审核，对于他们最近的特定更改；这种策略使咱们能够加重召回偏见，但仍能够收集全面的数据。该考察包含三个对于收到的评论的价值的 Likertscale 问题，一个对于评论对其更改影响的多项抉择（基于访谈产生的冀望）和一个可选的“其余”答复，以及一个开放式 - 最终提出质疑，以引起受访者对所收到的评论，代码评论工具和 / 或整个过程的意见。咱们收到了 44 份无效的考察问卷回答（45%的回答率，在软件工程钻研中被认为很高了）。

3.4 有效性和局限性的威逼

咱们形容了钻研办法所带来的对有效性和工作成绩局限性的威逼，以及为缓解这些挑战所采取的口头。

外部有效性——可信度。对于评论数据的定量分析，咱们应用启发式办法从定量分析中滤除机器人撰写的更改，但这些启发式办法可能容许某些机器人撰写的更改；咱们对此进行了缓解，因为咱们仅包含具备人工审核者的由机器人撰写的更改。对于定性考察，咱们应用了开放式编码来剖析受访者的答案。该编码可能会受到编写该编码的作者的教训和动机的影响，只管会通过让多个编码人员参加来加重这种偏见。决定加入咱们的访谈并自由选择考察的员工决定这样做，从而引入了自我抉择偏见的危险。因而，对于不抉择参加的开发人员而言，后果可能会有所不同；为加重此问题，咱们将访谈和考察中的信息相结合。此外，咱们应用雪球抽样办法来确定要面试的工程师，这有抽样偏差的危险。只管咱们试图通过面试具备各种工作角色和职责的开发人员来加重这种危险，但咱们访谈的开发人员可能有其余因素在整个公司中并不实用。为了加重主持人的承受偏见，参加定性数据收集的钻研人员不属于 CRITIQUE 团队。社会可取性偏见可能曾经影响了答案，使其更适宜 Google 文化。然而，在 Google 激励人们批评和改良发现的工作流程，从而缩小这种偏见。最初，咱们没有采访与专家评审员（例如平安评审）进行交互的钻研科学家或开发人员，因而咱们的后果偏差于个别开发人员。

通用性——可移植性。咱们的后果可能无奈推广到其余状况，而是咱们对多年实际和数百万次细化查看后，仍会产生的多种多样的做法和审查中断感兴趣。鉴于根本代码查看机制在多个公司和 OSS 我的项目中的相似性，有理由认为，如果审查过程达到雷同的成熟度并应用可比拟的工具，则开发人员将具备相似的教训。

4. 后果：能源

在咱们的第一个钻研问题中，咱们首先要钻研导致这一过程的起因，从而寻求了解开发人员在 Google 进行代码审查时的动机和冀望。

4.1 所有如何开始

Google 的代码审查最早是由第一批员工之一引入的；本文的第一作者采访了该员工（以下简称 E），以更好地了解代码审查及其演变的最后动机。E 解释了代码审查引入的次要推动力是：迫使开发人员编写其余开发人员能够了解的代码 ; 这被认为很重要，因为代码必须作为将来开发人员的老师。Google 在代码审查中的引入标记着从钻研代码库（已优化为疾速原型开发）向生产代码库的过渡，在此基础上思考将来工程师浏览源代码。代码审查也被认为可能确保不止一个人相熟每一段代码，从而减少了常识在公司中的驻留机会。

E 重申了这样一个概念，即只管审阅者发现错误是很棒的，但在 Google 引入 codereview 的首要起因是为了进步代码的可了解性和可维护性。然而，除了最后进行代码审查的教育动机外，E 解释说，开发人员的三个其余益处很快就在外部对开发人员变得不言而喻：查看款式和设计的一致性；确保足够的测试；通过确保没有任何开发人员能够在没有监督的状况下提交任意代码来进步安全性。

4.2 目前的冀望

通过对访谈数据进行编码，咱们确定了 Google 开发人员冀望从代码审查中取得的四个要害主题：教育 ， 保护标准 ， 把关 和事变预防。教育从代码审查中学习或学习，并与引入代码审查的最后起因保持一致；标准是指组织对自由选择的偏好（例如格局或 API 应用模式）; 网守波及围绕源代码，设计抉择或其余工件的边界的建设和保护；事变是指引入谬误，缺点或其余与品质相干的问题。

这些是审查过程中的次要主题，然而代码审查也用于 追溯历史。开发人员在审查过程实现后对其进行评估；代码审查能够浏览历史记录 代码更改的内容，包含产生了什么正文以及更改如何演变。咱们还留神到开发人员应用代码回顾历史来理解谬误的引入形式。从实质上讲，代码审查使未来的变更审核成为可能。

在咱们的考察中，咱们进一步验证了这种编码方案。他们能够抉择四个主题中的一个或多个主题和 / 或本人撰写。较早确定的四个主题中的每个主题都是在特定代码审查的背景下由 8 至 11 个受访者抉择的，因而，能够更加确信上述编码方案与开发人员对代码审查价值的了解相一致。

只管这些冀望能够笼罩以前在 Microsoft [4]上取得的冀望，但正如咱们的参与者所解释的那样，Google 的次要重点是教育以及代码的可读性和可了解性，这与历史动因相吻合。因而，关注点与 Rigby 和 Bird 的关注点不统一（即，小组解决问题的流动）[33]。

发现 1. Google 进行代码审查的冀望并不以解决问题为核心。Google 引入审核，目标是确保代码的可读性和可维护性。当今的开发人员除了保护标准，跟踪历史记录，保护措施和预防事变外，还从教育角度进行了理解。发现缺点受到欢送，但不是惟一的重点。

如前所述，在对访谈笔录进行编码时，咱们还跟踪了提到主题的评论上下文，咱们发现这些不同主题的绝对重要性取决于作者与评论者之间的关系（图 1）。例如，保护工程师与具备不同资格的工程师（我的项目负责人，专家可读性审阅者或“新”团队成员）之间的标准抵触，而与伙伴或其余团队相比则少一些，而看门人和事变预防则是次要的。具备宽泛的价值，并蕴含多种不同的关系。

图 1. 关系图，形容了哪些评论冀望主题次要呈现在特定作者 / 评论者上下文中。

发现 2. 对 Google 进行特定代码审查的冀望取决于作者与审查者之间的工作关系。

5. 后果：实际

在咱们的第二个钻研问题中，咱们形容了代码重审过程，并将其定量方面的内容与先前工作中发现的趋同做法进行了比拟[33]。

5.1 形容审查过程

Google 的代码审查与两个概念相干：所有权和可读性。咱们首先介绍它们，而后形容审阅过程的流程，而后得出外部审阅工具 CRITIQUE 与其余审阅工具不同的特点。

所有权。Google 代码库以树结构排列，其中每个目录都由一组人员明确领有。只管任何开发人员都能够提议对代码库的任何局部进行更改，然而相干目录（或父目录）的所有者必须在提交更改之前对其进行审核和批准；甚至目录所有者也要在提交之前查看其代码。

可读性。Google 定义了一个称为可读能力的概念，该概念很早就引入了，以确保代码库中的代码格调和标准保持一致。开发人员能够应用特定语言取得可读性认证。为了利用可读性，开发人员将更改发送给一组有可读能力的审阅者。一旦这些审阅者确信开发人员理解某种语言的代码格调和最佳实际，便会为开发人员授予该语言的可读性。每次更改都必须由具备所应用语言可读性证实的人员编写或审阅。

代码审查流程。审查流程与评论紧密结合，其工作形式如下：

1。创立：作者开始批改，增加或删除某些代码；一旦筹备好，他们就会进行更改。

2。预览：作者而后应用 CRITIQUE 来查看更改的差别，并查看主动代码分析器的后果（例如，来自 Tricorder [36]）。准备就绪后，作者将更改发送给一个或多个审阅者。

3。评论：审阅者能够在 Web UI 中查看差别，并随时起草评论。程序剖析后果（如果存在）也对审阅者可见。未解决的评论显示为变更作者必须解决的操作我的项目。已解决的评论包含可选或信息性评论，可能不须要变更作者采取任何口头。

4。解决反馈：作者当初能够通过更新更改或通过回复评论来解决正文。更新更改后，作者将上载新快照。作者和审阅者能够查看任意一对快照之间的差别，以理解产生了什么变动。

5。批准：解决所有评论后，评论者会批准该更改并将其标记为“LGTM”（对我来说很好 Looks Good To Me）。要最终进行更改，开发人员通常必须至多取得一名审阅者的批准。通常，只需一名审阅者即可满足上述所有权和可读性要求。

咱们尝试量化“轻量级”审阅的形式（CP1）。咱们通过查看变更作者邮寄了一组可解决以前未解决的正文的评论来掂量评论中来回的次数。咱们假如一个迭代对应于一个作者解决某个评论的一个实例；零反复意味着作者能够立刻提交。咱们发现所有更改中有 80%以上最多波及解决评论的反复。

倡议审阅者。要确定最佳的人来从新审阅更改，CRITIQUE 依附一种工具来剖析变更并倡议可能的审阅者。此工具确定满足更改中所有文件的审阅要求所需的最小审阅者集。请留神，通常只须要一名审阅者，因为更改通常是由领有文件查问所有权和 / 或可读权的人创作的。该工具对最近编辑和 / 或审阅所蕴含文件的审阅者进行优先级排序。因为尚未建设新的团队成员，因为他们尚未建设审核 / 编辑历史记录，因而已明确增加为他们。未调配的审阅者还能够对更改发表评论（并可能批准）。寻找审阅者的工具反对通常仅在文件更改超出特定团队的状况下才须要。在一个团队内，开发人员晓得向谁发送更改。为了将可能发送给团队中任何人的更改，许多团队应用一种零碎，该零碎将循环发送到团队电子邮件地址的审阅调配给配置的团队成员，同时思考到审阅负载和休假。

代码剖析后果。CRITIQUE 将代码剖析结果显示为正文以及人工正文（只管色彩不同）。剖析人员（或审阅者）能够提供倡议的编辑，这些编辑能够被提议，也能够通过评论利用于变更。为了在更改提交之前审核更改，Google 的开发还包含预提交挂钩：查看失败须要开发人员显式笼罩以启用提交的中央。提交前查看包含根本的主动款式检查和运行与变更相干的自动测试套件。所有预提交查看的后果在代码查看工具中可见。通常，会主动触发预提交查看。这些查看是可配置的，以便团队能够强制施行特定于我的项目的不变量，并主动将电子邮件列表增加到更改中，以进步意识和透明度。除了事后提交后果外，CRITIQUE 还能够通过 Tricorder [36]显示各种主动代码剖析的后果，这些剖析可能不会阻止提交更改。剖析后果包含简略的款式查看，更简单的基于编译器的剖析通过以及特定于我的项目的查看。目前，Tricorder 包含 110 个分析仪，其中 5 个是用于数百次附加查看的插件零碎，总共可剖析 30 多种语言。

发现 3. Google 代码审核过程与轻量级和灵便的交融做法保持一致。然而，与其余钻研过的零碎相比，所有权和可读权是明确的，并且起着关键作用。审阅工具包含审阅者举荐和代码剖析后果。

5.2 量化审核流程

咱们复制了 Rigby 和 Bird 发现的 CP2- 4 的定量分析，以便将这些实际与 Google 交融的特色进行比拟。

审查频率和速度。Rigby 和 Bird 发现快节奏的迭代开发也实用于古代代码审查：在他们的我的项目中，开发人员的工作距离十分短。为了找到答案，他们剖析了评论的频率和速度。

在 Google，就频率而言，咱们发现处于中位数上的开发者每周大概进行 3 次更改，而 80%的开发者每周进行少于 7 次更改。同样，开发人员每周审核的变更中位数为 4，而 80%的审阅者每周审核的变更少于 10。在速度方面，咱们发现开发人员必须期待对其更改的初步反馈，对于较小的更改，均匀工夫少于一小时，对于较大的更改，均匀工夫少于 5 小时。整个审阅过程的总体（所有代码大小）中值提早小于 4 小时。这比 Rigby 和 Bird [33]报告的均匀批准工夫要低得多，AMD 的批准工夫中位数为 17.5 小时，Chrome OS 为 15.7 小时，三个 Microsoft 我的项目为 14.7、19.8 和 18.9 小时。另一项钻研发现，微软批准的均匀工夫为 24 小时[14]。

审查规模。Rigby 和 Bird 认为，只有通过较小的变更来审查并随后剖析审查规模，能力实现疾速审查工夫。在 Google，正在思考的更改中，超过 35%仅批改一个文件，而大概 90%的批改少于 10 个文件。超过 10%的更改仅批改一行代码，而批改的行数的中位数为 24。更改位数的中位数显着低于 Rigby 和 Bird 对 AMD（44 行），Lucent（263 行）和 Bing 等公司的报告。，Microsoft 的 Office 和 SQLServer（在这些界线之间的某个地位），但合乎凋谢源代码我的项目中的更改大小[33]。

审查者和评论的数量。甚至在通过深入研究的代码查看中，钻研人员的最佳人数始终存在争议[37]。Rigby 和 Bird 考察了所思考的我的项目是否收敛到了相似数量的参加评审人员。他们发现这个数字是两个，无论是否明确邀请了审阅者（例如，在 Microsoft 我的项目中，邀请的中位数最多为 4 个审阅者），或者是否公开播送了更改以进行审阅[33]。

相比之下，在 Google 中，只有不到 25%的更改领有多于一名审阅者，而超过 99%的更改最多具备五名审阅者，中位审阅者人数为 1。较大的更改通常均匀会领有更多的审阅者。然而，即便均匀变动十分大，均匀也须要不到两名审稿人。

Rigby 和 Bird 还发现“当沉闷于 [超过 2] 位审稿人时，无关更改的评论数量起码”[33]，并得出结论，两名审稿人发现缺点的最佳数量。在 Google，状况有所不同：审阅人数越多，对更改的评论平均数就越多。此外，每次更改的均匀正文数随行数的变动而减少，对于大概 1250 行的更改，每个更改的最高正文数为 12.5。大于此的更改通常蕴含主动生成的代码或较大的删除，从而导致均匀正文数较低。

发现 4. 与先前考察的其余我的项目相比，Google 的代码审查已将审查过程交融到一个过程中，该过程的审查速度显着放慢且变更幅度较小。此外，与其余我的项目中的两名审阅者相比，一名审阅者通常被认为足够。

6. 后果：开发人员的认识

咱们最初一个钻研问题是通过 Google 的代码审查来考察开发人员的挑战和满足感。

6.1 Google 的代码审查中断

以前的钻研考察了整个审查过程中的挑战[4,26]，并提供了令人信服的证据，这也被咱们作为工程师的教训所证实，了解要审查的代码是一个次要阻碍。为了拓宽咱们的教训常识体系，咱们在这里集中探讨特定审查（“审查中断”）中遇到的挑战，例如延误或一致。

对咱们的访谈数据的剖析提出了五个次要主题。前四个主题认为审查中断在过程中的相干因素有：

间隔：受访者从两个角度感知代码审阅的间隔：天文（即作者与审阅者之间的物理间隔）和组织（例如不同团队或不同角色之间的物理间隔）。这两种类型的间隔都被认为是导致审阅过程提早或导致误会的起因。

社会互动：受访者认为代码审阅中的交换有可能从两个方面导致问题：措辞和势力。措辞是指有时作者对评论发表敏感的事实。对评论的情感剖析提供了证据，表明带有负面语气的评论不太可能有用[11]。权力是指应用代码审查过程来诱使别人扭转本人的行为；例如，迁延审核或保留批准。措辞或权力在审查中，可能会使开发人员对查看过程感到不难受或丧气。

审查主题：访谈提到了对于代码审查是否是从新审查某些方面的最合适上下文（尤其是设计审查）的一致。这导致期望值不匹配（例如，某些团队心愿大多数设计在第一次审阅之前实现，其余团队心愿在审阅中探讨设计），这可能导致参与者之间以及过程中产生摩擦。

背景：受访者让咱们看到，因为不晓得是什么导致了这种变动，所以会产生误解；例如，如果变更的理由是解决生产问题的紧急解决方案或“有个不错的改良”。预期后果的不匹配会导致提早或丧气。

最初一个主题是工具自身：

定制化：一些团队对代码审查有不同的要求，例如，对于须要多少审查者。这是技术上的审查中断，因为批评中并不总是反对任意定制，并且可能引起对这些政策的误会。依据反馈，CRITIQUE 最近公布了一项新性能，该性能容许更改作者要求所有审阅者签名。

6.2 满意度和工夫投入

为了理解已确定问题的重要性，咱们应用了考察的一部分来考察代码审查是否总体上被认为是有价值的。

咱们发现（表 2）在 Google 外部代码审查被普遍认为是有价值和无效的–所有受访者都批准代码审查很有价值的说法。咱们对 CRITIQUE 进行的外部满意度考察反映了这种观点：97%的开发人员对此感到称心。

在特定变动的背景下，情绪变动更大。最不称心的回答与很小的更改（1 个字或 2 行）或与实现某些其余指标所需的更改（例如，从源代码的更改触发过程）相干。然而，大多数受访者认为，他们所做的更改的反馈量是适当的。在这 3 个中，有 8 位受访者认为正文杯水车薪，并指出，所审查的更改是小的配置更改，对代码审核没有影响。只有 2 位受访者示意评论中有 bug。

表 2. 用户满意度调查结果

为了依据满意度对答案进行情境化，咱们还考察了开发人员破费在审阅代码上的工夫。为了精确量化审阅者所破费的工夫，咱们跟踪了开发人员与 CRITIQUE 的互动（例如，关上选项卡，查看了差别，评论，批准了更改），以及其余工具来估算开发人员每周破费多长时间来审核代码。咱们将开发人员交互的程序分组为肯定的时间段，将“审阅会话”视为与变更提交者以外的其余开发人员进行的，与同一未提交变更相干的交互程序，每次相隔不超过 10 分钟。从 2016 年 10 月开始的五周内，所有审核会话所花的总小时数，而后计算每周每位用户的平均值，过滤出咱们在过来五周内都没有数据的用户。咱们发现开发人员均匀破费 3.2（均匀每周 2.6 个小时）来审查更改。与 OSS 我的项目的 6.4 小时 / 周的自我报告工夫相比，这个数字很低[10]。

发现 5. 只管通过了多年的改良，但 Google 的代码审查仍面对审查中断。这些次要与评论四周产生的互动的复杂性无关。然而，开发人员强烈认为代码审查是一个有价值的过程，开发人员每周破费大概 3 个小时进行审查。

7. 探讨

咱们探讨了这项考察中呈现的主题，这些主题能够启发从业人员建设代码审查流程，并激发钻研人员在将来的考察中。

7.1 真正轻量级的过程

古代代码审查的诞生是它加重了繁琐的代码查看的累赘[4]；实际上，Rigby 和 Bird 在他们对整个零碎的考察中都证实了这一特色（CP1）。在 Google，代码审查已汇聚到一个更加轻量级的过程，开发人员发现该过程既有价值又能够很好地利用他们的工夫。

Google 的审查工夫中位数比其余我的项目要短得多。咱们假设这些差别是因为 Google 在代码审查方面的文化（严格的审查规范和对疾速审阅工夫的冀望）。此外，审稿人人数也有很大差别（其中一个在 Google 中，而其余两个在其余我的项目中）；咱们认为领有一名审阅者能够使审阅变得疾速而轻便。

审阅工夫短和审阅者人数少可能是因为代码审阅是开发人员工作流程中必不可少的一部分；它们也可能源于小的更改。OSS 我的项目的中位数变动范畴从 11 到 32 行变动，具体取决于我的项目。在公司中，此更改大小通常较大，有时高达 263 行。咱们发现 Google 的更改大小与 OSS 更靠近：大多数更改很小。变更的大小散布是代码审查过程品质的重要因素。先前的钻研发现，随着更改大小的减少，有用评论的数量会缩小，审阅提早会减少。大小也会影响开发人员对代码审查过程的了解；Mozilla 投稿人的考察发现，开发人员认为与大小相干的因素对审核提早的影响最大。Google 确认变更大小与评论品质之间的相关性，并强烈激励开发人员进行小的增量更改（大删除和主动重构除外）。这些发现和咱们的钻研反对审查小的更改的价值以及对钻研和工具的需要，以帮忙开发人员创立如此小的独立代码更改以进行审查。

7.2 实际中的软件工程钻研

Google 进行代码审查的局部做法与软件工程钻研中提出的做法保持一致。例如，微软公司对代码所有权的一项钻研发现，应认真审查较小贡献者所做的更改，以进步代码品质。咱们发现，此概念是在 Google 上通过要求所有者批准而强制施行的。同样，以前的钻研表明，通常有一个变更的审阅者将负责查看代码是否合乎惯例。可读性使此过程更加明确。在下文中，咱们将重点介绍使其成为“下一代代码审查工具”的 CRITIQUE 的性能。

审查者的倡议。钻研人员发现，对审稿代码具备先验常识的审稿人会提供更多有用的评论，因而工具能够为审稿人抉择提供反对。咱们曾经看到，审阅者举荐性能受工具反对，从而优先思考那些最近编辑 / 审阅受审文件的人员。这证实了最近的钻研，即频繁的审稿人对模块的倒退做出了微小的奉献，应与频繁的编辑者一并纳入。在 Google 中，实际上，找到适合的审稿人仿佛没有问题，实际上，施行举荐的模型很简略，因为它能够以编程形式辨认所有者。这与其余用于标识审阅者的提议的工具相同，审阅者曾经审阅了具备类似名称的文件或思考了诸如审阅中蕴含的评论数量之类的性能。Google 的工作重点是解决审稿人的工作量和临时缺勤（与 Microsoft 的钻研统一）。

动态剖析集成。对 88 位 Mozilla 开发人员进行的定性钻研发现，动态剖析集成是代码审查最罕用的性能。主动进行的剖析使审阅者能够专一于更改的可了解性和可维护性，而不会因为琐碎的评论（例如对于格局）而分心。咱们在 Google 的考察向咱们展现了在代码审阅工具中进行动态剖析集成的理论含意。CRITIQUE 为剖析作者集成了反馈渠道：审阅者能够抉择在剖析生成的评论上单击“请修复”，以示意作者应修复该问题，作者或审稿人都能够单击“无用”以标记对审阅过程无用的剖析后果。具备较高“无用”点击率的分析仪已固定或禁用。咱们发现，这种反馈循环对于维持开发人员对剖析后果的信赖至关重要。

合作审查之外的审查工具。最初，咱们找到了无力的证据，表明 CRITIQUE 的应用超出了审查代码。变更作者应用 CRITIQUE 来查看差别并浏览剖析工具的后果。在某些状况下，代码审查是变更开发过程的一部分：一个审查者可能会发送未实现的变更，以便决定如何实现施行。此外，开发人员还应用 CRITIQUE 来查看提交的更改的历史，只有这些更改被批准即可。这与 Sutherland 和 Venolia 构想的将代码审查数据用于开发的无益用法相一致。未来的工作能够考察代码审查工具的这些意外的和潜在的有影响的非审查应用。

7.3 常识流传

常识转移是 Rigby 和 Bird 提出的主题。为了掂量因为代码审查而导致的常识转移，他们从先验工作的角度登程，通过测量变更，审查和两个汇合的不同文件数来掂量专业知识，以更改的文件数为根据。他们发现开发人员通过代码审查理解更多文件。

在 Google，常识转移是代码审查教育动机的一部分。咱们试图通过查看评论和编辑 / 审阅的文件来量化此成果。随着开发人员积攒了在 Google 工作的教训，他们对其更改发表的评论均匀缩小了（图 2）。在过来一年内开始工作的 Google 开发人员，每次更改的正文通常多于两倍。先前的工作发现，作者认为来自审阅者的正文无用，而无用正文的数目则随着教训的减少而缩小。咱们假如评论的缩小是因为审阅者在应用代码库建设谱系关系时须要询问较少的问题的后果，并佐证了代码审阅的教育方面可能随着工夫的流逝而失去回报的假说。此外，咱们能够看到，由 Google 的工程师编辑和审查的文件，以及这两个汇合的联合，随着资格的减少而减少（图 3），并且看到的文件总数显著大于编辑的文件数。在公司工作（以 3 个月为增量），而后计算他们已编辑和审阅的文件数。在当前的工作中，更好地理解审阅文件如何影响开发人员的流畅性将是很有意思的。

图 2. 审查者的评论和开发者在 Google 的任职年限

图 3. 全职员工随工夫查看（编辑或审阅，或两者都有）的不同文件的数量。

8. 论断

咱们的钻研发现，代码审查是 Google 开发工作流程的重要方面。负责所有职务的开发人员都将其视为提供多种益处的环境，并且在此上下文中，开发人员能够互相学习代码库，保护团队代码库的完整性以及搭建，建设和倒退确保代码库可读性和一致性的标准。开发人员报告说，他们对审查代码的要求感到称心。大部分更改很小，只有一名审阅者，除了提交受权外没有其余评论。在一周中，有 70%的更改在邮寄进来进行初审后不到 24 小时内就会提交。这些特色使代码审查比其余采纳相似过程的我的项目更轻便。此外，咱们发现 Google 在其实际中蕴含了一些钻研思维，从而使以后钻研趋势的实际意义不言而喻。

原文地址：https://dl.acm.org/doi/10.114…