Google十年磨一剑，终使程序员偏爱的IDE黯然失色！

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

对于程序员而言，这句话的夸张程度几乎为零，因为它触及了程序员文化的一个核心方面：

不同的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

云端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方法上点击“查找所有引用”时，IDE背后的代码智能系统已经提前建立好了整个代码库的索引。

分布在不同产品、不同团队中的调用关系将被迅速呈现出来。

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

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

03

VS Code的加入

然而，Cider也面临着一个现实问题。

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

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

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

更麻烦的是，全公司任何团队（如Android团队、Flutter团队、AI团队）想要在Cider中添加特定工具，都必须排队等待Cider团队来编写。Cider团队成为了全公司工具链的瓶颈。

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

让Cider变成一个平台，各业务线团队可以自行编写VS Code插件并在内部分发，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雇主担保类移民。这种方式不需要拼学历、拼英语，也不需要雄厚的资金实力。唯一的“门槛”就是时间，需要耐心等待排期。它比较适合有长远规划、不着急拿身份的家庭。可以先在国内安心发展，等拿到绿卡后再过去生活。当然，每个人的情况都不同，找到适合自己的方式才是最重要的。感兴趣的朋友可以扫码详细了解一下！