被逼出来的自主可控，从华为自研看国产IDE的未来和商业模式

我所在的部门“华为云 PaaS 服务产品部”在软件开发工具领域肩负着两大使命：一是为华为内部各产业开发者提供软件开发工具，提升开发效率；二是以华为云为承载平台，将华为内部优秀的软件工程工具和研发实践服务于广大外部开发者。

纵观华为公司的 IDE 发展历程，大致经历了三个阶段：插件开发，自研内核，商业化探索。

华为从 90 年代起开始投入通信产品的研发，有着丰厚的嵌入式软件开发底蕴。华为嵌入式软件开发有几个显著特点：代码量巨大，可达千万行级别；运行环境强依赖特定平台，调试验证困难；过程质量要求高，有集成各 IT 系统诉求，以满足研发流程要求。彼时华为仍是一家以通信产品作为主要方向的设备厂商，对 IDE 领域并未过多投入，加之市场上已有一些成熟的商业和开源软件，能基本满足华为软件研发需求，此阶段 IDE 策略主要是基于以采购商业软件和使用开源软件为主。同时，由于公司对研发过程的质量要求高，大量研发流程需要在 IDE 中承载，这就对 IDE 提出了定制扩展的诉求。因此，各产品团队结合自身业务特点，开发了多款 IDE 插件。

时间来到了 2019 年 5 月，由于众所周知的原因，华为内部研发工具需要进行大面积的自研，以保障研发作业的安全性。面对巨大的生存风险，我们做出了艰难但正确的战略决策：自研 IDE 内核。随后，我们联合各个产品线基于统一底座 + 插件生态 + 语言支持的框架，建设公司的 IDE 解决方案。IDE 是一个复杂的软件系统，要实现所有组件的完全自研不现实也没必要，我们只需要找到最硬的那几根“骨头”把它们啃下来。到 2021 年底，我们基本实现了内部嵌入式软件开发领域 C/C++ IDE 工具的自研替换，部分能力甚至实现了对原有商业工具的超越。

解决自身生存问题的同时，我们也在积极地进行商业化探索。华为云软件开发生产线 CodeArts 就是华为软件研发能力外溢的第一次成功尝试。经过多年持续研发投入，CodeArts 从最初的云上软件开发平台 DevCloud 成长为覆盖软件开发全生命周期的生产线，并一跃成为中国 DevOps 平台市场领导者。而本文的重点“CodeArts IDE 系列产品”（https://ide.huaweicloud.com），就是 CodeArts 产品族中的核心之一。

也是在 2019 年 5 月，我们开始做 WebIDE 服务（本文 WebIDE 指代所有在浏览器当中完成编码调试测试的 IDE 产品形态包括后端部署在云端虚机、容器中的 Cloud IDE），当时目标的细分场景是云原生应用快速开发和部署。2020 年 HDC（华为云开发者大会），我们推出了与华为鲲鹏芯片协同的云端开发环境“华为云 CloudIDE”，成为鲲鹏原生应用开发的首选平台，用户反馈正面。

随着应用现代化、云原生的发展，云端开发场景越来越丰富，CloudIDE 再次被推到舞台中央，这次主打轻量级云原生应用开发部署。我们开发了大量打通云服务开发、调试和部署的插件，并于 2021 年推出了 ToB 的云原生应用集群调试服务 CloudDebugger 和面向云资源租户的 CloudShell 服务。2019 年到 2022 年三年艰难的探索，我们其实做到了不忘初心，并且深刻认识到：“随时随地编码”可能并非高频刚需场景，WebIDE 一定要服务于某个细分场景才能发挥其最大价值。事实上 WebIDE 在华为内部某些嵌入式开发场景已经规模应用起来，特别是开发环境配置复杂，编译构建环境特殊，提供一个开箱即用的 WebIDE 托管服务，对于开发者特别是新手非常有价值。

但是，单纯从一个效率工具的角度看， WebIDE 的还是有一些明显的痛点：首先是性能，托管服务的资源规格相对固定，算力可能不如本地环境强大；其次是灵活性，由于安全合规的要求，云端环境通常不能随意安装组件；再次是安全感，WebIDE 实例随时创建随时销毁，让开发者担心开发较大项目时数据会丢失。最后是使用习惯，在浏览器中进行开发作业需要适应，网络连接也要足够稳定。鉴于这些明显的痛点，我认为下一代 IDE 的主流产品形态应该还是类似传统桌面 IDE，但内涵更广泛。具体来说，下一代 IDE 除了具备传统桌面 IDE 的主要特征外还应该具备以下特征：

第一，智能化全面融入编码、浏览、调试、搜索等各个开发环节。

以代码补全为例，这里大体会有两个方向，一个是类似 GitHub Copilot 和 CodeArts IDE Snap 所谓的 AI 配对程序员，开发者用自然语言注释描述，AI 自动生成代码；一个是短符号的“Tab Complete”代码生成。

关于第一个方向，我个人观点：类似 AI 配对程序员的技术在中短期来看，重点是编程辅助，而不会进入主流开发流程，也不会成为高频刚需场景。究其原因，还是在于“安全感”，AI 生成的大段代码没人敢不做检查就直接提交到代码仓，而代码审核可能更耗时耗力。

关于第二个方向，我们进行了一系列概念验证，发现开发者喜欢“一切尽在掌握”的感觉。在短前缀或者无前缀的情况下，轻量级的 AI 模型对不同场景下的补全结果进行排序，让开发者通过敲击 Tab 键，连续多次完成短符号的代码生成，这种 Tab-Complete-Done 的体验让人愉悦。并且由于是短符号推荐，Top1 命中率远高于多符号补全。当然在推荐列表里也存在当前上下文的可能的长结果（整行补全），开发者可以通过上下键自己选择。

举个“Tab Complete”的例子，比如下面这段代码，理想情况下开发者敲击‘D’+Tab，‘.’+Tab，‘.’+Tab，‘.’+Tab 共八次按键，IDE 连续完成四次函数补全。

“Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();”

第二，随时创建并连接到短暂的、可扩展的远程异构环境。

简单来说，如果开发者需要一个 MySQL 的环境，他不需要在自己 IDE 环境中安装 MySQL，只需要通过 IDE 创建并连接到一个临时的远程 MySQL 环境进行开发测试，环境使用完毕即自动销毁，远程环境的生命周期管理对于开发者来说是透明，开发者也不用关心环境的可获得性。当然，这个能力光靠 IDE 还不行，还需要远端环境服务的支持。事实上过去三年我看到的趋势是，同时做云和 IDE 的厂商持续加强其工具和云服务的联系，只做云或者只做 IDE 的厂商正在尝试报团取暖。

第三，技术上同时兼容 WebIDE 和桌面 IDE 两种使用方式。

随着远程开发技术的成熟，技术上实现一个 IDE 支持两种模式（服务器和桌面模式）已经成为可能。这种架构可以给开发者提供足够的灵活度，彻底解耦编码和编译构建调试环境，也避免交叉编译可能带来的痛苦。

第四，丰富的插件生态、多语言支持和扩展的能力。

Visual Studio Code 插件已然成为事实的标准，下一代 IDE 只要能兼容该标准就能迅速获取海量插件。云原生应用的微服务、容器化、分布式架构等特征也带来了多样化技术栈和多编程语言支持的需求。新场景新编程语言的出现也要求 IDE 能提供扩展语言支持的能力。

这里首先澄清一点，以 Visual Studio Code 为代表的代码编辑器即使搭配语言插件也并不等同于传统桌面 IDE。代码编辑器以文本编辑为中心，以文件和目录为访问对象，而传统桌面 IDE 以代码编辑为中心，以项目为访问对象，二者有本质区别。那么 IDE 的核心技术是什么？图形用户界面 GUI？文本或可视化编辑器？编译构建调试工具的集成？其实都不是。IDE 作为一个效率工具最核心的部分是代码模型的处理引擎，其处理代码的性能，内存占用，索引大小，API 好坏直接决定了上层特性如语法高亮、浏览、补全、重构、检查等的易用性和整个 IDE 的体验是否“丝滑流畅”。

一个完整的代码模型处理引擎至少包括如下四个子系统：

一、项目模型（Project Model）。该子系统主要负责构建项目结构的高级视图，并提供接口访问当前工作空间的项目及其依赖关系、代码在磁盘上的文件夹和文件如何组织的数据结构。以 Java 项目模型为例，其最核心的组件是一个称为代码根（Code Root）的底层接口实现，代码根从逻辑层面代表 Java 项目所有代码的可能来源 – 本项目源代码、底层运行时依赖或第三方依赖包，并提供分析和处理上述代码和生成索引的功能。

二、索引（Index）。每次打开项目，IDE 都要需要花费时间来解析和处理所有源代码，这种处理的中间结果就存储在索引子系统中。项目第一次打开将构建完整的索引，一旦索引构建完成，所有后续的项目加载只需要对增量改动进行索引。索引又分基于文本的索引和基于语义的索引。前者很好理解，创建索引的信息是基于文本的，它不依赖于任何特定于语言的语义，因此是完全本地化到源文件中，该类索引的更新完全基于增加 / 删除 / 改动的文件。而基于语义的索引就比较复杂，它包含的语义信息可能涉及多个源文件。比如“所有返回类型为 A 的方法”的索引就是基于语义的，它给出了一个返回类型为 A 的方法列表。该索引的生成就要依赖于对该项目模型所有源文件的名字解析的过程，并且仅仅考虑添加 / 删除 / 修改的文件来进行更新也是不够的，因为语义依赖信息可能并不仅仅存在于改动的文件中。