如何在软件开发中引入好的内部生态系统紧密耦合

菏泽炫佑科技

如何在软件开发中引入好的内部生态系统紧密耦合

本文*初发表于（《An ex-'s Guide to dev tools》），经原作者授权由 InfoQ 翻译分享。

许多年前，我曾在谷歌短暂工作过。 尽管此后发生了很多变化，但在 期间接触其内部开发工具的经历对我产生了持久的影响。 在很多方面，谷歌的内部开发者工具都是世界上*好的。 谷歌不仅在自身软件系统的扩展方面处于领先地位，而且在大型软件的高效构建方法方面也处于领先地位。 针对代码库大小、代码可发现性、组织知识共享、多服务部署等问题提供了解决方案，达到了大多数企业尚未达到的水平。 作为参考，推荐《 》（“at”）一书。

但另一方面，谷歌的内部工具却非常有限。 事实上，几乎所有此类工具都与谷歌独特的内部生态系统紧密耦合。 这意味着一旦人们离开工作岗位如何在软件开发中引入好的内部生态系统紧密耦合，他们就无法在其他环境中使用这些工具。

尽管如此，这些才华横溢的谷歌前员工还是从在世界领先技术组织工作中吸取了经验教训，为许多其他组织注入了新的动力。 但适应谷歌之外的编程开发环境并不容易，尤其是当他们所依赖的一些工具无法再使用时。

多年来，我从自己和许多离开谷歌的人身上学到了很多东西。 我们的许多早期客户找到我们是因为他们离开谷歌后错过了原来公司的代码搜索功能。 通过与客户密切合作，我们了解他们迫切需要填补的空白，然后构建功能来满足他们的需求。 谷歌前员工正在探索如何在当前组织中使用新开发工具的模式。 这项工作的灵感来自于他们使用谷歌开发工具的经验。 当然，有的探索成功了，有的探索失败了。

在这个主题上，我认为编写一份关于外部开发工具的实用指南是有意义的。 能够将谷歌的内部开发工具生态系统直接克隆到新公司中，无疑是许多前谷歌员工的愿望，但要注意不要过于雄心勃勃。 以下是我对前 员工如何开始寻找工具以使他们及其新团队尽可能高效工作的看法。

软件开发生命周期

对于刚刚离开谷歌并加入其他公司的人来说，可能很难适应工作效率的大幅下降。 虽然每个人都同意需要进行一些改进，但您从哪里开始呢？ 首先需要认真思考的就是如何发现日常工作中真正的痛点。

无论是在 还是其他组织内部，软件开发生命周期基本上是这样的：

列出需要构建的功能，或需要修复的软件缺陷；

通过阅读大量代码和文档，并与同事交流，建立对问题的理解，并提出总体适合现有系统的解决方案；

开始编程。 首先做一些有用的东西。 在此过程中，您可能需要反复查看文档和部分代码。

一旦代码准备好运行，不要急于交付它。 进行代码测试、修复缺陷并进行进一步测试。 然后重构代码，生成干净且易于接管人理解的代码。 将代码推送到代码库构建分支并等待持续集成运行。 过渡期间的代码可能已经实现了一些额外的修复和细微的改进。

提交代码补丁以供审核，并根据团队成员给出的意见进行更改。 此过程可能需要重复多次，直到代码审阅者批准更改。

合并补丁并部署它。

监控已部署系统的运行情况，判断生产环境是否存在问题。 如果新补丁导致系统停机，请负责修复问题。

该过程的每个阶段都需要在合适的开发工具的帮助下进行。 开发工具引导开发人员遵循规则、主导工作流程、控制工作效率。

软件开发阶段

谷歌内部工具

适用于非 环境的可选工具

寻找特征或缺陷

问题

,吉拉

读代码

代码

开发者首选编辑器，如Hound等。

编写代码

,, Emacs, Vim, VS 代码

任何工具，除了

测试代码

火焰

工具多种多样，其中Bazel备受关注

审查代码

，，，等待

部署

博格

监视器

,,

，，，，等待

只有选择合适的工具才能提高开发效率。 我推荐一个代码库，位于 . 它列出了几乎所有的内部工具，以及具有相应功能的外部工具。 该列表非常详尽，但有些冗长。

开始阶段：熟悉现有工具，不要引入新工具

当我们**次参与一个项目时，我们不应该试图对现状做出任何改变，只要遵循规则即可。

作为团队的新成员，您不太可能有权力或影响力来影响整个团队以满足您个人的工具偏好。 另外，你对团队如何做事以及事情的前因后果也缺乏了解。 机械地复制谷歌的做法可能不适合新团队。 因此，**步是了解新团队的工作方式和禁忌。

从可以轻松改进的领域开始

我认为首先可以改进的是代码搜索功能。 鉴于我是代码搜索公司的联合创始人，我当然这么认为。 同时，下面给出更有说服力的理由。 如果读者不同意，可以跳过本节。

新公司可能有多个团队，这个时候我们就不可避免的要处理超出我们合理能力范围的代码。 即使在较小的公司工作，我们也可能通过依赖关系访问大量开源代码。 在构建新功能或追踪某些严重错误的根源时，有时您需要深入研究所有这些代码。

考虑到目前几乎所有开发人员面临的代码规模，毫无疑问，低效的代码搜索将严重阻碍开发进度并导致困难。

选择代码搜索引擎时，请考虑以下因素：

目前使用的主要代码搜索引擎包括：

良好的监控

监控是早期需要考虑改进的另一个领域。 工程师有时必须处理生产环境中出现的问题。 但生产与开发有很大不同。 你无法设置断点或直接添加并在几秒钟内看到效果。 在生产中进行更新在计算资源、开发人员时间方面特别昂贵，*糟糕的是，给用户和客户带来痛苦。

在过去五到十年中，部署发生了巨大变化。 微服务、云迁移等技术极大地改善了企业部署软件的方式。 许多企业已经采用了这些新的方法和技术，但尚未相应地更新其监控架构以轻松调试新的生产环境。

好消息是，已经有一些很棒的开源工具和公司极大地改善了 之外的监控和可观察性环境。

考虑到监控必须融入生产环境，比引入代码搜索难度更大。 引入监控需要对部署环境进行更改，这意味着要说服控制部署环境的团队。 监控可能还需要添加仪表板代码，这涉及向所有仪表板代码相关团队提交补丁。 但引入这样的新工具并不需要任何人改变现有的习惯，从某种意义上说，这并非不可能。 人们可以自由选择是否使用新工具，避免了推出新工具时遭到强烈反对。

一步一步：代码审查

引入代码搜索和监控不会改变其他团队成员现有的工作流程。 然而，改进代码审查工具需要大家的合作。

对于有 工作经验的人来说，他们很可能不会适应 之外的代码审查方法。 对于常用的代码审查工具Pull（PR），投诉主要集中在以下几点：

不够直观，有时无法看到自上一轮审核以来所做的更改。 简单路径仅支持查看显着差异；

不支持积压的变更请求 (CR)；

在同一页面上显示所有文件的所有差异，从而难以跟踪审核项目；

PR审查的实施方式毫无特色（）。 如果没有额外的第三方集成，审核过程就会很宽松。 即使添加了第三方集成，它仍然缺乏执行细粒度审计和检查策略的能力；

虽然某些语言对模糊“跳转到定义”（jump-to-def）和“查找引用”（find-）的支持有限，但与 内部使用的水平还相去甚远。

之外*接近的工具是 . 它*初是 的一个分支，本身就是 原始代码审查工具的开源分支。 由于工具系列的遗留，两者看起来非常相似，旨在创建由 支持的代码审查方法。

是谷歌前员工更喜欢的另一种工具来替代公关。 它*初是作为代码审查工具，后来开源并向外界发布。 该工具由该公司支持，该公司为不想维护自己的实例的用户提供托管实例和服务支持。

由前 员工 Piotr 创建的工具是另一个值得推荐的工具。 与 和 不同，仅在云中可用，提供类似于 内的代码审查体验。

为了向其他团队成员推荐代码审查工具的好处，指出使用团队现有代码审查工具的痛点非常重要。 以下是从PR类工具切换到PR类工具解决的一些痛点：

、 、 可以实现类似于谷歌内部的审查流程，但它们都还没有提供可基准测试的代码智能功能。 如果当前的代码审查工具没有代码智能，或者您发现 PR 中缺少代码智能，您可以尝试浏览器扩展。 它连接实例，提供代码审查工具帮助，跳转到定义和交叉引用，支持 PR 和服务器，并正在实现对 .

准备屠龙行动

软件开发生命周期中*棘手的部分通常是持续集成和构建系统。 因为理解构建通常需要详细了解整个代码库的每个部分。 加快构建速度是每个人的愿望，因此构建代码中使用了越来越多的技巧和优化，只有少数人能够真正确保所做的更改不会产生任何负面影响。

简而言之，构建系统通常非常庞大。 在尊重底层开发者实践提高开发效率的同时，还需要一一仔细梳理清楚。 如果您想尽早发现症状并尽早解决问题，Blaze 是*好的工具。 甚至为 Blaze 的衍生品 Bazel 开源提供帮助。 但Bazel毕竟不是Blaze，的外部环境也不是适合的工具。 例如，Blaze 缺乏 Bazel 中打包的大规模分布式构建集群功能。

Bazel 也不是万能药（）。 当 Bazel 首次发布时软件开发，Go 社区中的许多开源项目出于对标准 Go 构建工具的偏好而转向 Bazel。 但一年之内，许多项目面对 Bazel 的复杂性和上手难度（而且看起来使用 Bazel 的构建速度也更慢），又回到了 Go 社区。 尽管 Bazel 目前对 Go 的支持已经有了很大的改进，但是在转向它时需要仔细评估所获得的改进。

进行严格的评估需要手头有一些好的开发工具。 特别是，您需要良好的代码搜索工具，以便您可以实际深入研究代码库各个部分的构建脚本并了解它们的来龙去脉。 还需要良好的代码审查工具，因为更改构建系统是一件复杂的事情，需要多个不同工程团队的支持。

一旦您准备好屠龙，Bazel 之外还有其他工具旨在支持大型代码库中的可扩展构建。 包括：

它也是由前谷歌员工伊夫发起的。 它本身不是一个构建工具，而是一个持续集成工具，可以在 之外提供快速且可扩展的构建，独立于幕后使用的特定构建工具。

总结

独特地优先考虑开发人员经验和开发人员工具，使 员工和前员工能够从使用**开发工具的**手经验中受益。 这些工具极大地影响了他们的才能和能力。

一旦你离开谷歌，利用这些经验就会成为一种竞争优势。 人们可以将出色的新开发工具引入新组织，从而提高自己及其团队成员的工作效率。 通过使用这些工具在大规模软件开发中传播有效的*佳实践，新公司可以实现组织的有效工程，这对谷歌来说是一个主要的竞争优势。

诚然，大规模构建软件并不是一件容易的事。 正如《人月都知道》一书中所说，好的软件不是通过雇用更多的开发人员来制作的。 鉴于软件是*终用户生产力的倍增器，而开发工具是软件构建者生产力的倍增器，我们需要更好的工具。 如果你认同新企业的理念，那么就用你作为前员工的独特见解，为新企业带来*好的开发者工具。

原始链接：前任开发工具指南

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等