第94期 | 谷歌如何做代码评审
你好，这里是卖桃者说。今天和你聊聊代码评审。
前两天，谷歌在GitHub上开源了他们的《谷歌工程实践文档（Google Engineering Practices Documentation）》，文档的开头是这么写的：
谷歌有许多通用工程实践，涵盖所有语言和各类项目。这些文档代表了我们长期以来在开发过程中形成的各种最佳实践。开源项目或其他组织可能会从这些知识中受益，因此我们尽可能将其公之于众。
目前，仓库里只更新了《谷歌的代码评审指南（Google’s Code Review Guidelines）》，未来肯定不止于此，按照谷歌的规划，会陆续更新其他方面的最佳实践。
今天我就和你聊聊这份代码评审指南。
之前我就讲过，代码评审是一个非常好的流程和措施，可以说，保证谷歌的代码质量如此之好的关键原因就是代码审查，之前朱赟博士的专栏里也讲过 Airbnb 的代码评审流程。不过呢，代码评审在国内一直算个痛点，大家明知道做好代码评审会有很多好处，就是用不好。要么是制度问题，要么是流程问题，要么是观念问题，据我了解，国内代码评审做得又好又有效的，不算多数。
我仔细阅读了这份代码评审指南，可以说这是一份非常完善并且能够指导实战的操作性指南了，很有价值。这份文档，对于想做代码评审的团队来说，是一个很好的参考，很多地方都可以直接借鉴过来用。当然，公司体量和情况不同，对代码评审的需求也不同，在实践中运用的时候，还需要你根据自己公司的实际情况进行调整。
整个代码评审指南分为两个部分，一个针对代码评审者，一个针对 CL 提交者。这里解释一下，CL 是谷歌的内部术语，是"Change List"的简称，意思是已经提交到版本控制或正在进行代码检查的一个独立更改，其实跟我们通常所说的“patch”是一个意思。
在文档中，针对代码评审者的部分，包含了很多关于如何做好代码评审的具体建议，具体分为六个章节，分别是：
- 代码评审标准
- 代码评审时该查看什么
- 评审中如何查看一个 CL（Navigating a CL in Review）
- 代码评审的速度
- 如何写审核评论
- 如何处理审核后程序员拒绝修改的情况
针对代码提交者的部分，则包含了很多如何快速通过代码评审的建议，具体分为3个章节，分别是：
- 写一个好的CL描述
- 提交小一点的CL，意思就是不要改到翻天覆地了才提交代码评审
- 如何处理代码评审者的评论
我们可以看到，这份文档涵盖了代码评审双方的最佳实践，非常全面，几乎是开箱即用。以“代码评审时该查看什么”为例，谷歌在文档中列出了他们的评审要点，主要以下几个方面：
- 设计：代码是否经过精心设计并适合你的系统？
- 功能：代码是否符合开发者意图？代码对用户是否友好？
- 复杂性：代码是否可以更简洁？未来其他开发人员接手时，代码是否易于理解与易用？
- 测试：代码是否经过正确且设计良好的自动化测试？
- 命名：开发人员是否为变量、类、方法等选择了明确的名称？
- 注释：注释是否清晰有效？
- 风格：代码是否遵循了谷歌的代码风格？
- 文档：开发人员是否也同步更新了相关文档？
在指南中，上面的每一个小点，谷歌都进行了详细阐述，并给出了具体的实践建议，借鉴价值非常高。
另外，谷歌还在指南中分享了他们对于代码评审的基本原则。在谷歌看来，代码评审的目的是确保谷歌代码库整体的健康程度能随着时间的推移而不断改善，这个过程中用到的所有工具和流程都需要为此服务。因此，在实践中势必要做出一连串的权衡与取舍。
举个例子，一般来说，一个 CL 只要能提升整体代码的健康程度，评审者就应该批准它，即使这个 CL 并不完美。谷歌强调，这一点是所有评审原则中的最高级原则。
毕竟没有所谓“完美”的代码，只有更好的代码。评审者不应该要求每一个 CL 都是完美的，相反，评审者应该在 CL 的所谓“完美”与它所带来的变更重要性之间做出权衡。与其追求完美，评审者更应该追求“持续的改进”。只要一个 CL 能对整个系统的可维护性、可读性、易理解性起到改善作用，评审者就不能因为它不完美而推迟数天，甚至数周再批准。
当然，在某些情况下，这个原则也会有一些限制，比如某个 CL 添加了评审者不希望出现在系统中的特性，那么，即使这个 CL 的改动设计非常好，评审者依然可以拒绝它。
除了这个最高级原则，谷歌的评审原则还包括以下4点：
- 技术事实和数据要优先于个人偏好和意见。
- 在代码风格方面，《谷歌的代码风格指南》是最权威的参考资料。任何不在风格指南中的代码习惯，都属于个人偏好问题。一般来说，CL 的风格要和现有的代码保持一致。但如果原来并没有规定这样的代码风格，就接受 CL 作者的风格。
- 软件设计方面从来不是纯粹的风格问题，或者纯粹个人的偏好问题。很多所谓的风格都是建立在一些基本准测之上的，它们并不是简单地由个人偏好决定的。有时，如果有几个不同的可行方案，只要 CL 作者能够通过数据或基本工程原则证明几种方案同样有效，那么评审者应该接受作者的风格。否则，设计方案的选择还是应该根据软件设计的标准原则来进行。
- 如果没有其它适用规则，那么评审者可以要求作者的偏好与当前代码库保持一致，只有这样不会对整体的代码健康水平产生影响。
截至9月11日20点，《谷歌工程实践文档》在GitHub上的 Star 数已经达到6086，可见其受欢迎程度。我把这份文档的 GitHub 地址贴在了文稿内，强烈推荐你去仔细读一下，相信会有所收获。
好，今天的话题先聊到这儿。卖桃者说，明天见。
（编辑：成敏）