Google IDE 发展史

# Google IDE 的发展史 来源：https://laurent.le-brun.eu/blog/a-history-of-ides-at-google 我此前在[一篇关于 Google 规模下代码库演化的文章](https://laurent.le-brun.eu/blog/evolving-a-codebase-at-google-scale)中讨论过，Google 的主要代码库通过严格的工具和规范来支撑其规模化。多年来，有一个明显的例外：IDE。 ``` 背景说明：我于 2011 年至 2024 年在 Google 工作。部分信息可能不够精确，如有反馈我会更新。本文重点介绍 Google 的主要单体仓库 (google3)。 ``` ## 碎片化的生态 与许多公司一样，Google 的工程师们可以自由选择自己喜欢的 IDE，结果生态碎片化严重。2011 年，一些资深工程师被问到：“有没有办法为所有 Googler 提供一套优秀且统一的 IDE？”回答基本上是“不行”。其中，[Jeff Dean](https://en.wikipedia.org/wiki/Jeff_Dean) 回复道： > “试图让一群开发者全都同意使用同一个编辑器，只会招致不满。每个人对什么更重要都有不同看法，不同系统的优缺点在每个人心中的权重也不同。说到底，这事儿没那么重要。” 这种观点多年来一直占主导地位。毕竟，只要同事的代码质量过硬，他们用哪个 IDE 并不重要。但我在 Google 做了 12 年开发者工具，有时还是会琢磨这件事。 从公司生产效率的角度看：你不希望每个工程师花大量时间配置他们的编辑器。尽管工程师们使用不同的 IDE，但有用的集成最终不得不在各个地方重复实现：Bazel 支持、[Starlark 工具](https://laurent.le-brun.eu/blog/an-overview-of-starlark)、[代码格式化工具](https://laurent.le-brun.eu/blog/the-story-of-reformatting-100k-files-at-google-in-2011)、代码搜索集成等等。Google 的内部文化让这一切得以管理。工程师们常常自发启动工具项目，其他人则通过共享代码库发现这些项目并进行贡献。这种贡献通常受到鼓励（通过 [20% 时间](https://en.wikipedia.org/wiki/Side_project_time) 和同事奖金）。关键项目最终会获得正式的人力支持。例如，一个专门负责 IntelliJ 集成的团队大约在 2015 年左右成立。 有些人可能会想，为什么需要一个专门的团队来做这件事？IDE 本身难道不够好吗？部分原因是 Google 有一套独特的工具，如果能提供良好的 IDE 集成，就能让工程师更高效。但还有一部分问题是由单体仓库的庞大规模引起的。传统 IDE 假定源代码、构建元数据、索引和分析都在本地完成。而在 Google 的规模下，这个假设就站不住脚了。 ## 云端 IDE 大约在 2016 年，发生了一件我未曾预料到的事情。一些人开始构建一个基于 Web 的编辑器，命名为 Cider。这个名字是“Cloud IDE”的变体，后面加个“r”是为了更容易记住。 在一家大多数工具都基于 Web 的公司里，人们在浏览器中做代码审查、使用代码搜索浏览代码库……在一家使用 Chromebook 的公司里，从浏览器快速编辑文件其实很有道理。 但让我惊讶的是，Cider 后来竟然在工程师中变得很流行。起初，它主要用于技术写作者编辑 markdown 文件，而无需处理版本控制。对于修正拼写错误来说，这种工作流非常高效。只需点击一下，就能发送拉取请求，并选择在批准后自动合并。如今 GitHub 也有类似功能，但在当时，这对我来说还很新鲜。 随着时间的推移，这个团队陆续添加了越来越多面向开发者的功能。转折点在于他们通过[语言服务器协议](https://langserver.org/)增加了代码补全支持。 Cider 是一个轻量级客户端，启动速度比传统 IDE 快得多。所有神奇之处都发生在后端，后端索引了整个代码库，所以每当有人打开网页时，所有数据都准备好了。 代码智能需要将每个标识符与其类型和引用关联起来。这形成了一个庞大的语言图，每次提交都需要更新。而……代码库每秒会有很多次提交。但 IDE 还需要访问历史数据。如果我在开发一个项目，我的同事合并了他们的代码，我不想立即接受这些变更。因此我的编辑器需要使用与我上次同步日期相对应的图……当然还要加上我的本地修改。 有了这类功能，Cider 在某些人群中的流行度不断上升。例如，说服 Go 开发者切换过来比说服 Java 开发者容易得多（因为后者期待更高级的编辑器）。但能在十亿个文件中搜索并拥有交叉引用，那种喜悦是真实的。 ## Cider V：以 VSCode 为前端 在后端上的投入是合理的：它在解决 Google 特有的问题，而且没有好的替代方案。但前端感觉相当有限：它适合快速修补，但无法与真正的 IDE 竞争。 2020 年，方向发生了变化，我作为技术负责人之一加入了该团队。当时，Cider 已经是公司内占主导地位的 IDE，关于其未来的问题也随之而来。我们决定在 Cider 中使用 VSCode 前端。这是一个很自然的选择：VSCode 已经在 IDE 领域占据主导地位，它不局限于特定语言、可扩展且基于 Web。 通过切换到 VSCode 前端，我们继承了一个成熟的编辑器、一个庞大的扩展生态系统以及多年来积累的功能。许多 Cider 的功能请求在 VSCode 中已经是现成解决方案。更重要的是，扩展系统将为公司内的各个团队赋能，并将 Cider 团队从关键路径中移除。 *2022 年的 Cider V 截图* 即使前端团队只有十几名工程师，也花了好几年才构建出 Cider 的完整继任者。2021 年，公开测试版有 5000 名工程师使用，但要集成所有内容并打磨体验，还有很多工作要做。团队必须支持版本控制；集成代码审查工具；利用 Cider 后端提供代码补全和重构功能；重新设计扩展的发布和更新方式；等等。 许多用户充满热情，习惯了 Cider 编辑器，并期望 Cider V 中每个小细节都一模一样。一些微小的工作流变化或多余的一次点击，可能成为某些用户迁移的障碍。因此，项目中的打磨部分需要数月时间的迭代。甚至连配色方案都引发了大量的讨论。正如 [Joshua Bloch](https://en.wikipedia.org/wiki/Joshua_Bloch) 早在 2011 年就观察到的：“唯一比编程语言更能引发宗教式狂热的东西，就是文本编辑器和 IDE。” 我还可以写写与 VSCode 工程师的互动，以及我们如何向 VSCode 回馈代码，但这篇博文已经够长了。改天我会试着多写一些。但可以说，我们不得不维护本地分支，每月更新，并且尽可能减少本地 hack，与上游代码对齐。 *2022 年代码审查集成的设计探索* ## 统一的 IDE 我这篇博文开头提出了一个关于“为所有 Googler 提供统一 IDE”的问题。它并没有完全实现，但到 2023 年，Google 主要代码库中 80% 的开发工作都在 Cider V 中完成（而且这个数字还在增长）。 每种 IDE 都有其优缺点，但 Cider 通过提供与公司工具的最佳集成来吸引用户，例如出色的版本控制支持，以及代码审查集成，审阅者的评论会以内联方式显示在编辑器中。 最令我兴奋的是，大多数用户使用同一套工具所带来的副作用。这意味着我们可以为该工具投入更多资源（因为每次改动影响更大）。我负责 IDE 的可扩展性，很快，公司内各个团队开始联系我们，开发自己的扩展来改进特定工作流。两年后，大约有 100 个内部扩展正在开发中。这实现了许多以前不可行的场景。 2023 年，管理层推动所有团队越来越多地集成 AI 功能。这带来了诸如[利用机器学习解决代码审查评论](https://storage.googleapis.com/gweb-research2023-media/pubtools/7525.pdf) 和[智能粘贴实现上下文感知的代码粘贴调整](https://research.google/blog/smart-paste-for-context-aware-adjustments-to-pasted-code/) 等酷炫功能。当然还有 AI 代码补全。 随着更多 AI 功能集成到 IDE 中，拥有一个单一、可扩展平台的优势变得更加明显。当然，这非常昂贵，很少有公司能证明这种投入的合理性。但我相信，转向“标准化”（即使非强制）的 IDE 已经产生了巨大影响。 归根结底，标准化工具能创造杠杆效应。 > 评论已关闭，但欢迎反馈。您可以在 [Hackernews](https://news.ycombinator.com/item?id=48073979) 或 [Mastodon](https://floss.social/@llb/116546006457247667) 上讨论。如果您喜欢这类内容，可以通过 [RSS](https://laurent.le-brun.eu/blog/.rss) 订阅。要获取邮件通知，可以尝试 [Feedrabbit](https://feedrabbit.com/) 等第三方工具。