Google 的 IDE 演进小史

不知道你平时用的 IDE 是什么小七的工程师同事有在用 Vim 的也有 Emacs 党IntelliJ 全家桶也有人在用用得最多的可能是 VS Code。只要代码能写好、工具链能跑通似乎大家没有必要使用同一个 IDE。Google 早年也是如此。在 Google 工作了 13 年2011-2024的 Laurent Le Brun 最近写了一篇文章回顾了 Google 内部 IDE 的演进。本篇文章主要讲述 Google 主代码库 google3 下的 IDE 发展史。google3Google 内部最主要的单体代码库也就是 Google 大量核心产品和基础设施代码所在的内部代码仓库。图注Google 内部 IDE 演进大致时间线Google 需要统一 IDE 吗在 2011 年左右Google 内部有人向一些资深工程师提出过一个问题能不能为所有 Googler 提供一个统一、好用的 IDE当时的主流回答基本是否定的。Google 核心架构师 Jeff Dean 也不例外让一群开发者在编辑器上达成一致大概率会引起不满。每个人对编辑器的偏好不同关注点也不同。最后统一 IDE 这件事其实没有那么重要。“Trying to get a group of developers to all agree on a common editor is a recipe for unhappiness. Everyone has different opinions about what is important here, and the advantages and disadvantages of different systems are weighed differently by different people. In the end, it doesn’t matter that much.”via: Jeff Dean这个结论在很长的一段时间里都成立。站在个人开发者的角度只要工具顺手编辑器确实不需要统一。你用什么 IDE并不影响别人读你写的代码。但如果从公司整体效率上来看问题会变得不一样。Google 的代码库和工具链非常特殊。工程师可以自由地选择 IDE但很多基础能力会因此需要在不同 IDE 里重复实现Bazel 支持、Starlark 工具、代码格式化、代码搜索集成等等。这些重复工作不是说完全不可接受。Google 内部有很强的工程文化很多工具项目会自然地“冒”出来有人做了一个内部项目其他人发现有用就会继续贡献。其中一部分项目后面可能会由正式团队接手进行维护。比如Google 大约在 2015 年成立了专门负责 IntelliJ 集成的团队。到这里可能有人发现了其实我们要讨论的不是“IDE 功能够不够好”。真正的问题在于传统 IDE 默认很多东西都发生在本地——源码、本地构建元数据、索引、分析。但当代码库大到 Google 这种规模时这个假设就开始失效了。图注传统 IDE 的本地假设在超大规模代码库下会遇到挑战。云端 IDE在 2013 年前后Google 内部出现了一个 Web 编辑器项目叫 Cider。这个名字来自 Cloud IDE只是后面加了一个 r让名字更好记。从今天看在浏览器里写代码并不稀奇。但放在当时这件事还是挺有意思的。Google 内部本来就有大量 Web 工具。工程师会在浏览器里做代码审查用 Code Search 浏览代码库加上有不少人在用 Chromebook。在这种情况下提供一个能直接在浏览器里快速编辑文件的工具就变得很合理。Cider 最早并不是一个完整 IDE。它一开始的用户大多是技术写作者比如想改一个 Markdown 文件里的错别字不需要处理复杂的版本控制流程打开网页就能改点一下就能发起变更甚至可以在审批通过后自动合入。后来Cider 开始加入越来越多面向开发者的能力。真正的转折点是它通过 Language Server Protocol 支持了代码补全。这让 Cider 不再只是一个轻量的网页编辑器开始变成一个能服务真实开发工作的 IDE。Cider 的关键设计是前端很轻打开速度比传统 IDE 更快复杂的工程能力放在后端来完成。后端会索引整个代码库用户打开网页时很多数据已经准备好了。代码智能不是简单的“变量名补全”。它要知道每个标识符的类型、引用关系和上下文。这背后相当于一张巨大的语言图还是一张持续更新的图因为代码库每秒都有很多新提交。同时IDE 还不能只看最新代码。如果我正在一个项目上开发同事刚刚合入了一段代码我可能不希望编辑器马上去拉新代码从而影响我的开发工作。所以我的 IDE 需要基于我上次同步代码时对应的语言图再叠加我本地的修改。这就是云 IDE 在大规模工程里的价值它不是简单地把本地编辑器搬到网页上而是把索引、分析、代码智能这些本地很难承载的工作放到后端系统里完成。随着能力增强Cider 在 Google 内部越来越流行。当然不同开发者群体的接受度也不同。比如 Go 开发者更容易迁移过去而 Java 开发者往往期待更高级的编辑体验因此转换成本更高。图注Cider 的核心不是“网页编辑器”而是把代码智能放到了后端系统里。Cider V把 VS Code 作为前端Cider 的后端投入是合理的。因为它解决的是 Google 自身规模带来的问题外部并没有现成工具可以直接替代。但 Cider 的前端体验有明显限制。它适合快速修改却很难和成熟 IDE 正面竞争。2020 年方向发生变化。当时 Laurent Le Brun 加入 Cider 团队并担任技术负责人之一。那时Cider 已经是 Google 内部占主导地位的 IDE。团队开始讨论它的未来最后决定在 Cider 中使用 VS Code 前端。这个选择很合理毕竟 VS Code 已经成为主流的 IDE生态开放它语言无关、可扩展也天然适合 Web 场景。切换到 VS Code 前端后Cider 可以直接继承成熟编辑器能力、庞大的扩展生态以及多年积累下来的功能。更重要的是VS Code 的扩展系统可以让 Google 内部更多团队参与进来。过去很多需求都要等待 Cider 团队实现。使用 VS Code 前端后不同团队可以基于扩展系统开发自己的工作流Cider 团队不再是所有需求的唯一入口。图注Cider V 截图2022 年。图片来自 Laurent Le Brun 原文。不过这并不是简单的换个壳。即使前端团队有十多名工程师Cider V 也花了几年时间才成为完整的 Cider 继任者。2021 年开放测试时已经有 5000 名工程师在使用但还有大量工作要做版本控制、代码审查集成、基于 Cider 后端的补全和重构、扩展分发与更新机制等等。IDE 的迁移难点不仅仅是技术。很多用户已经习惯了原来的 Cider 编辑器对细节非常敏感。一个小流程变化、一次额外点击都可能成为迁移阻力。团队甚至需要花几个月时间打磨体验。连配色方案这样的细节也会引发大量讨论。这也间接说明了一件事IDE 承载着开发者长期形成的工作习惯。Cider V 团队会维护自己的本地 fork每月更新并尽量减少本地 hack让代码尽可能和上游 VS Code 保持一致。图注Cider V 中代码审查集成的设计探索2022 年。小结Google 的 IDE 演进史最后并不是一个“所有人必须使用同一个工具”的故事。它更像是在说明当代码库、构建系统、代码审查和协作流程复杂到一定程度时IDE 就不再只是个人偏好的编辑器而会逐渐变成开发流程的入口。Cider V 的价值也不只是把编辑器搬到浏览器里或者套上 VS Code 的前端。更重要的是它把 Google 内部的代码库、版本控制、代码审查、语言服务和扩展能力连接到了一起。于是当越来越多团队使用同一个平台每一次工具改进、每一个内部扩展、每一个 AI 功能集成都能影响更多开发者。这或许也是这段历史最值得参考的地方标准化工具本身不是目的但当它足够贴近真实工作流就会变成组织级的工程杠杆。