Google十年磨一剑，终使程序员钟爱的IDE黯然失色！
2026-09-20 08:16:11未知 作者:徽声在线
2011年，Java集合框架与《Effective Java》的作者Joshua Bloch曾发表过一句引人深思的言论，这句话在程序员圈子里广为流传。
对于程序员而言，这句话的准确性不言而喻：
不同IDE的选择，实际上映射了程序员各自独特的文化背景。
因此，当这种偏好在Google这样拥有庞大工程师队伍的公司中蔓延时，一个关键问题浮出水面：
若每位工程师都坚持使用自己钟爱的工具，公司的整体开发效率将何去何从？
01IDE碎片化现象
从个体视角出发，程序员A偏爱vim，程序员B则钟情于IntelliJ，代码提交时并无差异，看似无碍。
然而，站在Google这样的科技巨擘的立场，情况远非如此简单。
因为众多基础设施的建设，均需适配多样化的IDE环境。
以Google内部广泛使用的Bazel为例，这是Google开源的一款大规模构建系统。
你的代码中可能包含一个BUILD.bazel文件，而普通IDE对此一无所知。
├── BUILD.bazel这个BUILD.bazel文件详细定义了代码的构建流程及依赖模块。
随之而来的问题是：
IntelliJ若要支持它，需开发相应插件。
VS Code亦需插件支持。
Eclipse同样不例外。
甚至Vim用户也期待有相关功能。
在Google这样拥有数万工程师、同时存在多种IDE的公司中，每新增一个内部工具，都意味着要维护一整套插件生态系统，其背后的成本令人咋舌。
然而，Google的IDE碎片化现象却持续多年，这很大程度上得益于Google独特的文化——20%时间政策。
工程师们可以拿出20%的工作时间，投身于自己感兴趣的项目。
许多内部工具，正是源于这样的业余时间开发。
比如，有人觉得IntelliJ对Bazel的支持不够完善，便利用业余时间进行改进。
若此改进受到更多工程师的青睐，其他人便会继续贡献代码，逐渐形成内部项目，甚至可能演变为正式团队。
Google早期使用Eclipse时也遭遇过类似挑战，Eclipse原本为“众多小项目+jar包依赖”设计。
但Google面临的是截然不同的场景：一个庞大的源码仓库，大量源码间直接依赖，还有复杂的自动构建系统。
结果，Eclipse频繁出现崩溃。
于是，有人利用20%时间开发了MagicJar项目，将Java项目的依赖项构建成可直接导入的jar包，无需解析整个代码树。
这些看似微不足道的改进，最终推动了Google工具链的不断发展。
02云端IDE霸主初现
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的核心能力：开发者面对的是数十亿行代码，但体验却如同维护一个几万行的小项目。
03VS 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雇主担保类移民。无需拼学历、拼英语，也无需雄厚的资金实力。唯一的“门槛”就是时间，需耐心等待排期。比较适合有长远规划、不急于拿身份的家庭。先在国内安心发展，等拿到绿卡再前往美国生活。当然，每个人的情况都不同，找到适合自己的方式才最为重要。感兴趣的朋友可以扫码详细了解！
