代码可读性：Google 工程卓越的奥秘

回顾我在 Google 六年的经历，我认为 Google 的代码可读性流程在科技领域中独树一帜。

作为可读性导师，我曾审核过 Google 大约十万行 Python 代码，这些代码的作者超过数百人。在这个过程中，我与 Google 的数千名同事共同指导了数百万 Google 员工完成可读性流程。这个流程的影响力之大已经改变了整个科技行业对“纯粹的 Python / Java / C++ / Go” 的理解。

我想探讨一下可读性的内涵，它对 Google 员工（包括我自己）的影响，其在 Google 内部的文化地位，以及在 Google 之外是否有必要推行这个流程。

Google 的代码可读性

在 Google，每次代码变更都需要得到代码库相关部分的维护者的批准。这是大多数公司的通行做法，无甚奇特。然而，独特之处在于，Google 要求每次变更还需得到一个“具备可读性资格”的人的审批。具备可读性意味着你深入理解了该语言，掌握了设计模式，了解语言生态以及 Google 的编程习惯，因此被视为能够发现任何语言使用中的问题的可靠人士。如果作者或任何审查者具备可读性，那么就达到了可读性要求。我估计大约有三分之一到一半的 Google 员工在他们的主要工作语言中具备可读性。

要取得可读性资格，你需要提交你编写的代码，然后会随机指派一名可读性导师来审核你的代码。我们建议你阅读并遵循相关的风格指南，以避免反复无果的修改。在使用该语言编写足够多的“优质”代码后，你就会获得可读性资格。

你可以在 SWE Book 中了解更多关于可读性的信息。

可读性对 Google 员工的影响

对于许多新入职的 Google 员工（Nooglers），可读性在代码提交机制中的核心地位可能会被看作是不必要的官僚作风。对于许多资深 Google 员工，可读性依然可能被视为无谓的官僚主义。虽然你可以选择不去取得可读性（这是完全允许的！），但是如果你的团队中具备可读性的人太少，那么当这些审查员休假时，团队的工作可能会因此而停滞。在踏上可读性之旅的 Google 员工中，有一部分人会遭遇那些骄傲于自己“手动代码审查”的能力，或者对某些语言特性怀有偏见的可读性审查员。这只是人们对 Google 的可读性持有负面看法的众多合理原因之一。

然而，每一个对可读性流程持负面态度的人，都有另一位从中受益的人。我有许多同事都在可读性之旅中收获良多，我希望我曾经审核过的数百次代码改动也有助于提升 Google 的代码库。相比于其他类似规模的公司，可读性对 Google 代码库的系统性影响也确保了代码质量的基本一致性。

我与代码可读性的故事

我的代码可读性的道路曲折复杂。

在早期阶段，我犯过一个错误：为了提升代码的可读性，我对一位实习生的研究代码进行了一些微调。结果，被分配来评审的人对整个文件进行了严厉的批评，而不仅仅是我做的修改。这次出乎意料的大反响，对我个人来说是一次不愉快的体验。根据我后来作为代码阅读指导者的经验，这次负面的评审可能让我在提升阅读代码能力上多退了很多步。坦白说，那次初期的评审完全浪费了我们双方的时间，如果你还把我不得不经历的额外无谓的代码阅读评审计算在内，可能为 Google 带来了 5000 美元的生产力损失。

后来，我成为一名代码阅读指导者，我经常在私人邮件列表上看到各种对语言特性的愤怒抱怨。我的项目——AutoGraph's AST 的特殊编译技术，被频繁地提及，我其实对此感到非常自豪（附注：我是团队中唯一一个极力将 AutoGraph 魔法的范围管理到最小可组合转换集合的人。我非常清楚特殊语言特性可能带来的使用问题！）。所以，我确实见识到了在代码阅读过程中可能出现的各种问题。

然而，尽管存在这些问题，我仍然相信，只要做得正确，提高代码可读性是有价值的，因此我决定成为一名指导者。最初，我每次审核的改进都花费了我超过一个小时的时间，几乎每分钟只能审查一行代码。在一个陌生的代码库中随机挑选一个改进来阅读是非常困难的，因为你并不熟悉其背景，你也可能对其工作流程一无所知。项目的主要维护者已经和作者一起将代码提高到了一个可接受的质量标准，然后你还需要尝试对评审做出有用的贡献就会很难。

作为代码可读性导师，我完全可以选择捷径，挑出代码质量检查工具遗漏的小错误。但是，对我来说，指导代码可读性意味着广泛解读工程的卓越之处。除了风格和测试之外，我还会评论代码架构，可维护性，库的使用，系统设计，构建或购买决策等等。由于我自己曾经经历过意外的范围扩大的评审，我知道我不应该要求作者重写整个代码库。我有一种每次评审都会用到的耐心储备，我尽力把它用在最合适的地方。

担任代码可读性导师几个月后，我发现我的代码审核速度比开始时快了 10 倍。我能在几分钟内理解改动的目的，了解相关代码库的可能原因，有时甚至可以了解到作者的职业背景。（例如，“看起来你有 Java 编程的背景。在 Python 中，这种访问者设计模式可以用自定义的树迭代器来更简洁地表达。”）至少在这一个具体的代码审查能力上，我已经成为一个可衡量的 10 倍工程师。

可读性文化的深远影响

可读性是 Google 文化中不可或缺的一环。在 Google 的早期，首位员工 Craig Silverstein 会对每个新员工的首次代码提交进行深入全面的审核，以确保最佳实践和统一的编码风格得以遵守。他和其他早期的 Google 工程师深刻理解到了可读性对于统一代码风格、提高工程师互换性、优化工具和系统、提升程序员生产力的重要作用。

如今，Google 拥有许多先进的技术和系统，比如可以让所有人使用同样的方式构建代码、可以让所有人共享同一个代码库、可以让所有人追踪和修复 bug 的工具、可以让所有人轻松部署和运行应用程序的平台等等。许多其他的辅助系统也发挥了它们的魔力，如能够管理跨百万行代码的重构差异，或者能检测并自动删除冗余代码。

Google 的核心技术理念是，全球一致性的好处远超过了地方性效率的损失。这种强调工程的文化可能会让许多注重产品导向、具有创业精神和好奇心的人才望而却步，这无疑是 Google 的一项损失。在研究部门，我曾见过一些对可读性持有反对态度的研究者，他们只有在需要使用 TPU 计算资源时，才会忍受 Google 的系统。然而，积极的一面是，Google 吸引了世界上最优秀的工程师，即使管理层在产品决策上犯下错误，它依然能够交付技术上的卓越成果。

如果你认同 Google 的核心理念，那么可读性便是实现全球一致性的重要手段和催化剂。它不仅能够帮助你扩展你的知识面和技能，还能够促进你与其他工程师之间的交流和合作。我至今还清晰地记得，有一次我被指派去审查一份非研究部门工程师写的一段复杂的、包含大量 AutoGraph 的 TensorFlow 2 代码的可读性。除我之外，全世界可能只有不到 10 个人能够恰当地审核这段代码，而这个任务恰好落到了我手中。我敢肯定，在可读性导师中，有许多其他领域的专家也将他们的专业知识广泛传播到了整个 Google。我能想到的唯一其他具有 Google 范围内融合作用的工具是代码搜索和由 大语言模型（LLM） 驱动的代码生成工具，但这些工具都没有可读性带来的人文关怀。

你的公司是否应该实施可读性标准？

Google 的可读性标准有以下三个准则：

• 对可读性的要求达成一致

• 为工程师提供指导，直到他们具备可读性的资格

• 通过程序化的方式强制执行每次变更都必须由具备可读性的人员编写或审查

前两个准则并不容易引起争议。许多公司都有自己的编码风格指南，许多公司也只使用一种编程语言，没有不同的文化差异。许多公司还有一个默认的期望，即高级工程师会审查初级工程师的代码，直到他们具备了足够的能力和经验，可以参与其他工程师的代码审查。

第三个准则是最难实施的，无论是从技术上还是从组织上。GitHub 有一个受保护分支的功能，但它没有办法添加像 “Python 可读性” 这样的概念，而且我不认为 GitHub 有任何动力去实施可读性。从组织上来说，程序化的强制执行是最容易引起怨言的，很容易想象到一个副总裁会忽视可读性，宣布他们即将推出的产品比遵守可读性更重要。

什么样的好处才能抵消在工程师的工作流程中增加一个步骤带来的怨言呢？打造一个安全的关键项目？或者，也许去复刻 Google 的工程文化?

我个人认同 Google 的 “全局一致性超过了局部效率”。苹果和亚马逊公司内部的不同地方工作会有非常不同的体验，这一点在 Google 看来是不好的。然而，这却意味着团队可以快速地行动，而不需要征求公司其他部门的意见。Google 感觉像是陷入了困境；Google 越大，就越难以摆脱使用单一产品和流程的惯性，而这些产品和流程并不能适应所有可能的用例。我看到一个常见的情况是这样：“我们从来没有发布或演示过我们的研究项目。因为要部署它们，我们必须经过一系列繁琐的审批流程，涉及隐私、监管、法律、公关等方面。而且我们还要花费几个月的时间来学习 TensorFlow 的服务体系。”最终，我倾向于认为，将公司划分成更小、更敏捷的部门，让每个部门根据自己的需求形成不同的子文化，可能会更有利于创新和效率。

所以，我的答案是否定的，公司不应该实施 Google 版本的可读性标准。这应该不足为奇；如果可读性真的有意义，那么在 Google 外面我们会看到更多 Xooglers 实施它。同时，Google 的文化已经有了太多的惯性；它应该保留可读性流程，并专注于那些最适合其以工程为中心的文化的产品和问题。

轻量级可读性方案

我在高中参加过一个暑期数学项目，它有一个短语：“证明或反驳，并尽可能修正”。在指出了 Google 版本的可读性存在的问题之后，我想通过提出一个更灵活和实用的方案来改进它，我称之为“轻量级可读性”，它包括：

• 对可读性的要求达成一致

• 为工程师提供指导，直到他们具备可读性的资格

• 一个非阻塞的机制，鼓励人们获得可读性

这个变体保留了指导计划，同时希望消除大部分的抱怨。它与非正式的指导不同，因为它为工程师创造了跨公司学习的机会，而且它为工程师能够并且应该努力掌握他们的技能创造了一个很好的途径。

对于（1），我建议可读性的要求应该包括以下几个方面：

• 对语言的内存模型的理解；

• 对语言解决典型任务（服务器/客户端、序列化/反序列化、正则表达式、元编程、数组、时间、输入/输出、日志、性能测量/调试/优化）的方案有所了解，即使不是非常熟练；

• 对依赖管理的细节有所理解；

• 良好的测试实践（包括如何设计易于测试的架构）；

• 以及对公司的技术选择如何适应公司的技术/产品需求有一定的理解。

并不是所有的“标准流程” 都适用于每个公司；你需要根据实际情况选择性执行！

对于（2），你需要找到一些有经验和技能的工程师，他们愿意帮助和教导其他工程师提高可读性。你也需要给他们一些奖励或者认可，让他们觉得这样做是有价值的。

对于（3），我认为最简单的解决方案是将可读性作为晋升为高级工程师的要求。

在实施轻量级可读性方面，最好在公司规模还不太大的时候开始。在公司拥有超过 100 名工程师之后，启动可读性规范就会变得很困难，假设你想要公司四分之一的工程师达到可读性标准（高级: 初级比例 为 1：3），如果公司每年以 20% 的速度增长（+25% 新雇员 -5% 流失率），那么每年大约有 6% 的公司工程师需要达到可读性标准。假设一个可读性导师每年可以指导 3-5 个左右的人获得可读性，那么大约所有工程师的 1-2% ，或者大约 5 -10% 的高级工程师需要成为可读性导师。

结论

无论是自己的代码接受别人评审还是评审别人的代码，我从 Google 的可读性流程中受益良多。我非常感谢 Google 在培养其工程人才方面下了那么大的投入。可能没有多少人想要实施 Google 的可读性流程，但我很想看到“轻量级可读性” 流程在世界各处“生根发芽”。如果你也在你的公司里尝试了这个方法，期待你将效果反馈给我。