带你了解全球最大的软件公司的code review
原文链接：www.freecodecamp.org/news/how-co…
你是否想知道全球最大的软件公司之一是如何通过代码审查来保证代码质量的？
我也一样，这就是我和微软的同事一起研究在我们公司怎么进行代码审查的原因。它是一种常规的做法吗？每个开发人员都需要进行代码审查吗？他们使用什么工具呢？
这些问题在本文中会找到答案。
首先，我想先介绍一些关于微软的关键信息。微软有14万员工，其中大约44%（超过6万）是工程师。Office、Visual Studio和Windows等一些产品同时有上千人在共同的代码库上开发的。
我说这些是为了告诉你协调和管理软件开发的过程意味着什么。可以想象到的是，协调不同团队共同开发是一件非常重要的事。代码审查在这一过程中扮演着重要的角色。
在微软，代码审查是开发过程中不可或缺的一部分
微软的代码审查是一个被广泛采用的工程实践，成千上万的工程师认为这水一项伟大的实践，很多高绩效的团队都会在代码审查中花费大量的时间。
调查微软的代码审查
正是因为代码审查在开发过程中扮演着重要的角色，所以我们需要更深入的挖掘并真正理解这种做法的利弊。在微软代码审查的大规模研究中，我们采访、观察并调查了超过900位工程师，来了解他们在代码审查中的实践。
我们的目标是弄清楚代码审查究竟发挥着什么样的作用，工程师在做代码审查时面临着哪些挑战，并提炼出他们克服这些挑战的最佳实践。
我们能从微软的代码审查实践中学到什么？
大多数经验告诉我们，小团队和大团队一样有价值。如果你的团队还没有进行代码审查，我会以一种展示最佳实践的方式来提炼我们的发现。我还会解释代码审查的生命周期，以便你在开发过程中加入这样的实践。
如果你的团队已经在做代码审查了，你可以把你的实践经验与微软的代码审查实践进行对比。看你的代码审查生命周期是否有所不同，在后面的文章中，你会从代码实践的挑战中学习到有用的知识。通过阅读本文，你可以看看你的团队是否实现了我说的所有最佳实践，并克服了相应的挑战。
微软的工程师多久进行一次代码审查？
研究表明，36%的工程师说他们一天会进行多次代码审查，另外39%的工程师说他们每天最少进行一次代码审查，有12%的工程师会在一周进行多次，只有13%的工程师表示他们过去一周一次代码审查都没有做过。
这表示微软的工程师会花费较多的时间来进行代码审查，所以要保证这些时间花费的是值得的。但是，代码审查有哪些好处呢？
代码审查带来哪些好处呢？
代码审查最大的好处就是可以保证代码的质量，并且能够发现代码中的一些缺陷。另一个重要的好处就是知识传输。
知识传输意味着团队成员审核彼此的代码，以便熟悉代码库中的大部分代码，也是团队开发的最佳实践。另一个好处是，初级程序员和团队新人可以通过审查和被审查代码来快速提升他们的编程技巧。
工程师可以在代码审查期间讨论替代解决方案，这样做不仅可以改善代码库，也是所有相关人员学习的过程。
工程师一般怎么进行代码审查？
代码审查可以通过多种方式执行，有时是一名工程师走到另一名工程师的办公桌前一起看代码，有时是整个团队一起审查代码。但是在微软，最常见的情况是使用代码审查工具来完成代码审查。
微软的代码审查经常通过内部工具进行
代码审查工具有很多种，微软的团队可以自由选择。2016年，89%的工程师使用的是CodeFlow作为代码审查工具。后文我会对此进行进一步的解释。由于Git的兴起，工具库也随之改变，我会尽快增加更新后的数字。但我们要先来讨论常见的代码审查场景：
假设有一位名叫Rose的微软工程师，Rose刚刚完成了一个功能的一部分，现在想要得到同事的反馈。
Rose怎么在微软发起代码审查
Rose这时已经准备好接收反馈了，所以她首先要准备好自己接受审查的代码，然后打开代码审查工具，此时可以看到自己做了哪些修改。
认真检查这些修改之后，她需要向审查人员描述一下修改内容以及为什么修改。这个描述会帮助审查人员快速理解代码修改的目的，最后准备把代码发送给审查人员。
Rose怎么选择正确的审查人员？
大多数有经验的程序员都知道谁应该来进行代码审查。但对于团队新人或者是做了新的领域任务的工程师来说是有一些困惑的。如果Rose不知道她应该添加谁，她应该看一下团队规定或者问一下同事。她也可以使用代码审查工具的推荐功能来帮助她选择审查人员。
谁是相应的审查人员？
Rose选择了她认为合适的审查人员。他们通常是其他工程师，但也有可能是其他相关人员，例如开发工程师、设计人员或者是管理人员。选择一些审查人员是因为他们有专业知识，而有些审查人员被选择则是让他们了解即将发生的变化。
Rose请求同事给予反馈
选择好审查人员后，Rose会将代码审查发送出去。代码审查工具会自动通知审查人员，有时也会通知管理人员或者其他团队的项目管理者。
接收反馈是一个迭代过程
当Rose的同事有时间时，就会来进行代码审查。每一个审查人员都可以发表评论，评论完成后，审查人员便会把评论发送给Rose，Rose就可以根据审查人员的意见来完善代码了。
审查人员通常会关注的事情有：代码看起来有没有bug？架构是否有问题？是否存在一些细节问题，比如缺少注释或拼写错误。并不是所有的评论都很有价值，不过有几种最佳实践可以提升代码价值。
Rose准备好了一个新的优化后的版本
Rose会按照审查人员的建议修复bug并优化代码。如果Rose发现这其中有一些误解或其他有争议的问题，她会走向同事讨论这些问题。这种方法有时会比使用工具更加高效。
总之，当她处理完所有的反馈之后，她把最新的代码发送给审查人员。这种新的版本叫做revision。
如果需要，她会收到更多的反馈，这种循环会持续多次，这主要取决于修改的类型以及代码的质量。对于简单的修改，只需要一次就可以，而对于复杂的修改，往往要经过多轮的review。
所有的审查人员同意Rose合并代码
在审查结束后，审查人员会将代码标记为OK，Rose就可以将代码合并到代码库了。
有些团队会允许开发人员在审查结束前合入代码，但这只限于修改部分较小的代码，这有利于异步审查和快速开发。
我所描述的所有步骤都是微软典型的代码审查过程，但不同的团队也会根据情况制定更加宽松或严格的规则。
不是所有的团队都相同
可以想象的是，在微软的6万个工程师，上千个团队并不是完全相同的，有些团队会根据需要增加一些步骤或工具。而我只想向你介绍一些概要的步骤。
代码审查包括测试结果
代码审查中，我们最不想在查bug方面浪费时间，所以需要一套自动化测试流程。你要在提交审查之前保证代码执行结果符合预期。
这就是为什么有些团队需要在提交任何代码审查之前都跑一遍测试，这是为了防止某些工程师忘了测试，并保证每次提交的代码可用。
还有些团队会更进一步，在开发人员提交代码后触发一个构建。这个构建包括精确显示修改部分，并开始一系列自动测试。测试结果会反馈到代码审查中。这么做是为了保证公共代码库中代码的可用性。
代码审查包括用户接口
如果修改影响到接口，那么开发人员应该提交截图。这么做可以让审查人员直观的看到改变，其次可以与在自己机器上运行的结果进行比较。
代码审查包括静态分析
静态分析工具可以使审查人员不必浪费时间来检查代码风格是否符合规范。微软有些团队会使用自动话的审查机器人。审查机器人会自动标注代码风格问题，以节省人工审核时间。
微软代码审查工具
多年来，微软使用一款名叫CodeFlow的内部工具作为代码审查工具。这是一款复杂的代码审查工具，它可以引导开发人员发起审查，自动提醒审查人员，并包含丰富的评论和讨论功能。
CodeFlow的UI是比较重的，很像Word和PowerPoint。
CodeFlow的接口说明
如果不感兴趣的话可以跳过这部分，不过为了感兴趣的同学，我还是要介绍一下CodeFlow的各个接口。区域A展示的是所有有影响的文件。
区域B是已分配的审核人员列表以及审核状态（比如已签名或待处理）。C是文档展示区域，D是所有文档的评论列表。
F展示的是单条评论，这个评论和具体的代码相关联。最后，E区域是整个代码审查的结果，这里是complete。上方的数字表示之前的几个版本，这里有5个不同版本。
评论功能
评论功能是CodeFlow最棒的功能之一。审查人员可以选择代码中的一部分进行评论，代码的作者和其他审查人员就会收到通知，并且可以在这里开始讨论。
讨论功能
这个功能就像是在社交软件上交流一样（Twitter或Facebook），所以在CodeFlow上使用评论显得非常自然。另一个亮点是评论的状态，它可以是“won’t fix”, “resolved” 或“open”。
对照两个不同的版本
对比两个不同的版本是一个非常实用的功能。你可以清晰的看出作者在不同的版本之间做了哪些修改。这可以帮助审查人员轻松追踪修改过程。
代码审查分析工具
微软开发者会花费大量的时间在执行代码审查上，为了保证这时间花费的是值得的，微软有自己的代码审查分析平台。
这个平台会存储所有的代码审查数据。包括代码审查的开发者，所有的评论，甚至是每一个修改版本的代码。
这些数据是代码审查研究的基础，它也会被一些产品团队用来检验自己团队的实践结果。我在这个系列文章中的一些研究和分析也都来自于这些数据。
微软代码审查的未来
随着微软收购了Github，改变是不可避免的。例如，微软内部已经开始广泛采用Git作为代码版本控制工具了。这也意味着未来代码审查可能采用PR的形式。
