Google努力了10年，终于把程序员们最喜欢的IDE都干掉了！

这是Java 集合框架和《Effective Java》作者Joshua Bloch 在2011年说过这样一句话。

如果你接触过程序员，就知道这句话一点都不夸张：

不同 IDE 背后，其实代表着不同程序员文化。

所以，当这种选择偏好扩散到 Google 这样拥有十几万工程师的公司时，一个问题自然出现了：

如果每个人都坚持自己喜欢的工具，公司的开发效率怎么办？

01

碎片化IDE

从个人角度看，程序员A用vim，程序员B用IntelliJ，代码一样提交，没问题。

但是站在 Google 这样的超级工程组织角度，事情没有这么简单。

因为很多基础设施能力，都需要适配不同 IDE。

比如 Google 内部大量使用 Bazel，这是 Google 开源的大规模构建系统。

你的代码可能有个BUILD.bazel文件，普通的IDE是不认识的。

 ├── BUILD.bazel

这个 BUILD.bazel 文件定义了代码如何构建、依赖哪些模块。

问题来了：

IntelliJ 要支持它，需要开发插件。

VS Code 要支持它，需要开发插件。

Eclipse 要支持它，需要开发插件。

甚至 Vim 用户也希望有相关能力。

当公司有几万名工程师，同时存在七八种 IDE 时，每增加一个内部工具，都意味着要维护一整套插件生态，这背后的成本非常惊人。

但是Google碎片化的IDE却存活了很多年，一个很大的原因Google有一个非常特殊的文化：20%时间。

工程师可以拿出20%的时间时间，做自己感兴趣的项目。

很多内部工具，最初就是这么诞生的。

比如有人觉得 IntelliJ 的 Bazel 支持不好，就利用业余时间改进。

如果这个改进被更多工程师喜欢，其他人继续贡献代码，慢慢形成内部项目，最后甚至可能发展成正式团队。

Google 早期使用 Eclipse 时也遇到过类似问题，Eclipse 原本是为“很多小项目 + jar 包依赖”设计的。

但 Google 面对的是完全不同的场景：一个巨大源码仓库，大量源码之间直接依赖，还有复杂的自动构建系统。

结果 Eclipse 经常出现崩溃。

于是有人利用20%时间开发了一个叫 MagicJar 的项目，将Java项目的依赖项构建成直接导入的jar包，而无需解析整个代码树。

这些看似不起眼的小改进，最终推动了 Google 工具链的发展。

02

霸主初现

2013 年左右，Google 内部出现了一个叫 Cider 的项目。

它最初看起来并不起眼：一个运行在浏览器里的编辑器。

但它符合 Google 长期以来的理念：尽可能把计算能力搬到云端。

打开网页，不需要复杂配置，不需要安装庞大的开发环境，就可以开始工作。

同时，由于 Google 使用自己的代码管理系统，开发者修改文件后，可以直接创建代码变更，经过审核后提交到主代码库。

对于一些简单的文档修改、配置调整，这种体验非常高效，所以在初期Cider深受写文档的人喜爱。

慢慢地，Cider开始加入面向程序员的能力，比如通过 Language Server Protocol（LSP）提供代码补全、跳转等功能。

后来大家发现：Cider 真正厉害的地方，并不是浏览器里的编辑器界面。那只是一层外壳，真正的魔法发生在后台。

在你打开 Cider 开始写代码之前，后台已经提前分析并索引了整个代码库。

对于每一个符号（symbol），系统知道：

• 它是什么类型；

• 它在哪里定义；

• 谁调用了它；

• 它依赖哪些代码。

要知道，Google 使用的是单一代码库（monorepo）模式，大量产品和基础设施代码共享同一个巨型代码仓库，规模达到几十亿行。

(参见文章《》)

当后台把这些代码解析、索引，并建立成一个巨大的语义代码图谱时，开发体验会发生质变。

假设你在 Google 负责维护一个底层基础设施库：日志系统（Logging Library）。

现在，你准备把：logger.LogWarning(string msg) 改成logger.LogWarn(string msg)

如果是在普通本地 IDE 中，它只能分析你下载到电脑里的项目代码，帮你修改当前工程里的调用。

但是问题来了：Gmail 后端有没有调用？YouTube 视频服务有没有调用？Google Maps 有没有依赖？广告计费系统有没有使用？

这些代码可能属于完全不同的团队，甚至根本不在你的电脑里，你不可能把整个公司的代码库全部下载下来。

而在 Cider 这类云端 IDE 中，情况完全不同。

当你在 LogWarning 方法上点击 Find All References（查找所有引用） 时，IDE 背后的代码智能系统已经提前建立好了整个代码库的索引。

分布在不同产品、不同团队里的调用关系，会被快速呈现出来。

你看到的不再是一个项目里的代码，而是一张覆盖整个公司的软件依赖网络。

这就是超大规模代码库时代 IDE 的核心能力：开发者面对的是几十亿行代码，但体验却像是在维护一个几万行的小项目。

03

VS Code 入场

不过，Cider 也遇到了一个现实问题。

它的后台非常强大，但是前端编辑体验，并不如 IntelliJ、VS Code 这些成熟 IDE。

原因很简单：自己造一个 IDE 前端，实在太难了。

光标移动、文本渲染、快捷键、多窗口、语法高亮、括号匹配……这些看起来不起眼的小功能，背后都是巨大的工程量。

更麻烦的是，全公司任何团队（如 Android 团队、Flutter 团队、AI 团队）想要在 Cider 里加个特定工具，都必须排队让 Cider 团队帮他们写。Cider 团队成为了全公司工具链的堵塞点。

为什么不直接使用 VS Code 作为前端？

让Cider变成平台，各业务线团队可以自己编写 VSCode 插件并在内部分发，Cider 团队只需维护底座即可。

这就是Cider V 项目。

当然，Google 不能直接拿一个原版 VS Code 来用。

它需要深度改造，支持内部版本控制系统 Piper，整合代码评审系统 Critique，连接 Cider 后端，实现代码补全和智能重构，建立内部插件市场，解决安全、权限和分发问题。

另外，开发者对日常使用的 IDE 拥有极强的习惯依赖（肌肉记忆）。比如：

• 某个快捷键从 Ctrl+Shift+P 变成了 Ctrl+P；

• 代码高亮的某个颜色稍变浅了一点；

• 快捷跳转多需要点击一次鼠标；

这些在普通人看来微不足道的改变，在工程师群体中都会引发核爆级的讨论。

这也是为什么 Cider V 前端即使有了十几名工程师，依然花了数月时间去磨平与老 Cider 的微小体验差异。

04

走向统一

在很多大厂，推动工具统一往往靠自上而下的行政命令，但这容易招致工程师的抵触。

但是Cider V不一样，它没有被强制要求使用，但是到了2023 年却达到了 80% 的占有率！ 而且这一比例还在持续增长。

这对于一家拥有十几万工程师、几十亿行代码的公司来说，确实是一件非常惊人的事情。

我想原因只有一个：Cider V 程序员们用起来确实很爽。

统一并不是目的，不是消灭 Vim、IntelliJ 这些个人选择，真正重要的是，让每个工程师都能更快地理解代码、更安全地修改代码、更高效地协作。

AI 时代已经到来，Cider V这种云端的架构，更适合AI开发，前途不可限量。

很多朋友一直对美国身份非常感兴趣，但是投资移民太贵，人才类移民门槛又太高，普通家庭根本无法实现，是不是去美国就彻底没戏了？

其实很多人忽略了一种高性价比的方式：EW3雇主担保类移民。不需要拼学历、拼英语，也不需要雄厚的资金实力。唯一的“门槛”就是时间，需要耐心等待排期。比较适合有长远规划、不着急拿身份的家庭。先在国内安心发展，等拿到绿卡再过去生活。当然，每个人的情况都不同，找到适合自己的方式才最重要。感兴趣的朋友可以扫码详细了解一下！