工具公司取名 被迫自主可控，从华为自研看国产IDE的未来和商业模式

作者| 王亚威

策划 | 蒂娜

编者按：目前我们使用的IDE基本都是国外的巨头提供的，比如，，，，但是IDE是软件开发生态的入口，是软件开发的技术基础。 因此，作为存在供应中断风险的根本技术之一，IDE与操作系统、芯片、编程语言一样重要。 此外，随着越来越多的软件开始采用云开发模式，使用国外的开发环境，开发团队和个人也面临着保密性和完整性无法确认等问题。 所以IDE的自主可控的未来发展其实是一件很重要的事情。

但是，相对于其他领域，IDE开发需要更高的能力和大量的编程经验。 国内从事IDE开发的技术专家不多，而本文作者在云和软件开发工具领域有多年经验。 在这篇文章中，他从产品形态、核心技术、商业价值和产业机会等角度，立足当前IDE领域的发展，展望了IDE的未来，并介绍了下一代IDE的投资情况技术、产品和生态建设方向。 这篇文章无论是从洞察力还是经验传承的角度，对整个中国软件行业都具有很大的参考价值。

华为自研IDE之路

我的部门“华为云PaaS服务产品部”在软件开发工具领域有两大使命：一是为华为内部各行业的开发者提供软件开发工具，提高开发效率； 另一种是以华为云为承载平台，利用华为内部优秀的软件工程工具和研发实践来服务外部开发者。

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

华为自1990年代开始投入通信产品的研发，在嵌入式软件开发方面有着深厚的底蕴。 华为的嵌入式软件开发有几个显着特点：代码量巨大，高达数千万行； 运行环境对特定平台的依赖性强，调试和验证困难； 过程质量要求高，需要集成各种IT系统以满足研发过程的要求。 当时，华为还是一家以通讯产品为主攻方向的设备厂商，并没有在IDE领域投入过多。 此外，市场上也有一些成熟的商用和开源软件，基本可以满足华为的软件研发需求。 现阶段IDE策略主要以购买商业软件和使用开源软件为主。 同时，由于公司对研发流程的质量要求很高，大量的研发流程需要承载在IDE中，这就提出了IDE定制化扩展的需求。 因此，每个产品团队都根据自己的业务特点开发了多种IDE插件。

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

在解决自身生存问题的同时，我们也在积极探索商业化。 华为云软件开发产线是华为软件研发能力外溢的首次成功尝试。 经过多年的持续研发投入，从最初的云软件开发平台发展成为覆盖软件开发全生命周期的产线，成为中国平台市场的领导者。 本文的重点是“IDE系列产品”（），它是产品家族的核心之一。

与桌面 IDE

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

随着应用现代化和云原生的发展，云开发场景越来越丰富，再次被推上舞台中央。 这一次，它专注于轻量级云原生应用程序的开发和部署。 我们开发了大量的云服务开发调试部署插件，并于2021年推出了ToB的云原生应用集群调试服务和云资源租户服务。在2019年到2022年的三年艰难探索中，我们不忘初心，深刻体会到“随时随地编码”未必是高频刚需场景，必须服务于某个细分场景才能发挥最大价值。 事实上，华为内部的一些嵌入式开发场景已经大规模应用，尤其是开发环境配置复杂，编译构建环境特殊。 提供开箱即用的托管服务对于开发人员尤其是新手来说非常有价值。

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

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

以代码补全为例，这里一般有两个方向。 一种是类似于IDE Snap的所谓AI配对编程器。 开发者使用自然语言标注进行描述，AI自动生成代码； 另一种是短符号“Tab”代码生成。

关于第一个方向，我个人的观点：中短期内，类似AI配对程序员的技术会以编程辅助为主，不会进入主流开发流程，也不会成为高频的只是——需要的场景。 原因在于“安全感”。 没有人敢把一大段AI生成的代码不检查就提交到代码仓库，代码审查可能会比较费时费力。

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

以“Tab”为例，比如下面的代码，理想情况下，开发者按'D'+Tab、'.'+Tab、'.'+Tab、'.'+Tab共八次击键，而IDE 连续完成四个函数补全。

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

复制代码

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

简单的说，如果一个开发者需要一个MySQL环境，他并不需要在他的IDE环境中安装MySQL。 他只需要通过IDE创建并连接到一个临时的远程MySQL环境进行开发和测试。 使用后环境会自动销毁。 环境的生命周期管理对开发者是透明的，开发者不需要关心环境的可用性。 当然工具公司取名，这种能力单靠IDE是不够的，还需要远程环境服务的支持。 事实上，过去三年我看到的趋势是，既做云又做IDE的厂商不断加强他们的工具和云服务的联系，而只做云或只做IDE的厂商正在努力向集团汇报为了温暖。

第三，它在技术上与桌面和 IDE 使用兼容。

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

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

代码插件已经成为事实上的标准，下一代IDE只要兼容这个标准，就可以快速获得大量的插件。 云原生应用的微服务、容器化、分布式架构等特点，也带来了对多样化技术栈和多编程语言支持的需求。 新场景下新编程语言的出现，也需要IDE提供扩展语言支持的能力。

IDE的核心技术是什么

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

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

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

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

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

四、语义（）。 给定一个表达式“a = x;”，如何确定'x'的种类？ 它是局部变量、函数参数、类字段还是方法名？ 如何确定'x'的类型？ 整数，长，...？ 语义子系统可以回答这些问题。 一般来说，AST是一种用于表示特定源文件的低级代码文件结构，AST节点通常没有具体的类型信息。 还有一种数据类型叫做()。 从 IDE 的角度来看， 是一种更高级的数据结构。 它们由多个源文件的 AST 或二进制依赖包生成，代表跨文件的 AST 节点。 类型信息，可以告诉你一个方法是否是一个构造函数，一个变量属于哪个类型声明。 语义子系统会构建一个完整的符号表，并将相应的符号附加到AST节点上，使其成为带有类型信息的AST（Typed AST）。 这个过程称为类型绑定（type）。 基于Typed AST回答上述“如何判断”问题的过程称为名称解析（name）。

说了这么多工具公司取名，下一代IDE的代码模型处理引擎长什么样子呢？ 这个问题我没有想清楚，但是我们正在探索一种基于统一架构的代码模型处理引擎。 架构大致分为三层： 语言解析层：语言相关，针对不同的语言有不同的解析逻辑； and layer : 语言无关的通用接口； 索引持久层：基于索引元数据的独立于语言的高性能存储系统。 这种设计的好处是最大限度地重用子系统，快速支持新的编程语言。 在技​​术指标层面，下一代代码模型处理引擎应该在补全或引用查找等高频特征上有指数级的性能提升。

商业价值和行业机会

最后，我想谈谈IDE未来在中国市场的商业价值和产业机会。 去年（2022年）是微软诞生25周年。 从第一个版本 97 到 2022，其主要商业模式一直是订阅或许可销售。 微软的商业价值仅仅是销售收入吗？ 如果是的话，后面的代码编辑器Code是免费产品，它的商业价值如何？

微软在2008年左右开始发力云，2014年萨提尔成为微软CEO后，提出“移动优先，云优先”的战略，全面拥抱开源。 “是空气中的我们”被扔进了历史的垃圾场。 随后.NET开源，2016年发布VS Code 1.0并开源，2018年收购，最终形成强大的软件开发工具（VS/VS Code）++Azure的开发者生态价值链，成为推动微软收入持续增长的引擎。 微软深谙“得开发者得天下”的道理，开辟了云战场的新赛道：

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

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

关于作者：

王亚伟，华为云开发工具与效率首席专家，华为软件开发产线首席技术总监，目前带领国际化的软件专家团队，负责IDE系列产品的开发和华为云开发者生态能力建设。 在加入华为之前，他是微软开发者事业部的高级开发经理，在微软多个国家和地区工作了13年。 在云和开发工具方面近 20 年的行业经验使他具备从底层技术、产品规划和开发者生态能力中建立洞察力的能力。 王亚伟先生发表并获得软件开发技术相关发明专利20余项。