谷歌前员工的软件开发工具指南
作者|刘碧阳
翻译|盖雷
策划|蔡芳芳
Google的内部开发工具是世界领先的，为大规模软件开发的各种痛点提供解决方案。但是几乎所有的工具都与谷歌独特的内部生态系统紧密耦合，不能用于其他环境。本文介绍了如何在软件开发中引入良好的开发工具，提高自身和团队成员的生产力，进而在大规模软件开发中传播有效的最佳实践，给公司带来工程效率。
很多年前我在谷歌工作过一段时间。虽然从那以后事情发生了变化，但是接触Google内部开发工具的经历对我产生了长远的影响。在很多方面，谷歌的内部开发工具是世界上最先进的。Google不仅在自己软件系统的扩展上走在前列，在大型软件的高效构建方法上也是如此。Google为代码库规模、代码可发现性、组织知识共享、多服务部署等问题提供了解决方案，已经达到了大多数企业尚未达到的高度。《谷歌软件工程》(“谷歌的软件工程”)推荐参考。
但另一方面，谷歌的内部工具非常有限。事实上，几乎所有这样的工具都与谷歌独特的内部生态系统密切相关。这意味着人们一旦离开工作岗位，就很不幸地无法在其他环境中使用这些工具。
尽管如此，这些才华横溢的谷歌员工还是从世界领先的技术组织中吸取了经验教训，然后为许多其他组织注入了新的动力。但是要适应Google之外的编程环境并不容易，尤其是因为他们已经形成依赖的一些工具无法使用。
这些年来，我从自己和很多其他离开谷歌的人身上学到了很多。Sourcegraph的很多早期客户是因为离开谷歌后错过了原公司的代码搜索功能才找到我们的。通过与客户的密切合作，了解他们迫切需要填补的空白，进而构建Sourcegraph的功能来满足他们的需求。谷歌前员工正在探索如何在当前组织中使用新的开发工具。这项工作的灵感来源于他们使用Google开发工具的经验。当然，有些探索是成功的，有些是失败的。
关于这一点，我觉得写一本实用实用的外部开发工具指南是很有意义的。能将谷歌的内部开发工具生态系统直接克隆到新公司中，无疑是不少谷歌前员工的愿望，不应目标过高。接下来，我将谈谈我的看法，以及前谷歌员工是如何开始寻找工具，让他们和他们的新团队尽可能高效地工作的。
一个
软件开发的生命周期
对于刚离开谷歌加入其他公司的人来说，可能很难适应不如以前的工作效率。虽然大家都觉得需要一些改进，但是应该从哪里入手呢？要认真考虑的第一步是如何找出日常工作中真正的痛点。
无论是对于Google还是其他组织，软件开发的生命周期基本都是这样的：
列出要构建的特性或要纠正的软件缺陷；
通过阅读大量代码和文档，与同事交流，可以建立对问题的理解，给出一个普遍适用于现有系统的解决方案；
开始编程。首先，做一些能跑的东西。在此期间，您可能需要反复查看文档和一些代码。
一旦代码达到了运行的水平，就不要急于交付。做代码测试，修复缺陷，做进一步的测试。然后重构代码，生成清晰易懂的代码。将代码推送到代码库生成分支，等待持续集成运行。在此期间，代码中可能已经实现了一些额外的修复和小的改进。
提交代码补丁以供审查，并根据团队成员给出的意见进行更改。这个过程可能需要重复几次，直到代码审查者通过更改。
合并补丁并部署它们。
监控已部署系统的运行，并确定生产环境中是否存在问题。如果新补丁导致系统停机，请负责修复问题。
这个过程的每个阶段都需要借助于适用的开发工具来执行。开发工具引导开发人员遵循规则，主导工作流程，控制工作效率。
只有选择合适的工具，才能提高开发效率。我推荐一个Github的代码库，它位于https://github.com/jhuangtw/xg2xg.它列出了几乎所有谷歌内部工具和具有相应功能的外部工具。名单很详细，但略长。
2
开始阶段：熟悉现有工具，不要引入新工具
当我们第一次参加一个项目时，我们不应该试图改变现状，只是遵循规则。
作为团队新人，你不太可能有权利或者影响整个团队去迎合你个人对工具的偏好。另外，你也缺乏对团队工作方式和事物因果的理解。死记硬背的模仿谷歌可能不适合新团队。所以首先要了解新团队的工作方法和禁忌。
三
从简单的改进开始
我觉得首先可以改进的是代码搜索功能。既然我是一家代码搜索公司的联合创始人，我当然这么认为。同时，以下理由更有说服力。如果读者不同意，可以跳过这一节。
代码搜索是谷歌员工经常缺少的日常工具之一。
可以自己尝试各种代码搜索引擎，找出真正好用的选项，然后推荐给别人。也就是说，你不需要得到领导的允许，也不用冒着自己性格的风险去说服别人去尝试你以前从来没有用过的工具。
大部分团队还没有使用过代码搜索工具，所以不存在强迫别人改变现有习惯的问题。如果团队经常使用好的代码搜索工具，可以跳过这一节！
一个新公司可能会有多个团队，所以我们必然会处理超出我们合理能力的代码。即使在小公司工作，也可能通过依赖关系获得大量开源代码。在构建新的函数或追踪一些严重错误的来源时，有必要在某些情况下深入研究所有这些代码。
考虑到目前几乎所有开发人员都需要面对的代码规模，毫无疑问，低效的代码搜索会严重阻碍开发进度，导致一步步的困难。
选择代码搜索引擎时，请考虑以下因素：
查询语言：正则表达式是标准。确保代码搜索查询语言具有表现力且易于使用。提供直观的按词搜索和高级模式匹配功能。
扩展性：确保代码搜索引擎适合当前代码库的大小。如果代码库大小达到几GB，就需要考虑搜索引擎是否支持三元词索引技术。该技术适用于大规模代码库中的正则表达式匹配。
代码浏览：任何用过谷歌代码搜索的人都知道，搜索只是完成了一部分工作。在查看搜索结果时，就像在IDE开发环境中查看代码一样，需要支持跳转到定义函数，方便查找引用。如果代码浏览功能不够强大，需要在编辑器和搜索引擎之间频繁切换。
权限：如果企业强制执行代码库的权限，就要考虑代码搜索引擎对权限的适应性。
整体成本：考虑部署代码搜索引擎的成本和在线使用的整体维护成本。
目前，人们使用的主要代码搜索引擎包括：
OpenGrok:甲骨文的产品，历史最多，一直在用。
猎犬：由Etsy工程师和开源创建的代码搜索引擎。
Livegrep:是Stripe的Nelson Elhage创建的代码搜索引擎。
当然，还有我们的原始图表。
四
良好的监控
监控是早期改进需要考虑的另一个方面。工程师有时不得不处理生产环境中的问题。但是制作和开发差别很大，设置断点或者直接添加printf是不可能在几秒钟内看到效果的。就计算资源、开发人员时间以及最糟糕的用户和客户痛苦而言，生产环境中的更新成本特别高。
在过去的五到十年里，部署发生了很大的变化。微服务、Kubernetes、云迁移等技术极大地改善了企业的软件部署方式。许多企业采用了这些新的方法和技术，但没有更新监控架构来方便地调试新的生产环境。
好消息是有一些不错的开源工具和企业，大大提高了Google之外的监控和可观测状态。
普罗米修斯：博格蒙的时间序列测量跟踪和可视化工具。为用户提供显示在仪表盘上的应用跟踪指标，如CPU使用率、错误率、p90延迟等。
Grafana:标杆总督的仪表盘工具。一个常见的场景是连接到普罗米修斯，并建立一个视图，在一个页面上显示一系列关键指标，以显示应用程序的整体运行状况。
分布式跟踪是日益流行的多服务架构的一个重要工具，谷歌Dapper在这方面处于领先地位。Lightstep是由Dapper的创始人之一本西格曼发起的一个项目。分布式跟踪是很多监控系统提供的功能，包括支付工具蜂巢和哨兵，以及优步工程师推出的开源工具耶格(Jaeger)。
考虑到监控必须集成到生产环境中，这比引入代码搜索更困难。引入监控需要改变部署环境，这意味着说服控制部署环境的团队。监控可能还需要添加仪表板代码，这包括向所有与仪表板代码相关的团队提交补丁。但是引入这样的新工具并不需要任何人去改变现有的习惯，从某种意义上来说也不是不可能的。人们可以自由选择是否使用新工具，这可以避免在实施新工具时面临强烈的反对。
五
循序渐进：代码审查
引入代码搜索和监控不会改变其他团队成员的现有工作流程。然而，改进代码审查工具需要每个人的合作。
对于有Google工作经验的人来说，很有可能不适应Google以外的代码审查方式。对GitHub Pull Request(PR)这种常用的代码审查工具的投诉，主要集中在以下几点：
看到自上次审核以来所做的更改不够直观。简单路径只支持查看显著差异；
不支持积压的变更请求(堆叠的变更请求)；
所有文档的所有差异都显示在同一个页面上，很难跟踪审批的项目；
GitHub PR的审计实现方式没有特色。如果没有添加额外的第三方集成，审核过程将会很松散。即使增加了第三方集成，仍然缺乏强制性的细粒度审计和签出策略功能；
虽然有些语言对模糊的“跳转到定义”和“查找引用”的支持有限，但它们与谷歌使用的批判水平相去甚远。
谷歌之外最接近批判的工具是Gerrit。Gerrit最初是Rietveld的一个分支，Rietveld本身是谷歌最初的代码审查工具Mondrian的开源分支。由于工具行的继承性，它们看起来非常相似，都是为了创建一个Google支持的代码审查方法而设计的。
Phabricator是谷歌前员工喜欢用来取代Github PR的另一个工具。Phabricator最初是作为Facebook的代码审查工具，后来被打开发布。该工具由Phacility支持，为不想维护自己实例的用户提供托管实例和服务支持。
由前谷歌员工Piotr Kaminski创建的Reviewable是另一个值得推荐的工具。不像Gerrit和Phabricator，Reviewable只在云中使用，提供类似Google的代码审查体验。
Gerrit提供了明确的签准，这有助于审计过程更加结构化。如果系统扩展了团队，并在整个组织中实施了更严格的审核策略，则此功能非常有用；
Gerrit方便审阅大量差异，支持逐文件审阅，支持上次审阅后的修改和积压CR，提供更快更全面的审阅。
Gerrit、Phabricator、Reviewable可以实现类似谷歌内部的审计流程，但都没有提供可以校准的代码智能功能。如果当前的代码审查工具没有代码智能，或者发现GitHub PR没有代码智能，可以试试Sourcegraph的浏览器扩展。它连接Sourcegraph实例，为代码审计提供工具帮助，跳转到定义和交叉引用，支持GitHub PR、Phabricato和Bitbucket服务器，并支持Gerrit。
六
准备屠龙大招
软件开发生命周期中最困难的部分通常是持续集成和系统构建。因为要理解building，通常需要仔细理解整个代码库的每一部分。加快建设是每个人的愿望，所以越来越多的人在建筑代码中使用一些技巧和优化措施，这导致只有少数人能够真正确保当前进度中所做的更改不会产生任何负面影响。
简而言之，构建一个系统通常是一个巨大的毛球。在尊重底层开发人员提高开发效率的做法的同时，要认真的逐一澄清。如果你想早发现症状，早解决，Blaze是最好的工具。谷歌甚至帮助开源的Blaze的衍生产品Bazel。但Bazel毕竟不是Blaze，谷歌的外部环境也不是谷歌的工具。比如Blaze缺乏Bazel打包的大规模分布式集群构建功能。
Bazel也不是银弹。Bazel刚发布的时候，Go社区的很多开源项目都转向了Bazel，因为他们对标准Go构建工具的热爱。但是在一年之内，面对Bazel入门的复杂和困难(而且似乎和Bazel的搭建速度也比较慢)，很多项目都转回了Go社区。虽然Bazel对Go的支持有了很大的提升，但是在转向使用它的时候，有必要对所获得的提升进行仔细的评估。
为了进行严格的评估，手边必须有一些有用的开发工具。尤其需要一个好的代码搜索工具，以便研究代码库各个部分的构建脚本，了解它们的来龙去脉。还需要一个好的代码审查工具，因为改变建筑系统是一件复杂的事情，需要许多不同的工程团队的支持。
一旦你做好了屠龙的准备，除了Bazel还有其他工具可以在设计上支持大规模代码库的可伸缩构建。包括：
巴克；由Facebook提供；
Gradle广泛应用于Java领域；
裤子，前谷歌员工为Twitter和Foursquare开发的；
拜托，谷歌前员工推出的新构建工具，主要借鉴Blaze。
还有由前谷歌员工伊夫朱奎拉(Yves Junqueira)发起的YourBase。YourBase本身不是一个构建工具，而是一个持续的集成工具，它独立于后台使用的特定构建工具，在Google之外提供快速、可伸缩的构建。
七
摘要
Google独一无二的提供开发者体验和开发者工具优先，让Google员工和前员工都能从使用一流开发工具获得的第一手经验中受益。这些工具极大地影响了他们的天赋和能力。
一旦离开谷歌，使用这些体验就成为一种竞争优势。人们可以将优秀的新开发工具带入新的组织，提高自己和团队成员的生产力。通过使用这些工具，在大规模软件开发中传播有效的最佳实践可以为新公司带来有效的组织工程，这是谷歌的一大竞争优势。
诚然，大规模的软件建设不是一件容易的事情。正如《人月神话》这本书(神话中的人月知道)所说，好的软件不是靠雇佣更多的开发人员就能实现的。既然软件是最终用户生产力的倍增器，开发工具是软件构建者生产力的倍增器，那么我们需要更好的工具。如果你认同新企业的想法，你可以利用你作为谷歌前员工的独特见解，为新企业带来最好的开发工具。
前谷歌人开发工具指南
https://about.sourcegraph.com/blog/ex-googler-guide-dev-tools/