第94期 | 谷歌如何做代码评审
池建强
讲述：池建强大小：7.17M时长：07:49
你好，这里是卖桃者说。今天和你聊聊代码评审。
谷歌有许多通用工程实践，涵盖所有语言和各类项目。这些文档代表了我们长期以来在开发过程中形成的各种最佳实践。开源项目或其他组织可能会从这些知识中受益，因此我们尽可能将其公之于众。
目前，仓库里只更新了《谷歌的代码评审指南（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 地址贴在了文稿内，强烈推荐你去仔细读一下，相信会有所收获。
好，今天的话题先聊到这儿。卖桃者说，明天见。
（编辑：成敏）
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《卖桃者说》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(10)
- 最新
- 精选
learn more分享一下我们的评审流程 1）被评审者先整体描述功能需要解决的问题 2）直接上代码，必须是条理有序的讲解流程，有必要可以调试 3）代码梳理过程中，评审者先记录问题，不要打断被评审者的思路 4）代码讲完，评审者提问环节，就是之前记录的问题一一提出 5）被评审者或者开发经理记录评审待改进的内容，有时并不是只针对被评审者，而是所有编码者 6）评审完成之后，落实待修改项，这时必须指派一个人监督和一个时间点来完成，否则很难实施 7）这次评审完成且落实好之后，那么又进入第一步接着下一轮的评审211
名贤集大佬，我有个小问题，你每天是念稿还是脱口而出。26
huhu小仙女啊！这篇我看不懂。 不过这句：“一个 CL 只要能提升整体代码的健康程度，评审者就应该批准它，即使这个 CL 并不完美。”做事有可评判的准则和依据，我喜欢这样的操作。2
aof我跟领导提code review，领导说耗时费力不讨好1
方勇(gopher)流程，制度，氛围，缺一不可，高质量的代码和统一风格是在一次次review中沉淀下来的，在系统架构组中，印象最深的不是设计评审而是 一次review到12点，各种头脑风暴，仔细推敲，比写代码还有意思，经典的代码review是一次享受！1
leslie其实就像老师所说：Code review这件事事实蛮难做的，目前中小企业普遍是用工具去审核且审核人基本是权威或者决策者；二叉树中陈皓老师所说的争论其实蛮少。 自己今年换到互联网行业：其实就是DB这块的研究员的角色，针对PM提出的需求提供解决方案、解决线上DB异常，至于是否执行了我不知道，只要邮件中提供测试环境下的解决方案且测试前后的效果就OK；DB这块本想做，最终发现其它人水平和自己差距太大-直接变成了我写规范并定期审核coding了。 Google等一线企业的方式根本推不下去：用最近热播的电影《哪咤。魔童转世》中的一句台词形容这种窘迫就是“井口之外一切皆错”；就像听到同行经常聊起，有了工具讨论啥；code review反而。。。这大概是大多IT同行感受到的现状1- leslieCode review这件事情确实国内推行蛮难的：自己这次跳回互联网在本地企业想做这件事情，发现完全做不下去；尤其像有了某些代码审核工具之后更加如此。 完全没有居安思危的感觉，套用最近电影院热播的《哪咤。魔童转世》中的一句台词“井口之外一切皆错”：企业不同高度不同、无力改变、只能前行。1
lucklyrsCL我觉得很有必要，对于代码质量的后期维护，团队之间的code交流和自我进步有很大的推进作用，甚至可以强制到团队研发每个人
小斧没有所谓“完美”的代码，只有更好的代码。评审者不应该要求每一个 CL 都是完美的，相反，评审者应该在 CL 的所谓“完美”与它所带来的变更重要性之间做出权衡。与其追求完美，评审者更应该追求“持续的改进”。只要一个 CL 能对整个系统的可维护性、可读性、易理解性起到改善作用，评审者就不能因为它不完美而推迟数天，甚至数周再批准。 当然，在某些情况下，这个原则也会有一些限制，比如某个 CL 添加了评审者不希望出现在系统中的特性，那么，即使这个 CL 的改动设计非常好，评审者依然可以拒绝它。
Q公司也准备做代码审查，在合并test分支时候审核，工作量会比较大，比如经常会测试提交bugfix。如果在合并master分支审核，代码已经测试如果不合格在改代码，上线风险很多。想请教老师是怎么做的呢？
收起评论