从华为投入研发基础开发工具看国产 IDE 的未来和商业模式

华为的 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 产品族中的核心之一。

WebIDE vs 桌面 IDE

也是在 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 能提供扩展语言支持的能力。IDE 的核心技术是什么

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

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

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

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

三、语法（Syntax）。语法是编程语言的底层结构和规则。IDE 使用抽象语法树（AST）来理解编程语言的源代码，而 AST 的访问是高频操作，所以语法子系统的任务就是提供高效和方便的 AST 访问接口给 IDE 其他模块使用。

四、语义（Semantics）。给出一个表达式“a = x;”，如何判断‘x’的种类？是本地变量、函数参数、类字段还是方法名？如何判断‘x’的类型？int，long，string…? 语义子系统可以回答这些问题。一般来说，AST 是一种低层的代码文件结构，用于表示特定的源文件，AST 节点通常不具备具体的类型信息。还有一类数据称之为符号（Symbol），从 IDE 角度看符号是一类更高层的数据结构，它是从多个源文件的 AST 或者二进制依赖包中生成的，代表的是 AST 节点跨文件的类型信息，它可以告诉你某个方法是否是构造函数，某个变量属于哪个类型申明。语义子系统会构造完整的符号表并把对应符号附着到 AST 节点上，使之成为具备类型信息的 AST（Typed AST）, 这个过程称为类型绑定（type binding）。而基于 Typed AST 回答上述“如何判断”的问题的过程称为名字解析（name resolution）。

讲了这么多，那下一代 IDE 的代码模型处理引擎是什么样的呢？这个问题我也没想清楚，但我们在探索一种基于统一架构的代码模型处理引擎，架构大致分为三层：语言解析层：语言相关，不同语言不同的解析逻辑；语法、语义适配层：语言无关通用接口；索引持久化层：语言无关，基于索引元数据的高性能存储系统。这样设计的好处是最大化重用各子系统，并且可以快速支持新编程语言。技术指标层面，下一代代码模型处理引擎应该在补全或引用查找等高频特性方面有指数级的性能提升。

商业价值和产业机遇

最后我想聊聊 IDE 未来在我国市场的商业价值和产业机遇。去年（2022 年）是微软 Visual Studio 诞生 25 周年，从第一个版本 Visual Studio 97 到 Visual Studio 2022，其主要商业模式一直都是订阅或者许可售卖。Visual Studio 对于微软的商业价值是否只是销售收入？如果是，后来的代码编辑器 Visual Studio Code 是免费产品，它的商业价值又是什么？

微软于 2008 年左右开始做云，2014 年萨提亚成为微软 CEO 后，提出“移动为先、云为先”战略，并且彻底拥抱开源，“Windows is the air we breathe”被扔进历史的垃圾堆，随后.NET 开源，2016 年发布 VS Code 1.0 并开源，2018 年收购 GitHub，最终组成了软件开发工具（VS/VS Code）+ GitHub + Azure 的强大的开发者生态价值链，成为驱动微软营收持续增长的引擎。微软在云这个战场开辟了一条新赛道：

· 云服务供应商必须打通开源软件到云服务的价值链。

· 软件开发工具（特别是 IDE 或类 IDE 产品）是这条商业和生态价值链的起点，云服务是终点。

· 在转化率不变的前提下，工具的用户越多，生态入口越大，云的生态越繁荣。

回到我们自己，咱们国家软件产业是否需要一个拥有自主可控核心技术的 IDE？这个问题没有统一答案，不同行业差异很大。但软件供应链攻击的问题（大家有兴趣可以关注下 SolarWinds 供应链攻击事件）让我始终坚信：信创基础软件工具链对于我国高科技企业来说是一个巨大的产业机遇。因此，关乎国家安全的战略性产业，对技术自主可控要求高的企业，这个问题的答案就显而易见。对于需要构建开发者生态的企业或产品，拥有自己的 IDE 可以打造定制化的开发者体验和工作流，降低应用开发难度方便开发者，同时也可以避免将生态构筑在别人的平台之上，在当下这个脆弱的全球产业链大背景之下，这点尤为重要。

未来不管技术如何发展，软件架构如何演进，IDE 作为开发者的效率工具其核心的编码调试测试等功能不会改变。在不同细分领域如 AI、智能汽车、芯片等，其集成的工具链会更广泛，开发场景也会具备更多的业务属性。

作者简介：

王亚伟，华为云开发工具和效率领域首席专家，华为软件开发生产线 CodeArts 首席技术总监，当前领导一支国际化软件专家团队负责 CodeArts IDE 系列产品的研发和华为云开发者生态能力建设。加入华为前，曾任微软开发者事业部资深开发经理，在微软全球多个国家地区工作 13 年。近 20 年的云和开发工具的行业经验让他具备从底层技术、产品规划到开发者生态能力建设洞察的能力。王亚伟先生发表和被授予 20 多项软件开发技术相关的发明专利。