前Googler开发工具指南

许多年前，我曾在Google工作过一段时间。自那时以来，发生了很多变化，但是即使对Google内部开发人员工具的短暂了解也给我留下了持久的印象。在许多方面，Google内部的开发工具是世界上最先进的。 Google不仅在扩展自己的软件系统方面，而且在弄清楚如何有效地大规模构建软件方面都是先锋。他们已经处理了与大多数其他公司尚未达到的复杂程度有关的代码库数量，代码可发现性，组织知识共享和多服务部署相关的问题。 （有关参考，请参阅Google的软件工程。）

但是，在其他方面，Google的内部工具受到了很大的限制。特别是，几乎所有这些应用程序都与Google独特的内部生态系统紧密相连。不幸的是，这意味着您离开时不能随身携带它们。

Google的海外侨民为许多其他组织注入了惊人的才华，他们吸取了在世界领先的技术组织之一中工作的经验教训。但是要适应Google外部的编程可能会很困难，尤其是当您开始依赖不再使用的工具时。

多年以来，我从自己的经验以及许多其他离开Goog​​le的经验中学到了东西。 Sourcegraph的许多早期客户始于离开Goog​​le后的前Googler缺少代码搜索。我与这些人紧密合作，以了解他们试图填补的空白，以便我们可以构建Sourcegraph来满足他们的需求。随着时间的流逝，从前Google员工如何寻求新的开发工具到他们的组织中的模式出现了，灵感来自他们对Google开发工具的经验。有些成功，有些则没有。

我认为，为实用型和实用性着眼，为前Googler编写Google外部开发工具指南会有所帮助。毫无疑问，许多前Google员工希望他们可以将Google内部的开发工具生态系统简单地克隆到他们的新公司中，但是您不能为之困惑。这是我应从何处开始的看法，我认为前Google员工可以采取一般方法来找到使他们（以及他们的新团队）尽可能高效的工具

如果您最近离开Goog​​le加盟另一家公司，您可能会感到整体上的沮丧感，使您的工作效率不如从前。您认为您需要更改某些内容，但这是什么？第一步，您应该考虑自己每天做些什么，并确定疼痛的根源。

您想到了要构建的功能或需要修复的错误。

您阅读了一堆代码，设计文档，并向同事提问。您正在了解问题以及解决方案将如何大致适合现有系统。

您开始编写代码。您首先瞄准的是可以正常工作的东西。也许您回去查找文档或在执行此操作时多次阅读一些代码。

您可以使用它，但是还没有准备好发货。您已经破坏了一些测试，现在修复了这些问题，添加了更多测试，重构了代码以使其更干净，更容易让下一个人理解。您将其推到分支。您等待CI运行，也许您会实施一些其他修复程序和小的改进。

您将补丁提交进行审查。您的队友发表了一些评论。您进行更改。在审核者批准更改之前，可能要经过几轮来回的操作。

现有的监视系统将确定是否存在任何生产问题。如果是导致中断的补丁程序，那么您就可以修复它。

在此过程的每个阶段，通常都有一个工具可以辅助开发人员的体验。工具会影响您的工作周期，并极大地影响您的生产率。

为了提高生产率，您需要找到更好的工具。有一个有用的GitHub存储库，可识别Google内部几乎所有的单个工具以及Google外部最接近的同类工具：https：//github.com/jhuangtw/xg2xg。这份清单很全面，但有点让人不知所措。那你会从哪里开始？

在您的第一个月，请勿尝试更改任何内容。只是听和学习绳索。

作为团队的新成员，您可能无权或无权更改团队使用的所有工具。此外，您还缺乏知识-了解新团队如何以及为何表现方式以及为何使用当前工具集。只需复制粘贴适用于Google的内容，不一定适用于您的新团队。因此，了解什么对您的新团队有效，哪些无效。

我相信代码搜索通常是一个很好的开始。是的，我是代码搜索公司的联合创始人，所以我当然会这么说，但这是我的原因-如果这些不引起您的共鸣，那么我建议跳到下一部分！

您可以自己尝试使用不同的代码搜索引擎，然后在与他人共享之前先验证一个是好的。这意味着您无需获得网守的批准，也不需要花费宝贵的社会资本说服他人尝试您尚未开始使用的工具。

不需要强迫别人改变现有习惯，因为您的新团队还没有代码搜索工具。如果他们这样做了，那就不好了，或者他们使用得不多，或者很好，并且您已经有了很好的代码搜索，所以跳过本节！

如果您的新公司在组织中拥有多个团队，则您可能要处理更多的代码，这些代码可以作为一个人合理地使用。即使您在一家规模较小的公司工作，也有可能通过依赖项获取大量开源代码。在构建新功能或跟踪某些严重错误的来源时，您需要在某些时候深入研究所有这些代码。

考虑到如今几乎每个开发人员都必须处理的代码量，毫无疑问，缺少代码搜索会迅速降低您的爬网开发速度。

查询语言：正则表达式是赌注。您想确保代码搜索查询语言既具有表达能力又易于使用。文字搜索应该是直观的，并且应该提供更高级的模式匹配。

缩放：确保代码搜索引擎可缩放到代码库的大小。如果您的代码库超过几GB，那么要查找的关键是代码搜索引擎是否使用三元组索引https://swtch.com/~rsc/regexp/regexp4.html，因为这是您获取常规代码的方式表达式匹配可以在大型代码库中工作。

代码浏览：作为Google代码搜索的用户，您知道搜索只是故事的一半。单击完结果后，您希望能够四处单击以跳转到定义并查找引用，就像签出代码并在IDE中设置开发环境一样容易。 *如果没有出色的代码浏览功能，您将经常在编辑器和代码搜索引擎之间进行上下文切换。

权限：如果您的公司强制执行代码库权限，则应考虑您的代码搜索引擎是否尊重这些权限。

总成本：同时考虑代码搜索引擎的价格和使该工具保持在线状态的维护费用。

另一个值得关注的早期领域是监视。每个工程师在某个时候都必须处理生产问题。生产与开发是一个截然不同的地方-您不能只设置一个断点或添加一个printf就可以在几秒钟内看到效果。在多个方面进行生产更新是昂贵的：计算资源，开发人员时间，最糟糕的是，给用户和客户带来痛苦。

在过去的5-10年中，部署发生了很大变化。微服务，Kubernetes，迁移到云—这些是公司部署软件方式的重大转变。许多公司已经采用了这些新的范例和技术，但是他们尚未更新其监视基础结构以简化在这些新生产环境中的调试。

幸运的是，近年来出现了一些很棒的新开放源代码工具和公司，它们极大地改善了Google之外的世界中监视和可观察性的状况。

Prometheus是时间序列指标跟踪器和可视化器，类似于Borgmon。它使您可以对应用程序进行检测，以跟踪随时间变化的指标，例如CPU利用率，错误率和p90延迟。

Grafana是类似于Viceroy的仪表板工具。常见的情况是将Grafana与Prometheus连接起来，因此您可以构造一堆显示整个应用程序健康状况的关键指标的单页视图。

Google率先使用Dapper进行分布式跟踪，这是用于日益常见的多服务体系结构的基本工具。 Dapper的创建者之一Ben Sigelman继续创立了Lightstep。现在，分布式跟踪已成为许多监视系统的功能，包括由Honeycomb和Sentry等付费产品以及由Uber工程师构建的Jaeger等开源项目。

引入监视比引入代码搜索要难一些，因为它必须集成到生产环境中。这通常涉及更改部署环境，这可能意味着说服控制该部署环境的团队。它还可能需要添加检测代码，这涉及向拥有所检测代码的各个团队提交补丁。但是，从某种意义上说，引入新工具并不需要任何人改变现有习惯仍然很容易。人们可以自由使用或不使用新工具，这在您尝试首先部署该工具时消除了强烈的反对意见。

引入代码搜索和监视不需要要求团队中的任何人更改现有工作流程。但是，更改代码检查工具确实可以。

很有可能，如果您已经在Google待了一段时间，那么在Google之外进行代码审查的方式会让您有些奇怪。 GitHub Pull Requests是最常见的代码审查工具，但前Google员工通常对此有一些抱怨：

这并非一帆风顺，有时无法查看自上一轮审核以来所做的更改。简单的路径仅使您可以查看整个未完成的差异。

变更集中所有文件的整个差异显示为一个巨大的页面，很难跟踪您查看过的内容。

GitHub的公关人员对如何进行审查非常没有意见。如果不添加其他第三方集成，则审核过程看起来就很松散，即使使用第三方集成，它仍可能无法执行更细粒度的审核和签核策略。

某些语言的模糊跳转至定义或查找引用的功能有限，但距离Critique在Google内部支持的水平还差得远。

您可以在Google之外找到最接近Critique的东西是Gerrit。 Gerrit最初是Rietveld的分支，Rietveld本身就是Google原始代码审查工具Mondrian的开源分支。因此，它应该非常熟悉，因为它源自为支持Google进行代码审查的确切方式而创建的一系列工具。

Phabricator是前Google员工通常更喜欢GitHub Pull Requests的另一种代码审查工具。 Phabricator最初是Facebook的内部代码审查工具，后来被开源并发布给外界。背后还有一家公司Phacility，可提供托管实例和支持，以防您不想维护自己的实例。

另一个值得研究的工具是前Googler Piotr Kaminski创建的Reviewable。与Gerrit或Phabricator不同，它仅是云计算，但可能提供与当今Google内部最接近的代码审查体验。

在向团队其他成员出售Gerrit，Phabricator或Reviewable的好处时，重要的是要确定团队使用其现有的代码审查工具所面临的痛苦。这是通过从类似GitHub-Pull-Request的工具切换到类似Gerrit的工具来解决一些常见痛点的方法：

Gerrit通过明确的签名来促进更结构化的审阅过程，如果您已经扩大了团队并希望在整个组织中实施更严格的审阅策略，那么这将是一个很好的选择。

Gerrit使查看更大的差异更加容易，因为您可以逐个文件查看文件，查看自上一轮检查以来的更改以及堆栈CR。这样可以进行更快，更彻底的检查。

Gerrit，Phabricator和Reviewable使您可以近似地了解您在Google内部进行的常规审核流程，但是代码情报都无法提供。如果您在当前的代码检查工具中缺少代码智能，或者发现缺少GitHub PR代码智能，请尝试使用Sourcegraph浏览器扩展。它连接到Sourcegraph实例，以在代码检查期间提供工具提示，跳转到定义和交叉引用。它适用于GitHub PR，GitLab MR，Phabricator和Bitbucket Server。正在支持Gerrit。

软件开发生命周期中最难处理的部分通常是CI和构建系统。这是因为理解构建通常涉及以相当细微的方式理解整个代码库的每一部分。随着时间的推移，各种人都在尝试加快构建速度，因此构建代码会产生越来越多的黑客攻击和优化措施，直到达到真正了解要做什么的人数为止。变化为零的负面后果非常小。

简而言之，构建系统通常是一个巨大的毛团，在摘取较低的开发人员生产力果实之前，应谨慎尝试解开纠结。可能会更早地解决这个问题，因为Blaze的世界比您现在使用的要好，而且Google甚至还帮助开源了Blaze的衍生产品Bazel。但是Bazel并非Blaze，其中一个就是它缺少与之免费提供的庞大的分布式构建集群，而且Google之外的世界也不是Google。

Bazel不是灵丹妙药。 Bazel首次发布时，Go社区中的许多开源项目都转而使用它，以支持标准的Go构建工具。但是，在一年之内，由于使用的复杂性，Go社区其他成员的不熟悉以及Bazel的建造速度似乎变慢，其中的许多人都转回来了。从那时起，Bazel对Go的支持有了重大改进，但是您需要严格评估如果切换到Go将会看到哪些改进。

为了进行严格的评估，您将需要拥有许多其他出色的开发工具。特别是，您将需要进行出色的代码搜索，因此您实际上可以深入研究代码库各个部分中的构建脚本，并了解它们的来龙去脉。您还需要一个出色的代码审查工具，因为更改构建系统将是一项复杂的更改，需要许多不同的工程团队的批准。

一旦准备好杀死巨龙，您应该了解Bazel之外还有许多构建工具，这些工具旨在在大型代码库中实现可扩展的构建。这些包括：

还有一个YourBase，它不是构建工具，而是由前Googler Yves Junqueira启动的CI服务，用于将超快速和可扩展的构建引入Google之外的世界，而与所使用的基础构建工具无关。

Google以不同于其他大多数公司的方式优先考虑开发人员的经验和开发人员的工具。 Google员工和前Google员工受益于使用一流开发工具的第一手经验，这些工具为他们的天赋和能力带来了巨大的影响。

离开Goog​​le后，您的竞争优势之一就是可以利用这些经验，将出色的新开发工具带入您的新组织中，以提高自己的生产力和团队成员的生产力。通过使用这些工具来传播有效的最佳实践，以大规模开发软件，您可以为新公司带来Google的一项主要竞争优势，即其工程组织的效率。

大规模构建软件很难。正如阅读过《神话人月》的每个人都知道的那样，仅雇用更多的工程师就无法获得更好的软件。您需要更好的工具。正如软件是最终用户生产力的乘数一样，开发工具也是软件开发人员的生产力的乘数。因此，如果您真的相信新公司的使命，那么将其作为前Googler来使用自己的专业知识并带给他们最好的开发人员工具成为您的优先事项之一。

试用Sourcegraph。通过自我托管Sourcegraph开始搜索代码-最多可容纳10位用户。或者尝试使用Sourcegraph Cloud轻松搜索公开的开放源代码。

请随时通过在Twitter @srcgraph上发布或向[受电子邮件保护]发送电子邮件来问我们问题。