本文由知乎网友漫慢忙翻译自 Dr. Michaela Greiler 的 How Code Reviews work at Microsoft,做者所在的团队调研了微软是如何作代码审查的,并作了相关的总结。原文附有大量连接资源,在此没有整理出来,相关连接能够查看原文获取架构
您是否曾经想过全球最大的软件公司之一是如何经过代码审查来确保高质量代码?并发
我也是。所以,我与同事一块儿调查了 Microsoft 是如何进行代码审查的。他们的作法是常见的作法吗?开发人员是否须要进行代码审查?他们使用哪些工具?让咱们在这篇文章中找到答案。cors
首先,让我为您提供一些有关 Microsoft 的关键信息。微软大约有 140,000 名员工。其中约有 44%,即超过 60,000 名员工是工程师。成千上万的工程师同时使用相同的代码库来开发 Office,Visual Studio 或 Windows 等几种产品。异步
能够想象,确保不一样子团队开发的代码能够完美地协同工做是一项艰巨的任务。在 Microsoft 中,代码审查起着重要做用,确保能够在如此大规模的范围内实现顺畅的协做。编辑器
在 Microsoft,代码审查是一种被普遍采用的工程实践。绝大多数工程师认为这是一个很好的最佳实践。并且大多数高效能团队都花了大量时间进行代码审查。工具
由于代码审查在 Microsoft 开发过程当中起着如此重要的做用,因此它是咱们深刻研究并真正了解这种作法利弊的理想目标。在 Microsoft 进行的有关代码审查的大规模研究中,咱们采访、观察和调查了 900 多名开发人员的代码审查实践。post
咱们的目的是了解 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 形式进行的代码审查正在增长。