微软是如何确保代码质量的呢？

全球最大的软件公司之一微软拥有约140,000名员工，其中大约44％，即超过60,000名员工，是工程师。

Office、Visual Studio或Windows等几种产品，都是由数千名同时在同一代码库上工作的工程师开发的。确保由不同子团队开发的代码完美地协同工作是一件非常重要的任务。

那么你想过么，如此大的工程师规模下，微软是如何确保代码质量的呢？

微软的法宝在于：完整的代码评审机制！

微软代码评审是一种被广泛采用的工程实践。成千上万的工程师认为这是一个伟大的最佳实践。大多数高绩效团队花费大量时间进行代码评审。

那么，微软的代码评审究竟是一种怎样的机制呢？今天，文摘菌就带你来一探究竟。

调研微软的代码评审

在微软代码评审的大规模研究中，我们采访、观察并调查了900多名开发人员。

我们的目的是了解如何在微软完成代码评审。我们想知道，在进行代码评审的时候，开发人员面临哪些陷阱，以及他们为克服这些挑战而开发的最佳实践。

您可以从微软的代码评审实践中学到什么？

大多数经验教训对于小型或大型团队组织都很有价值。如果您的团队尚未进行代码评审，我会向您展示该实践的好处。如果您的团队已经有了代码评审机制，您可以将您的实践与微软的代码评审实践进行比较。

微软工程师多久进行一次代码审查？

在这项研究中，36％的开发人员表示他们每天进行多次代码评审。另有39％的开发人员表示，他们每天至少进行一次代码评审。 12％的人每周多次进行代码评审，只有13％的人表示过去一周他们没有进行代码评审。

这意味着，微软的开发人员将大量时间花在代码评审上。因此，确保有效使用这段时间非常重要。

代码评审提供哪些好处？

代码评审的好处

代码评审最重要的好处是，提高代码质量并找到代码中的缺陷，另一个重要好处是知识转移。

知识转移意味着，审核彼此代码的团队成员熟悉代码库的大部分内容。但是，这也意味着代码评审最好在团队内部实施。另一个优点是，新的团队成员和初级开发人员可以在审阅或获得反馈的同时学习和提高他们的编码技能。

如果开发人员在代码评审期间讨论替代解决方案，它不仅可以改善代码库，还可以为所有相关人员提供学习机会。因此，学习、指导和自我改进是代码评审之所以被认为是微软的一种有益实践的主要原因。

开发人员通常如何进行代码评审？

代码审查可以通过多种方式执行。有时，可以很不正式， 比如一位开发人员走到另一位开发人员的桌边一起看一些代码。其他时候，团队一起审核代码。但是，您在微软的代码审查中遇到的最可能的情况是，代码评审是在借助工具的帮助下完成的。

代码评审的工具有很多种。在微软，团队可以自由选择他们的工具。 至2016年，89％的开发人员表示使用CodeFlow代码评审工具。稍后我将解释更多有关此代码评审工具的信息。从那时起，随着Git的兴起，工具领域发生了变化。

现在，让我们考虑一个典型的代码评审案例： 微软的开发人员Rose刚刚完成了一个功能，现在想要得到她同行的反馈。

Rose如何在微软开始代码审查？

Rose首先要为代码评审做准备。这一步包括打开代码评审工具，允许她预览代码更改。代码评审工具可以执行差异化对比任务，帮助罗斯确切了解她做了哪些更改。

在仔细审查了这些变化之后，她标记了一些备注，告诉评审人她做了什么以及为什么这样做。备注说明有助于审阅者了解代码更改的目的和动机。至此，代码已准备好可以发送给审阅者了。

Rose如何选择合适的代码审阅者？

许多经验丰富的开发人员都知道应该选谁作为代码审阅者。然而，对于团队中的新人或新的工作领域，选择可能会更棘手。如果Rose不知道她应该添加谁，她会查看团队规定或询问她的同事。她还可以使用代码评审工具的推荐功能，该工具可以根据代码库的经验和知识帮助选择审阅者。

谁是相关审阅者？

Rose选择她认为可以为这段代码贡献知识的审阅者。审阅者通常是其他开发人员，但也可以包括其他利益相关者，例如开发人员工程师，UI专家或经理。一些评审员被选是基于他们的专业知识，其他评审员被选是为了让他们能随了解即将发生的变化。

代码评审的一般步骤

Rose要求她的同行反馈

一旦选中每个人，Rose就会发出代码评审。代码评审工具会自动发送创建评审的通知到每个人。通知对象不仅包括所有审阅者，也会包括其他人员，例如相关团队的经理或产品经理。这些通知允许他们的信息保持同步，即使他们不需要执行评审。

接受反馈是个迭代过程

Rose的同事们有时间就会审查代码。每个审查者都能评注代码，完事后把代码发回Rose，Rose可以据此修改代码。

审查者通常关注的点包括：代码有bug吗？代码结构有问题吗？代码有拼写错误、少个冒号之类的小毛病吗？不是所有的评注都重要，但是有几个小技巧可用来提升代码评注。

Rose准备新版本的代码

Rose根据评注修改代码。如果有的地方弄错了或有争议，Rose可能直接去跟审查者面谈，或者通过审查工具交流会更私人化一点。

不管怎样，一旦Rose根据反馈完成了代码修改，她可以发一份新版本的代码给审查者，这份代码叫修订版。

若有必要，她还会收到反馈。这个循环视情况而定会持续好几轮，一般的小代码审查一次即可，复杂的代码可能得审查多轮。

这样的工作是很常见的，还可能在作者和审查者之间擦出思维的火花。

所有的审查者都批准，Rose登记代码

完事之后，审查者标记代码为okay，Rose终于可以把代码补充到公共代码库了。有些团队会允许开发者在审查结束前就把代码上传到代码库。这种情况通常在代码只需小修小改的时候发生，这样可以异步审查并加速开发。

上面我说的所有步骤都是Microsoft代码审查周期的常规操作，被所有团队执行，根据团队不同而略有出入。

并非所有团队都一样

如你所想，事情并非一成不变。Microsoft的一些团队会有些额外步骤或工具助力代码审查。我会简单介绍这些额外步骤。

包含测试结果的代码审查

可能你最不想做的事情就是，审查那些代码审查软件就可以审查的代码。所以你应该在审查之前先跑一遍测试。

一些团队要求做代码审查的时候把测试结果也一起上传。这样可以保证人人都测试一下。

其它团队可能更加严格，每个审查者审查的时候都会触发编译，编译和测试的结果都会被放在审查报告上。

涉及用户交互界面的代码审查

如果开发者把用户交互界面也改了，那TA最好截个屏给别人看下。这样审查者就省的跑代码了，直接看图片就行，审查者也可以方便检查因运行环境不同而产生的差异。

包含静态分析的代码审查

静态分析对规范代码样式来说尤其有效。微软的一些团队使用自动化的静态和动态分析工具作为专用的机器人评审员。这些机器人评论代码样式和其他静态问题。这样就能腾出时间让人工代码审阅者执行更有趣的任务。

微软的代码审查工具

多年来，微软实际上的代码评审标准之一是一个名为codeflow的内部工具。这是一个复杂的代码评审工具，它支持开发人员并指导他们完成代码评审的所有步骤。

Codeflow帮助编写代码，自动通知审阅者，并具有丰富的注释和讨论功能。

codeflow是一个相当依赖UI的工具，很像Word或PowerPoint，如下面的截图所示。

CodeFlow界面说明

看屏幕截图，在左边(A)你可以看到所有受影响的文件。

同样在左边，您可以看到(B)分配给评审的审核员名单以及他们的状态(例如，已签署或待决)。活动文档显示在编辑器(C)中。在底部，您可以看到(D)所有文档的注释列表。

另一方面，在活动文档(F)中只有一个注释。此注释连接到代码的具体部分(即一行中的一个单词)。最后，在顶部，您可以看到代码评审的总体状态。在这种情况下，已经完成。之前的数字表明了不同的修正。在这次审查中，进行了五次修订。

评注功能

Codeflow最优秀的特性之一是它的评论功能。代码审阅者可以非常精确地选择她想要评论的代码的部分。例如，审阅者甚至可以在一行中高亮显示一个或两个字符，而不是突出显示整个行。然后，审阅者可以将评论附加到该选择。

将此注释通知代码作者或其他审阅者，并可以围绕此注释以线程的形式启动会话。

讨论功能

这种评论功能就像在Twitter或Facebook等社交媒体平台上发表评论。因此，Codeflow的评论体验非常自然，人们可以进行丰富的对话和讨论。另一个不错的好处是可以为这些评论线程中的每一个指定一个状态。例如，状态可以是“不会修复”、“已解决”或“打开”。

代码评审修订的比较

你也可以选择代码评审的两个不同版本，并比较两者之间的差异。这意味着您可以准确地看到代码评审作者在一个代码评审修订版和另一个代码评审修订版之间执行了哪些更改。这方便了跟踪审查的进展。

代码评审分析工具

开发人员花费大量时间在Microsoft执行代码评审。为了确保这段时间得到充分利用，Microsoft拥有自己的代码评审分析平台。

该平台存储从代码评审开始的所有代码评审数据，参与代码评审的开发人员，以及开发人员的所有评论。甚至可以追溯每次修订的代码更改。

这些代码评审数据是Microsoft对代码评审进行多项实证研究的基础。许多产品团队也使用它来理解他们自己的代码评审实践。

微软代码评审的未来

随着Micorosft的参与和对GitHub的收购，改变是不可避免的。例如，在Microsoft中广泛采用git作为源代码管理工具，就可以看出这种变化。但是，这也意味着在微软，以”pull request”的形式进行的代码评审正在上升。