作者 | Dr. Michaela Greiler
翻译 | 漫慢忙
本文翻译自 Dr. Michaela Greiler 的 How Code Reviews work at Microsoft,作者所在的团队调研了微软是如何做代码审查的,并做了相关的总结。原文附有大量链接资源,在此没有整理出来,相关链接可以查看原文获取
您是否曾经想过全球最大的软件公司之一是如何通过代码审查来确保高质量代码?
我也是。因此,我与同事一起调查了 Microsoft 是如何进行代码审查的。他们的做法是常见的做法吗?开发人员是否需要进行代码审查?他们使用哪些工具?让我们在这篇文章中找到答案。
首先,让我为您提供一些有关 Microsoft 的关键信息。微软大约有 140,000 名员工。其中约有 44%,即超过 60,000 名员工是工程师。成千上万的工程师同时使用相同的代码库来开发 Office,Visual Studio 或 Windows 等几种产品。
可以想象,确保不同子团队开发的代码可以完美地协同工作是一项艰巨的任务。在 Microsoft 中,代码审查起着重要作用,确保可以在如此大规模的范围内实现顺畅的协作。
在 Microsoft,代码审查是一种被广泛采用的工程实践。绝大多数工程师认为这是一个很好的最佳实践。而且大多数高效能团队都花了大量时间进行代码审查。
因为代码审查在 Microsoft 开发过程中起着如此重要的作用,所以它是我们深入研究并真正了解这种做法利弊的理想目标。在 Microsoft 进行的有关代码审查的大规模研究中,我们采访、观察和调查了 900 多名开发人员的代码审查实践。
我们的目的是了解 Microsoft 如何进行精确的代码审查。我们想知道,开发人员在进行代码审查时会遇到哪些代码审查陷阱,以及他们为克服这些挑战而开发的代码审查最佳实践。
大多数经验教训都是非常有价值的,不管对于小型团队和组织,还是对于大型团队和组织。如果你的团队还没有进行代码审查,那么我们会向您展示我们的发现以及代码审查的好处。我还将解释代码审查生命周期,以便您可以将这种实践纳入自己的开发过程中。
如果你的团队已经施行了代码审查,则可以将您的实践与 Microsoft 的代码审查实践进行比较。您的代码审查生命周期看起来是否有所不同?在下一篇文章中,我们将介绍代码审查陷阱和代码审查最佳实践。有了这些信息,您就可以开始查看您的团队是否已经实施了我介绍的所有最佳实践并克服了挑战。现在让我们开始吧。
在这项研究中,有 36% 的开发人员表示他们一天执行多次代码审查。另有 39% 的开发人员表示,他们每天至少进行一次代码审查。12% 的人每周进行多次代码审查,只有 13% 的人说他们在过去一周未进行代码审查。
这意味着 Microsoft 的开发人员将大量时间花费在代码审查上。因此,重要的是要确保这段时间是值得花费。那么,代码审查有哪些好处?
开发人员提到,代码审查最大的好处是提高代码质量并发现代码中的缺陷。代码审查的另一个重要好处是知识转移。
知识转移意味着互相检查代码的团队成员会熟悉大部分代码库。这也意味着代码审查最佳实践是在团队内部不断发展形成的。另一个优势是,新团队成员和初级开发人员可以在查看或获得反馈的同时学习和提高他们的编码技能。
如果开发人员在代码审查期间讨论替代解决方案,则不仅会改善代码库,而且对所有相关人员都有学习作用。因此,学习、指导和自我完善是 Microsoft 将代码审查视为有益实践的原因。
代码审查可以通过多种方式执行。可以是一个开发人员走到另一个开发人员的办公桌前一起看一些代码,也可以是团队一起检查代码。但是,在 Microsoft 进行代码审查时,最有可能遇到的情况是代码审查是借助工具完成的。
有各种各样的代码审查工具可用,并且在 Microsoft,团队可以自由选择他们的工具。在 2016 年,89% 的开发人员表示是使用 CodeFlow 代码审查工具。稍后,我将解释有关此代码检查工具的更多信息。从那时起,随着 Git 的崛起,工具的使用也发生了变化。让我们考虑一个典型的审查情况:
让我们想象一下 Microsoft 的一名开发人员,让我们暂且称她为 Rose。Rose 刚刚完成了功能的一部分,现在希望获得同事的反馈。
好了,Rose 准备获得一些反馈。因此,她首先准备好代码以进行审查。此步骤包括她打开代码检查工具,预览代码的更改。代码审查工具执行一些对比任务,这些任务可以帮助 Rose 准确查看她所做的更改。
在仔细检查了这些更改之后,她准备了一些说明,告诉审阅者她做了什么以及为什么这么做。这个说明可帮助审阅者了解代码更改的目的及其动机。现在,可以将代码发送给审阅者了。
许多经验丰富的开发人员都知道谁应该参加代码审查。但是,对于团队中的新成员或新的工作领域,选择起来可能会比较棘手。如果 Rose 不知道自己应该添加谁,她可以查看团队的相关政策或询问同事。她还可以使用代码审查工具的推荐功能,该功能可帮助她来选择审阅者。
Rose 选择了她认为可以为这段代码贡献知识的审阅者。审阅者通常是其他开发人员,但也可以包括其他利益相关者,例如 dev-ops 工程师,UI 或管理人员。审阅者被选择可能是因为他们的专业知识,也可能是他们需要随时了解即将到来的变更。
一旦选好了审阅者,Rose 就会发送代码审查请求。代码审查工具会自动发送通知,以通知审阅者已创建了新的代码审查。通知将发送给所有审阅者。但是,通常团队的经理或产品经理也会添加到通知列表中,并为每次审阅自动通知他们。这些通知使他们能够了解到相关信息,不过他们不需要执行审核。
一旦 Rose 的同事有时间,他们将查看代码审查。每个审阅者都可以在代码中添加注释和评论。完成评审后,审阅者会将带注释的代码发送回 Rose。Rose 现在可以处理这些评论,并准备代码的新版本。
审阅者通常会查看一些信息:代码看起来是否有错误吗?有架构上的问题吗?是否有一些小问题,例如缺少说明、拼写错误等?并非所有评论都同样有价值。但是,有几种最佳实践可提高代码审查注释的价值。
Rose 通过修正和解决建议来处理反馈。如果 Rose 发现存在一些误解或其他有争议的问题,她可能会去找同事亲自讨论。这有时比通过工具更容易,更个性化。
无论如何,一旦她处理完所有反馈,就将代码的新版本发送给审阅者。该新的改进版本称为修订版。
如果需要,她将收到进一步的反馈。这种迭代是否持续几次取决于更改的类型及其质量。对于简单和小的代码更改,通常只需要一个代码审阅修订。对于其他更复杂的更改或有问题的代码中的更改,可能需要几次迭代。
这是完全正常的,一部分原因是这个代码审阅反馈周期能激发作者与代码审阅者之间的讨论。
在此审查周期之后,审查者将代码标记为 OK,然后 Rose 可以将代码签入通用代码库。
有些团队制定了一些政策,允许开发人员在实际审查完成之前签入代码。这通常是针对一些微小的变化,以允许异步审查和加快开发速度。
我描述的所有步骤都是 Microsoft 典型代码审查生命周期的一部分,并由所有团队执行。根据团队的政策,团队对每个步骤的要求都会更加严格。
可以想象,微软有 60,000 名工程师和非常多的团队,并非都按统一标准来操作。Microsoft 的某些团队可能在代码检查生命周期中需要其他步骤或工具。我想简要介绍一下一些团队添加到代码审查过程中的一些额外步骤。
您最想要的功能可能是通过“自动检测”的错误代码来节省时间。我的意思是,如果您可以运行自动化测试并意识到代码无法按预期工作,那么这就是您应该做的:在审查之前运行测试。
这就是为什么有些团队要求在每次代码审查时都提交测试结果的原因。这样就不会有人会忘记运行单元测试了。而且它可以确保在给定的代码更改下测试实际上已经运行并通过。
其他团队甚至更进一步,以某种方式配置了代码审查工具:开发人员提交的每个代码审查都会触发构建。该版本包含该确切的更改,并且还启动了一系列自动化测试。这个构建和这些测试的结果将附加到代码审查中。通过这种方式进行配置,可以确保已使用公共代码库中的最新代码对代码更改进行了测试。
如果更改影响到用户界面,则要求开发人员提交屏幕截图也是一个好主意。这样,代码审阅者可以在不运行代码的情况下看到代码更改的影响。其次,在自己的计算机上运行代码时,代码审阅者可以发现差异。
静态分析工具就代码样式问题而言,可以为代码审阅者节省大量时间。Microsoft 的某些团队将自动化的静态和动态分析工具用作专用的机器人审阅者。这些机器人在代码样式和其他静态问题上给出评论。因此,可以腾出时间让人工代码审阅者执行更多有趣的任务。
多年来,Microsoft 进行代码审查的事实上的标准之一是内部工具 CodeFlow。这是一个复杂的代码审查工具,可支持开发人员并指导他们完成代码审查的所有步骤。CodeFlow 在代码准备过程中提供帮助,自动通知审阅者,并具有丰富的评论和讨论功能。
您可以在下面的屏幕截图中看到,CodeFlow 是一个重 UI 工具,非常类似于 Word 或 PowerPoint。
如果需要,可以跳过此步骤,如果感兴趣,我将带您浏览 CodeFlow 的界面。查看屏幕截图,在左侧 (A),您会看到所有受影响的文档。
同样在左侧,您会看到 (B) 分配给该本次审查的审阅者列表及其状态(例如,已签署或待审核)。活动文档显示在编辑器 (C) 中。在底部,您可以看到 (D) 所有文档的注释列表。
另一方面,在活动文档 (F) 中只有一个注释。此注释与代码的具体部分(即一行中的一个单词)相关。最后,在顶部,您将看到代码审查的总体状态,在截图中是完成状态。之前的数字表示不同的修订版本。在此审查中,有五个修订。
CodeFlow 最好的功能之一就是它的注释功能。
代码审阅者可以非常精确地选择她要评论的代码部分。例如,审阅者甚至可以仅突出显示一行中的一个或两个字符,而不是突出显示整行。然后,审阅者可以对该选择附加评论。
该评论会发送给代码作者或其他审阅者,并且可以围绕该评论发起对话。
这种评论功能感觉就像在诸如 Twitter 或 Facebook 之类的社交媒体平台上评论。因此,CodeFlow 中的评论体验非常自然,可以进行丰富的对话和讨论。另一个不错的好处是可以为每个注释线程分配状态。状态可以是“无法解决”,“已解决”或“未解决”。
一个有用的功能是可以选择两个不同的代码审查版本,并比较两者之间的差异。这意味着您可以准确地看到代码作者在一个代码审查修订版和另一个代码审查修订版之间进行了哪些更改。跟踪审核进度非常方便。
在 Microsoft,开发人员花费大量时间进行代码审查。为确保这些时间花得有价值,Microsoft 拥有自己的代码审查分析平台。
该平台存储所有代码检查数据,从正在检查的代码开始,到代码检查中涉及的开发人员,再到开发人员的所有注释。甚至可以追溯到每个修订的代码更改。
这些代码审查数据是 Microsoft 对代码审查进行一些实证研究的基础。许多产品团队还使用它来跟踪他们的生产率并了解他们自己的代码审查实践。另外,我在此博客文章系列中分享的许多关于 Microsoft 代码审查的见解都来自对该代码审查数据的研究和分析。
随着 Micorsoft 参与和收购 GitHub,一些变化是不可避免的。例如,Microsoft 已经广泛采用 Git 作为源代码版本管理工具。同时,在 Microsoft,以 pull requests 形式进行的代码审查正在增加。