Google十年磨一剑，终使程序员钟爱的IDE逐渐退场！

2011年，Java集合框架与《Effective Java》的作者Joshua Bloch曾发表过一句引人深思的言论，这句话在程序员群体中引起了广泛共鸣。

对于程序员而言，这句话的内涵远不止字面意思那么简单：

不同IDE的选择，实际上折射出程序员文化的多样性。

因此，当这种偏好在Google这样拥有庞大工程师队伍的公司中蔓延时，一个关键问题浮现出来：

如果每位工程师都坚持使用自己偏爱的工具，公司的整体开发效率将如何保障？

01

IDE碎片化现象

从个体视角看，程序员A使用vim，程序员B选择IntelliJ，代码提交并无障碍。

然而，在Google这样的巨型工程组织中，情况远非如此简单。

众多基础设施能力需适配不同IDE，这成为一大挑战。

例如，Google内部广泛使用的Bazel构建系统，便是典型例证。

代码中可能包含BUILD.bazel文件，而普通IDE对此一无所知。

 ├── BUILD.bazel

此文件定义了代码的构建方式及依赖模块。

问题随之而来：

IntelliJ需开发插件以支持，VS Code亦需如此，Eclipse、Vim等亦不例外。

当公司拥有数万名工程师，且IDE种类繁多时，每引入一个内部工具，都意味着需维护一整套插件生态，成本之高，难以估量。

然而，Google的IDE碎片化现象却持续多年，这得益于其独特的文化——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的核心能力：开发者面对数十亿行代码，体验却如维护几万行小项目般轻松。

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雇主担保类移民。无需拼学历、英语，亦无需雄厚资金实力。唯一“门槛”便是时间，需耐心等待排期。适合有长远规划、不急于拿身份的家庭。先在国内安心发展，待拿到绿卡后再赴美生活。当然，每个人情况不同，找到适合自己的方式才最重要。感兴趣的朋友可扫码详细了解！