前谷歌员工揭秘：拥有顶尖开发工具技能却无用武之地？

很多年以前，我曾在谷歌短暂地工作了一段时间，没错，我也算是谷歌的一名前员工。虽然从谷歌离职后，周围的很多事都发生了不小的变化，但即使只是短暂地接触了谷歌的内部开发工具，也给我留下了深刻的印象。

谷歌内部的开发工具从很多方面来说，都可以算是世界上最领先的。谷歌不仅领头开发了自身软件系统，还优先探索如何大规模且高效地构建软件。多年来，谷歌无论是在代码库规模，还是代码可发现性、组织知识共享和多服务部署相关等问题的解决方案，都是很多其他公司无法企及的。

图源Sourcegraph

然而，从另一个角度来看，谷歌的内部工具是非常局限的。几乎所有的这些工具都和谷歌的内部生态系统紧密相连。所以，这意味着，如果从谷歌离开，你不能把这些工具也一起带走。

从谷歌离职的员工，成为很多其他公司的人才，他们在加入其他公司时，也常会分享在谷歌吸取的经验与教训。但是对于他们来说，使用过最前沿的工具之后，想要适应谷歌以外的编程开发环境并不容易，尤其是在他们已经产生依赖的工具无法使用之后。

这些年，我从自身的经历和其他从谷歌离职的人中学到了许多。

Sourcegraph早期的许多客户，就是因为在离开谷歌后，想念谷歌的代码搜索功能从而寻求我们的帮助。通过和他们密切合作，我们了解他们需要填补的空白，从而更好地构建Sourcegraph以满足他们的需求。一些谷歌前员工在不断探索将开发工具引入新公司的方法，结合他们在谷歌使用开发工具的经验，创造了一些模式。有的探索成效显著，有的则效果不佳。

所以，我认为写一本注重实操的关于谷歌以外的开发工具指南是很有必要的。当然，很多谷歌前员工都希望能够简单地将谷歌内部生态克隆到新的公司，但这显然行不通。

下面我将谈谈我的看法，关于谷歌前员工该从哪里开始的建议，以及能够使其团队高效运作的一些普遍的方法。

谷歌内部工具的软件开发生命周期：使用 or 不使用

刚从谷歌离职的员工在进入一家新公司后，可能有一种挫败感，因效率大不如前。你想要做出一些改变，但是从哪里开始呢？我认为，第一步应该是从日常工作中找出问题所在。

无论是在谷歌内部还是其他组织，软件开发的生命周期都大同小异：

1. 开发者列出要构建的功能或者需要修复的错误；

2. 通过阅读一堆代码、设计文档，和同事讨论，了解问题所在，以及给出一个能基本适应现有系统的解决方案；

3. 编写代码。首要目的是让代码先运行起来。期间可能需要反复查看文档，或者再读几遍代码；

4. 虽然代码已经可以运行，但是还没准备好交付。修复破坏了的测试，再做一些测试。重构代码让代码更整洁，并且让下一个接手的人更容易理解。将代码推送至代码库生成分支，等待CI运行，期间开发者可能还会进行一些额外的修复和细微的改进；

5. 提交修补程序进行审核。根据团队的其他成员提出的意见进行修改。修改以后，在审核人员通过修改以前，这个过程可能还需要重复几轮；

6. 合并补丁，进行部署；

7. 监控系统将检查代码是否存在生产问题。如果新的补丁造成中断，就需要再进行修复。

在上述的每一个阶段，通常会需要工具来辅助开发者。工具能够塑造开发者的工作周期，并且对于生产力有巨大的影响。

为了提高生产力，开发者需要更好的工具。我推荐一个有用的GitHub存储库，其中包括谷歌内部几乎所有工具以及谷歌之外的公司拥有的最接近的工具。（链接：
https://github.com/jhuangtw/xg2xg）这个列表很全面，但是让人眼花缭乱。那么，应该从哪里开始呢？

新工具放一边，先熟悉现有工具

开始的第一个月，不要试图改变，只需要聆听+学习。

作为团队的新成员，你可能没有影响力或权限来更改团队使用的工具。另外，你还缺乏一些对于团队行事风格和原因的了解，以及使用现有工具的理由。简单的复制粘贴谷歌的工具并不一定就适合你的新团队。所以，你需要通过多听多学来了解什么是对团队有用的，而什么是团队不需要的。

从易到难

代码搜索是个好工具。作为代码搜索公司的联合创始人，我这么说像是自卖自夸。但我这么说是有理由的：

• 首先这是谷歌前员工最想念的工具之一；

• 你可以尝试不同的代码搜索引擎，找出好用的再推荐给其他人。这意味着你既不需要获得批准，也不需要花费宝贵的时间来说服其他人使用你自己都没用过的工具；

• 大多数团队还没有代码搜索工具，所以其他人不会被迫改变现有的习惯。（如果你的团队已经开始频繁地使用出色的代码搜索工具，可跳过本节。）

如果你的新公司有多个团队，你可能会需要处理更多的代码，并且一个人摸索。即使你在一家规模较小的公司，也有可能通过依赖项获取大量的开源代码。这些代码是你在构建新功能或者跟踪某些关键Bug来源时需要深入研究的。

考虑到现在开发者必须要处理的代码的规模，如果缺乏代码搜索，就会严重影响开发的进度。

在选择代码搜索引擎时，需要考虑以下几点：

• 查询语言：正则表达式只是入场券。代码搜索引擎应该确保代码搜索查询语言具有很好的表现力，且易于使用的。文字搜索应该是直观的，另外，更高级的模式匹配也是必要的；

• 扩展性：代码搜索引擎要能够适应代码库的规模。如果代码库超过几千兆字节，那么关键就要看代码搜索引擎是否使用了三元组索引，因为这样你才能在大型代码库中实现正则表达式匹配；

• 代码浏览：使用过谷歌代码搜索的人都知道的，搜索并非是其全部。用户希望单击后能跳转到定义并查找引用，就像在IDE开发环境中查看代码一样简单。但是，如果没有出色的代码浏览，用户就需要经常在编辑器和代码搜索引擎之间来回切换；

• 权限：如果公司强制实施代码库权限，那么就需要考虑代码搜索引擎是否符合这些权限；

• 总体成本：考虑代码搜索引擎的价格和保持工具在线的维护开销。

以下一些常见的代码搜索引擎：

• OpenGrok：一个非常老但生命力持久的代码搜索引擎，现在由Oracle维护；

• Hound：由Etsy的工程师创建和开源的代码搜索引擎；

• Livegrep：由Stripe的Nelson Elhage创建的代码搜索引擎；

• 当然，还有我们的Sourcegraph。

获得良好的监测

另一个需要尽早改进的方面是监测。工程师总有些时候必须要处理一些在生产环境中出现的问题。生产和开发截然不同——不能只是设置断点或者添加printf就能马上看到效果。在很多方面，对于生产环境进行更新会产生巨大的开销，比如消耗计算资源，以及花费开发者大量的时间。

在过去的5-10年的时间里，部署发生了巨变。微服务、Kubernetes，云迁移等技术，极大地改变了公司部署软件方式。许多公司已经采用了这些新方式和技术，但这些公司还没有更新其监测基础结构，以便在新的生产环境中轻松地进行调试。

幸运的是，近年来，优秀的新开源工具和公司涌现，它们极大地改善了谷歌之外的世界中的监测和可观察性状态。

• Prometheus：一个时间序列指标跟踪器和可视化工具，类似于Borgmon。它能够让用户通过检测应用程序来跟踪随CPU 利用率、错误率和p90延迟等指标的变化；

• Grafana：一个类似于Viceroy的仪表板工具。一种常见的方式是将Grafana与Prometheus连接起来，这样用户就可以构建指示整体应用程序运行状况的关键指标的单页视图。

谷歌率先推出了分布式跟踪，这是一种日益常见的多服务架构的重要工具。Dapper的创造者之一Ben Sigelman继创建了Lightstep。分布式跟踪现在是许多监测系统的一个功能，包括像Honeycomb和Sentry这样的付费产品，以及像Uber工程师构建的Jaeger这样的开源项目。

考虑到监测必须集成到生产环境中，所以引入监测比引入代码搜索要更加棘手。通常会涉及到更改部署环境，而更改部署环境可能意味着要说服部署环境的团队。监测可能还需要添加监测代码，这需要向拥有所检测代码的各个团队提交补丁。这看起来非常麻烦。但是，从某种意义上来说，引入新工具不需要任何人改变现有的习惯。让开发者自由地使用新的工具，这似乎可以减少很多反对的声音。

代码审查

引入代码搜索和监测都不需要团队改变现有的工作流，但是如果代码审查工具发生变化，那么工作流就会改变。

如果你曾在谷歌工作了一段时间，那么你可能会不适应在谷歌之外进行代码审查的方式。GitHub Pull Requests是最常见的代码审查工具，但Google前员工通常会对此有一些抱怨：

1. 不够直观。有时无法查看自上一轮审核以来所做的更改。简单路径仅允许查看显著的差异；

2. 不支持堆叠的CR；

3. 变更集中所有文件的全部差异显示为一个巨大的页面，并且很难跟踪所查看的内容；

4. GitHub PR的审核机制非常不友好。如果不添加额外的第三方集成，审核流程可能看起来很松散，即使使用了第三方集成，它仍然可能缺乏执行更精确的审核和签出策略的能力；

5. 对于某些语言，模糊跳转到定义或者查找引用存在限制，但是它远比不上谷歌内部使用的Critique的水平。

在谷歌之外，和Critique最接近的是Gerrit。Gerrit最初是Rietveld的一个分支，而Rietveld本身就是谷歌原始代码审查工具Mondrian的开源分支。因此，谷歌前员工应该对它有种亲切感，因为它来自一系列工具，而这些工具是为了支持谷歌进行代码审查的方式而创建的。

另一种谷歌前员工似乎更喜欢代码审查工具是Phabricator。Phabricator最初是Facebook的内部代码审查工具，随后被开源并向外界发布。这款工具由Phacility公司提供托管实例和支持，以防用户因不想为维护自己的实例而陷入麻烦。

还有一个值得研究的工具是Reviewable，它由前谷歌员工Piotr Kaminski创建。不同于Gerrit或Phabricator，Reviewable仅限云的，但能够提供最类似谷歌内部的代码审查体验。

向团队的其他成员推销Gerrit，Phabricator或Reviewable的前提是，现有的代码审查工具让团队感觉很痛苦。

以下是一些通过从类似GitHub-Pull-Request的工具切换到类似Gerrit的工具来解决一些常见问题的方法：

• 通过明确的签发，Gerrit能够提供更具有结构化的审核流程，这对于希望审核策略更加严苛的组织来说是个助力；

• Gerrit可以让审阅大量的差异变得更加轻松，因为用户可以逐个文件查看、查看自上一轮评审以来的更改以及堆叠CR，以便于更快、更彻底地进行审查。

最后一步

在软件开发生命周期中，最棘手的部分通常是CI和构建系统。因为要理解构建，通常需要理解整个代码库的每一个部分。而不断有人在尝试各种方法来加速构建，于是有越来越多的黑客参与构建代码，进行的优化也逐渐增多，直到人们发现不产生负面影响的更改屈指可数。

总之，构建系统就像是一团乱麻，所以在利用底层开发人员的成果之前，需要更加的谨慎。想要早发现早解决的话，Blaze是很好的选择，谷歌甚至帮助开源了Blaze的衍生产品Bazel。但Bazel不是Blaze——首先，它缺乏一个免费的大规模分布式构建集群，毕竟谷歌以外的世界和谷歌不尽相同。

然而，Bazel也不是万能的。Bazel首次发布时，Go社区中的许多开源项目纷纷转向使用Bazel。后来，由于其使用的复杂性、难上手以及Bazel的构建速度实际上较慢等缺点，在一年之内，许多开源项目又将工具切换了回来。不过，自那以后，Bazel对Go的支持有了重大改进。如果你选择再次使用它，还是需要对这些改进进行严格地评估。

进行这些严格的评估需要大量出色的开发工具，特别是需要出色的代码搜索工具，这样你才能深入研究代码库各个部分中的构建脚本，并且了解它们的来龙去脉。代码审查工具也是非常重要的，因为更改构建系统将是一个复杂的过程，需要获得许多不同工程团队的批准。

在万事俱备之前，你还需要知道，除了Bazel之外，还有许多构建工具，这些工具旨在实现大型代码库中的可扩展构建。包括以下几种：

• Buck：来自Facebook；

• Gradle：Java界的宠儿；

• Pants：由前谷歌前员工最初为Twitter和Foursquare创建；

• Please：一个由谷歌前员工创建的新手构建工具；

• 还有YourBase，它不是一个构建工具，而是由谷歌前员工Yves Junqueira发起的CI服务，旨在为Google以外的世界带来超快速和可扩展的构建，而与使用的底层构建工具无关。

总结

和大多数公司不同的是，谷歌优先考虑开发人员体验和开发人员工具。无论是谷歌的员工还是已经离职的前员工，都拥有使用一流开发工具的第一手经验，这些工具使其如虎添翼。

离开谷歌后，这些经验就变成了竞争优势，利用这些经验将新的开发工具带到新的组织中，让自身以及团队的生产力更上一层楼。

大规模构建软件是非常困难的。读过《人月神话》的人都知道，创建好的软件不能单靠雇用更多的工程师。你需要更好的工具，正如软件是最终用户生产力的乘积一样，开发工具也是软件工程师生产力的乘积。如果你认可新公司的使命，那么你的首要任务就是充分运用你在谷歌获得的专业知识，并为其提供最好的开发者工具。