随着前端开发的发展更迭，前端日常开发工作变得愈发复杂愈发深入，同时前端工程中从项目初始化、编译、构建到发布、运维也变得细化而成熟。日常前端工作的每个环节都涌现出丰富的工具、服务和解决方案来解决工程效率的问题。那么，前端工程化的下一阶段的突破口是什么，我们期望通过 IDE 的方式和视角来找寻答案。
行业分析
行业趋势
其实 IDE 本身不是一个新兴的概念，在维基百科上能找到第一款的 IDE 是来自 55 年前为 BASIC 语言提供研发能力的一款软件工具，而最近的一到两年时间内，IDE 的业内动态突然呈上涨趋势。
从外部视角来看，可以看到有两个趋势浮出水面，一个是 IDE 领域相关的创业公司逐渐浮现出来，出现了许多相关的创业明星公司：
- 起初由前端脚本编译项目到现阶段容器化能力支撑编译服务能力、不断突破倍受好评的 codesandbox 平台；
- 出自 Eclipse 研发老牌团队研发，目前被各大公司、厂商，包括谷歌计算服务(GCP)采用 theia-ide 解决方案；
- 以及号称兼容 VSCode 程度最高的 coder 项目；
除此之外还有很多小而美的 IDE 落地场景，如 RN 研发明星产品 expo 的配套云端工具，发展成 npm 官方配套的 runkit 平台。
另一个趋势是云厂商市场上巨头的投入也开始增加：
随着 AWS 完成对老牌云端 IDE 工具 Cloud9 的收购之后，国内腾讯云也完成对 Coding 的战略投资，而近期也完成对 Coding 公司收购。而近期微软也拿出了自己的解决方案，推出了云端版本的 VSCode。
从阿里体系视角来看，与集成研发环境相关的工具平台也在这段时间周期内如雨后春笋涌现出来：
随着近年不断发展的支付宝小程序、函数服务、中后台、智能化等前端技术的发展，在不同前端技术方向，都涌现出了通过集成研发环境的方式来整体研发过程中的工程工具服务，来提升整体研发的效率和体验。
起因分析
面对当前的趋势，为了更好地到 IDE 共建的研发落地思路，我们从 业务侧、技术侧两个角度来分析内在的起因。
业务侧
业务链路承接: 针对许多与研发强相关相关的如小程序、函数计算等场景，技术产品链路背后都有一个完整技术、产品体系需要一个承接主体，来完成对产品功能、信息、能力的传达。通过日常研发人员熟悉的 IDE 形式，将各个研发体系中的关联功能进行集成，向用户透出。通过集成方案降低开始成本与门槛，提高品牌、产品的触达效率。
体验效率升级: 随着工程化的发展，代码研发模式也从较单一的编辑工具编辑延展到 终端命令、本地工具、线上研发平台 相互穿插交织的方式。而 IDE 刚好能作为研发编辑工具与研发工具服务的结合平台，提高工具、服务之间的串联效率，提升链路的完成性和交互体验，最终完成研发链路的效率升级。
业务侧来看，可以看出两个观点其实相辅相成，正式由于通过 IDE 这种形式，能更好地完成业务链路和产品细节的整合，将复杂度和衔接成本降低，同时能提供良好的流程体验，更有利于业务场景的落地和推广。
技术侧
一项技术产品站上舞台往往是技术的底层设施的完善程度有一个里程碑式的提升。随着当前线上线下领域中底层技术的成熟与开放，为搭建 IDE 相关的技术工具、平台降低了门槛，这里举两个代表性的例子：
随着在容器、本地、基础依赖技术体系的不断成熟和得到开发者的认可，搭建 IDE 集成环境的效率和门槛进一步提升和降低，促进 IDE 在不同研发场景中的落地和发展。
分析小结
由整体行业的发展我们可以窥见，当下一体化的研发模式会逐渐随着业务上的诉求以及 技术上的成熟的趋势 ，通过 IDE 集成研发环境整合的方式在各个业务场景上铺开。
而回过头来，当下研发模式面临的问题和痛点是什么，是我们 IDE 共建项目的目标和出发点。
起因与目标
起因
一方面当下的工程体系、平台很多更关注于线上资源的编译构建、审核检查以及上线发布流程，而对于研发态的干预和定制能力有限。
代码研发过程往往与上线过程存在一定的隔阂。面向未来的理想全链路工程体系，可以将研发态的能力与服务也进行链路整合，完成从仓库创建到仓库资源发布的整合，最大化的集成研发过程中的能力与服务，提升研发效率。
另一方面，由前文提到，当下其实在公司内外部的很多产品中，都有各自自研或者基于开源项目进行 IDE 能力研发与定制，同一个功能点，例如基于 monaco-editor 代码语言提示等功能在现有的产品中的实现都大同小异，而这块相同的功能的投入每个平台都需要投入一定的精力，存在 重复建设的问题，而向更深层的探索理解和研发投入也受到限制。
目标
从当前的现状出发，引申出共建 IDE 项目的目标:
>面向经济体业务研发场景，打造云端与本地端一致，内外统一的 IDE 通用底层能力，支撑研发场景的 IDE 能力的快速搭建与集成
基于 IDE 底层能力，业务场景研发平台能快速地完成 IDE 能力的搭建或集成，同时通过底层的插件体系能力完成业务研发链路的能力的定制集成。
通过通用统一体系的建设，将重复投入的精力进行收敛，让更多的精力基于统一的研发底层投入到更深层次能力的建设和创新中去，形成技术生态的良性循环，在内外部各个系统之间形成扭转，让技术产出发挥最大化的价值。
方案与策略
项目定位
IDE 的本意是集成开发环境。从狭义上理解就是我们日常研发的代码开发工具，例如以 VSCode 举例，集成研发环境中包含的代码编辑器 Editor 、资源查看 Explorer、终端 Terminal`等相关的功能模块。
当前实际业务场景的诉求上所期望的是作为集成开发环境角色，研发平台需要支撑的除基本编辑研发能力相关之外，同样需要将用户在研发流程中所用到工具、服务都进行串联和集成，才能让研发流程在一个环境或者体系中运转，发挥工具、服务的最大效应和价值。
所以 IDE 共建底层项目需要做的，一方面往技术底层走，需要在常规的 IDE 基础模块能力方面提供完整的通用体系能力。另一方面往上层走，面向业务场景提供 IDE 服务集成解决方案，方便快速完成业务场景中研发工具、服务的整合与落地。
基础能力
在开展上层建筑业务价值之前，需要将最底层基础的基本能力进行夯实，我们将现有传统 IDE 领域中所关联的一些模块能力进行分成划分：
目前大致化为三个部分。
基础能力层：有构建 IDE 功能的底层依赖模块组成
- 例如基于布局能力来完成整个 IDE 应用界面的搭建；
- 基于最底层的文件服务模块完成目录浏览的数据读取支持和进行目录和文件的浏览查看，同时也向文档Model 文档定制模块提供相应的文件监听能力，用于前台编辑文本的状态同步；
封装能力层：这一层与基础能力层一样，也是属于共建底层能力的一部分。而这层则是着重通过基础能力层提供的能力，来实现在 IDE 领域相关的一些核心模块。
- 例如核心编辑器模块的运行需要依赖底层的文件服务、通信能力、命令机制、快捷键绑定等一系列的模块；
- 而在终端模块的协议适配过程中则需要通信能力提供底层的协议适配能力；
支撑服务层：除了 IDE 集成需要的底层模块能力，这层主要是针对 IDE 的运行态所需要具备的一些线上服务。
- 例如通过插件市场进行插件的下载安装；
- 通过容器服务来提供云端版本 IDE 的运行时环境等；
目前共建项目现阶段主要的精力就是投入到基础 IDE 底层模块及支撑服务的研发中，保证功能在符合现有落地的场景下，达到现有 IDE 体系一线水平能力。
业务能力
在业务能力话题中，前文提到 IDE 的核心价值其实对业务场景研发链路的整合，完成研发效率的提升，在现有的环境中确实有非常多这样的场景：
在业务集成能力的采取的策略方案上，因为我们期望想实现内部与外部、本地端与云端的同步一致，我们期望通过插件的方式来解耦打包集成能力，形成技术生态服务业务。
以微信小程序、支付宝小程序举例，相比现有VSCode体系中的插件主要是针对研发流程中的编辑体验增强，业务上的场景往往是研发链路界面、入口的集成来实现链路的串联。
所以在目前设计的插件体系中，在兼容 VSCode 插件生态 的基础上，扩展出插件对UI 组件定制的逻辑，针对插件中的业务逻辑，底层提供提供可选的浏览器 WebWorker 环境与 Node 环境 运行时环境，并在运行环境时中注入底层能力中一些响应 API ，提供业务逻辑运行时与 UI 组件的双向调用链路。完成 UI 组件定制与业务逻辑的响应。
在插件中可以在逻辑服务侧进行对界面中注册的通过不同组件注册进行 API 调用，反馈到组件的展示上，同时在浏览器中不同的 UI 组件也能对插件服务逻辑提供出来的服务接口逻辑进行调用，分离逻辑执行，提高整体的业务逻辑执行性能和稳定性。
在从业务场景中去碰撞汲取经验、沉淀技术的同时，我们也对接下来的发展有既定的计划。
下一步
我们期望在随着底层的成熟和稳定，在明年的时间点能在下一步进行更多场景的尝试。
一方面进行外部开源开放，用户也可以借助底层能力来做符合自身日常工作的集成研发解决方案，并也亲身参与到底层能力的改造优化中。
另一方面在阿里云上基于KAITIAN-FRAMEWORK云上也会提供开发者工作台串联云上研发流程的产品，来集成掉开发调试与部署发布全链路流程，提升整体云上服务的研发体验，提供未来研发模式的探索体验。
我们期望能通过 IDE 项目，凝聚合力，形成生态环境，借助集体的力量，一步一个脚印迭代完成从轻量级研发到主要研发模式的逐步替换，形成未来日常工作的基础设施。
以上就是我们在第十四届D2前端技术论坛中分享的所有内容。
PPT链接。
关注「Alibaba F2E」
把握阿里巴巴前端新动向
