共计 8678 个字符，预计需要花费 22 分钟才能阅读完成。
简介： KAITIAN IDE 是如何支撑阿里内部各种研发场景的？
作者 | 上坡
在 19 年 5 月，由跨阿里巴巴经济体的 3 个前端团队组织在一起，经过一年的努力，产出了 IDE 的底层实现 - KAITIAN 框架。与此同时，借助 KAITIAN 底层能力，体系内、外的研发场景也陆陆续续建设起来。在 IDE 框架完成了一些业务实践之后，我们对 KAITIAN 带来的研发场景下的业务价值以及发展的方向也有了更多的思考。
冰山一角
在经济体体系内，许多研发体系、平台借助 KAITIAN 底层，通过 KAITIAN 插件等方式将零散的研发模式进行了统一，将原有研发工作中的研发态与部署态、本地端与线上端的流程进行集成，在面向流程更流畅、环境更统一的研发链路上提供了进一步更好的选择。
业务场景概览
通过研发平台的集成，KAITIAN 底层间接打通支撑了诸如 支付宝小程序、营销搭建、中后台、Node FaaS 等垂直场景的研发，同时针对更加通用的例如 代码审核、冲突合并 等场景，借助底层能力，在体验、效率上也较原有链路有一定程度的提升。
在基础研发体验上，我们也陆陆续续集成验证了 100+ 的 VSCode 生态 插件，在基础研发体验上得到基本保障。
在 KAITIAN 项目建设之初，我们希望能通过灵活的插件机制，在兼容 VSCode 生态的同时，能将经济体前端研发生态内不断在发展和孵化出来的研发工具、服务进行承载，有机的串联起来整个链路，发挥出各个工具、服务的最大作用、价值。
垂直场景研发
例如针对电商体系下的营销页面研发，将 D2C 能力平台 imgcook 进行结合，在双促中大幅提升页面的生产效率，通过 D2C 能力进行 70% 的代码编写工作，在编辑器中进行调整加工后，点击立马上线。相比之前的流程大幅提高生产效率。
在体系外，经过支付宝小程序研发同学的不懈努力，小程序开发者工具 也完整扎实地跑在的 KAITIAN 底层框架之上，同时借助 KAITIAN 两端一致的能力，也在短时间内完整孵化出来线上环境的 小程序在线开发平台。
通过将这些功能根据使用频率、重要优先级进行组合，让研发工具不只是编码工具，而是真正成为一个研发空间，让用户像飞机机长一样，快捷触达、操作各个研发功能，提升研发的连贯性，组成表现一致的研发上下文，形成统一的研发产品体验，最终达到提升研发效率。
同时将小程序研发中的 模拟器、调试器 等能力通过 KAITIAN 插件进行封装，实现本地平台与线上平台的同步一致。借助底层架构一致，这些研发工具服务，也已经在内外的各个 KAITIAN 底层平台上进行集成，定制出更符合各自团队的研发链路。
在阿里云上，阿里云云开发平台 也在紧锣密鼓进行建设和开展训练营，通过整合云上研发解决方案的方式，基于 KAITIAN 体系提供针对 serverless、iot 一站式研发模式。
体系沉淀
在支撑业务的同时，我们也将集成业务的过程中遇到的问题进行总结沉淀。例如针对 Web 场景下，集成依赖基础设施较多的情况，我们将 容器调度、资源策略、框架集成 等环节进行抽象集成，提供具备租户式创建 IDE 能力的 WebIDE 中台，通过租户申请，10 分钟之内提供一个可定制的 IDE 集成环境；同时针对插件研发，我们也逐步沉淀出研发 组件库、模板库、研发插件 等插件研发基础设施。
去年一年，随着 KAITIAN 底层技术的诞生，这块技术也随着业务场景不断在往前，一方面我们逐步触达到了项目设定到的表面上的具体目标，而针对共建业务深层次的问题，也逐渐浮现出来。
冰山之下
作为开发人员，IDE 就像工作中的最佳拍档，伴随着大部分工作时间。我们同样也希望 KAITIAN 体系能从底层能力角度做好这个角色。于是在业务不断发展的同时，我们也在不断思考目前体系中所要解决和面临的一些问题。
底层能力
目前 KAITIAN 底层从业务的集成角度来看待，可以作为一个前端采用 React、后端采用 NodeJS 技术的前后端的完整应用。在这样的集成方式架构下，一些在使用过程中的问题也随着业务上的实践逐渐凸显出来。
基础性能
KAITIAN 在最初构建的时候，选择了 React 来进行前端页面的开发，同时基于 mobx 来实现页面中的状态管理。那么在传统前端 SPA 遇到一些例如视图、节点更新，渲染执行效率的一些问题，在随着不断提升的用户数量的同时，也在 KAITIAN 上层平台中暴露出来。例如界面渲染中的拖拽场景，对于单边触发多边联动触发更新的场景，都是在当下界面渲染中正在不断优化的部分。
同时在研发流程中的语法提示服务、项目研发部署日志、远程终端等一些前后端关联的功能都需要前后端频繁的交互。在 KAITIAN 的底层实现中，在 web 环境下借助 websocket 协议、本地借助 socket 协议的方式进行前后端通信。那么在 web 网络通信的环节过程中，相比本地环境通信的能力差距，我们需要尽可能保证传输的高效率。例如如果当用户输入一个字母的时候，如果语法提示的信息多等了 1 秒才出现，整体的体感差别是比较大的。
对于上述两个点以及其他方向的底层性能打磨，一方面通过结合日常前端应用的性能优化策略进行验证优化，另一方面尝试采取更好的实现方式来达到更佳的体验效果。
前后端解耦
目前 KAITIAN 底层作为前后端完整应用集成方案，能快速地集成出一个 Web 版本或者 Electron 版本的前后端应用。这样对于一个工程研发平台快速集成 IDE 研发能力本身是个快速简便的解决方案。
但随着在业务的落地过程，对于一些弱环境依赖的轻量研发场景以及在后端能力上的实现有着自有后端体系的实现的场景仍存在模式优化的空间。例如 codesandbox 这类研发场景，对于文件的操作上，不需要对外部情况变更进行监听以及也不存在文件磁盘的读写，基本主要依靠数据库操作，但同时具备一些研发中例如语法提示的支撑能力。
这样的研发模式在 简便易用 与 能力完善 之间找到一个最佳平衡点，在一些特定场景中实现最佳研发体验。
对于这样的场景，目前 KAITIAN 底层也在逐步进行改造支持。在 KAITIAN 底层设计之初本身是通过 TS 来实现 面向 接口 Interface 编程，存在着软件依赖之间天然的抽象隔离，那么我们通过将模块实现之间，模块的前后端实现之间进行进一步抽象化，完成前后端、模块间的解耦。目前其中的部分模块已经单独服务到这类的研发场景中，接下来也会逐步整理产出在这个领域场景中最佳实践。
对于框架底层性能及其他能力来说，作为研发编码能力和体验的底层支撑，对底层模块的质量优化是一个长期优化、不断跟进、没有终点的过程。在业务演变的同时，紧贴业务的场景和用户的研发要求，以实际场景为目标，做好 IDE 底层体系能力的基础保障。
插件体系
在基础的框架能力之上，我们期望 KAITIAN 插件体系能作为未来研发模式的一艘航母，能具备承载目前和未来绝大多数的主流研发模式的能力。在插件机制实现之初，我们打通了 Node/WebWorker/UI 三个环境来最大化插件的拓展场景。在业务实践过程中，我们也发现在插件运行的不同角度下，也有着更深度的业务需求和发展空间。
API
针对当下研发 IDE 丰富完善的功能体验，以及面向整个阿里经济体体系下前端域纷繁复杂的研发工具、服务生态。在 KAITIAN 启动之初，我们就期望能在插件运行环境上下文中，能提供完善的插件 API 调用及基础能力。
一方面通过兼容 VSCode 体系下的插件 API 来实现对研发过程中基础研发体验能力的补齐，能一样拥有完整的 LSP 语言服务协议、DAP 调试适配协议等核心机制的完整实现，具备完善可扩展代码提示、断点调试等能力；在另一方面，我们还需要解决研发过程中全链路工具、服务的串联集成，串联整个项目的生命周期，借助在 KAITIAN 插件体系下拓展 WebWorker、UI 环境以及在环境中提供的能力，来实现体验更顺畅、自然的研发模式。
而看似完备的环境，在业务实践过程中，也存在着一些我们需要不断深化、完善的基础体系能力。
API 粒度控制
KAITIAN 最初始建设的一套兼容 VSCode API 的插件体系，在实际业务的 ” 摸爬滚打 ” 中，我们发现对于这块基础 API 的使用上，还需要在粒度上进一步地做分层。例如从原有 VSCode 相关 API 的角度出发，期望一方面降低原有在 VSCode 插件研发现有较高的门槛，另一方面在深度的能力上进一步提供更多的能力，满足、促进研发模式的孵化需求。
例如目前针对以往命令行 CLI 的工具，在 KAIIAN 插件中存在着的创建终端面板执行的场景，按照现有 VSCode 插件 API 的实现，需要经历 3 步：创建终端、发送终端命令、显示终端。实际发现很多用户会直接将这个常用操作封装成一个例如 Terminal.run 这样的方法来方便调用。在这个层面上，我们也在着手针对底层能力的一些合并调用、组合调用从更体系化地角度进行更适当粗力度的封装，这样用户可以在功能实现上，就能尽量降低底层功能细节的关注，提高研发效率，更专注到业务逻辑的开发上。
一方面是方法进一步的抽象封装，在另外一方面，例如在 VSCode 的 task 命令空间的插件 API 实现中，暴露给用户的 API 数量在一些场景中无法满足，但实际用户在一些命令任务执行时序节点需要一些更多信息的获取、传递。这块我们在这个场景下进行更细粒度的补充透出。
在原有的 VSCode 插件 API 的粒度和开放上我们通过粗细力度的完善，逐步优化 VSCode 能力体系插件的研发体验，帮助用户降低门槛，提效插件研发。
业务上下文
因为我们期望 KAITIAN 能在经济体横向范围内具备足够的通用性，所以在实践设计之初，业务层的内容其实更多期望在业务集成侧解决，底层实现完全的隔离。但是在实际业务集成的过程中，业务需要透传一些业务上下文的信息到插件的运行调用中，例如应用之间调用的 令牌信息、用户登录信息、当前研发应用信息、当前环境网络信息 等等。
在这样需求之初，集成方通过同样并行实现一个底层模块逻辑，平行的将集成侧的交互信息通过与底层实现一致的方式透出到插件环境中。这样的方式能解决当下业务上的问题，但在背后其实仍然存在着遗留的问题。
- 研发门槛 & 维护成本: 对于通过集成底层模块的方式来注入业务上下文，无论是门槛和集成方式都无法得到有力的保障，一方面集成侧的用户需要对底层框架模块实现有着一定程度的理解，这就对整体的集成门槛有一个不小的提升，另一方面对于底层不同的理解会产生不同的集成思路，具体到代码实现上的形式也变得不可控起来，对于后期的更新维护产生更多的成本。
- 依赖描述: 目前这些通过集成侧注入到运行上下文的业务信息，在一定层面上其实也形成了插件本身运行的依赖，通过 ” 非官方 ” 的注入方式，无法将这部分的插件依赖进行管理起来，那么则无法对插件依赖进行准确的描述。一个插件如果存在业务环境上下文的依赖，但同时无法进行的准确的描述，那么插件生态天然就多了一道屏障，无法形成互通体系。
在当下我们逐步开开始从集成侧角度，建立上层的 注入上下文 的实践层规范，提升集成侧的集成效率、体验，同时保障插件自身的环境依赖可描述，保障插件生态互通。
KAITIAN API 体系
在 KAITIAN 插件机制中，我们有参考小程序框架实现 UI 环境与 WebWorker、Node 环境的方法服务注册与远程调用能力，同时本身在 UI 与 WebWorker 环境中，我们也逐步在建设 KAITIAN 插件体系下 API 能力。
UI 环境代表的是 IDE 整个前台界面的运行环境。例如我们期望对于上下左右面板的控制、对于左右、底部 Tab 切换的控制以及对于自定义组件在不同插槽位置的注册渲染等能力，都需要依赖在底层能力通过插件 API 的方式进行透出，保障插件在 UI 界面上的控制场景需求。
同时我们期望 WebWorker 环境在能承接业务逻辑的同时，更能逐步在未来承担起目前在 Node 环境中的能力，降低对后端资源的消耗和依赖，目前对命令、语言、生命周期控制等基础能力的依赖，也逐步在 WebWorker 环境中进行建设和透出。
依托插件具体的运行环境，提供不同环境的 API 体系抽象，保障业务逻辑在插件环境中的承接。
UI
面向前端研发的 IDE 插件体系，我们期望能天然借助 React 组件能力进行对业务逻辑的表达。在这块 UI 组件领域中，看似对于前端来说非常熟悉的 React 体系，在业务实践过程中我们也逐步沉淀出一套适合插件 UI 环境的技术体系。
沙箱能力
在插件 UI 实现流程中，一方面由于前端 UI 实现的简易边界，没有限制，我们很容易通过样式、标签进行界面的组织，另一方面由于当下前端环境下丰富的类库、组件，开发者往往也会直接依赖一些开源组件来提升开发效率。简易的实现路径同时也容易产生 UI 组件之间相互影响。例如目前在实践过程中，我们发现往往会因为插件 UI 中因为引入 AntD 组件的方式有误，导致了对整体界面全局样式的污染。
目前我们也在逐步借助 WebComponent 能力进行对插件渲染进行一定的容器控制，建设渲染容器的沙箱机制。将插件注册的组件通过 ShadowDom 的方式进行控制，屏蔽掉对整体界面渲染影响。同时我们注意到原有 VSCode 插件中的 treeview 等组件布局的 序列化渲染 实现方式，也不断在放大数据化渲染的应用场景，通过提供官方的 UI 模板等实现形式，插件用户只需要进行对应的 UI 实现配置，在完成业务逻辑实现的同时，保障 UI 实现的稳定性。
在进一步，针对 JS 对环境的影响以及执行控制，目前也在参考现有社区的方案实现，逐步验证探索 Worker、Realm、QuickJS 等方案，在为插件开发者搭建一个自由发挥的舞台同时，建设一个坚固稳定的渲染环境。
物料体系
在 IDE 插件中的 UI 研发其实与日常开发后台页面没有实质的区别，对于中低复杂度的场景，在实践过程中我们发现如果让用户从原子的标签开始研发，一方面整体的实现过程需要较多基础研发成本，另一方面在最终实现效果上，可能也无法与上下环境中的主题、样式风格等基础 UI 元素保证一致。
可以从一定的角度上来理解，在 IDE 视角下的 UI 开发，可以类比于日常的中后台场景研发，具备一定的相似性。如何丰富用户的研发手段，建设高效的研发流程，同时保障最终效果的高质量输出可以类比在中后台场景中的实践。
我们在框架建设的中期，开始将 IDE 体系内的 UI 能力进行抽象收敛，产出 IDE 工具领域下的视觉组件，在底层框架复用的同时，也在插件 UI 环境下进行透出。通过这样的方式，在 IDE 插件研发的场景中，可以起到几个比较好的作用。
- 研发效率提升: 从封装的基础组件研发，能快速完成链路产品原型搭建，在非深度业务场景下，作为基础的研发体验保障之一
- 视觉一致性保障: 由于组件本身由 IDE 场景中孵化，在视觉语言表达上，会消除掉在使用其他 UI 能力时，不同 UI 体系导致的视觉展现混乱、干扰的情况，最终呈现到插件使用用户上的操作体感上有了保障基础
- 渲染稳定性: 实现 UI 组件对于目前插件同学来说容易，但是 UI 环境本身是一个较脆弱的环境，通过官方的组件实现，最大限度的降低因为业务逻辑导致的页面异常、甚至死循环卡死的情况
在借鉴组件体系建设之上，在业务实践过程中，我们仍然在思考如何再进一步降低研发成本的同时，保障运行环境的高效稳定，以及在深度定制下的最佳实践规范。
从基础组件向上的视角，用户在面临界面中的插槽面板的时候，基于基础组件实现高阶的 组合组件、布局模板，在能适配更多研发链路下的布局需求的同时，依然能享受到组件带来的基础体系保障。在上层封装中也逐步孵化出更多数据配置化的序列化 UI 实现，尽量控制在 UI 基础实现上的投入的同时，通过数据模型进行对 UI 的控制，进一步在投入与产出中找到 ” 黄金分割 ” 的方案。
从基础组件向下更深度的视角，我们也逐步建立起来提供给插件体系的主题变量 TOKEN 等更细粒度的物料体系，保证在一些复杂场景下的 UI 实现也依赖能最大限度与上下文环境保持一致体验。
插件生态
KAITIAN 除了底层框架实现，我们在设计之初期望通过官方提供的插件市场，来担当插件生态的中心承接点，作为基础源以点带面的进行插件的上架管理、安装更新、访问权限等基本服务功能支撑。对于不同上层业务方，可通过基于基础源的方式进行上层业务控制。
在这样的一个分层体系的业务实践过程中，通过基础插件市场提供的分组管理体系，能很好的解决掉业务间可能存在的干扰影响场景。但对于更深度的业务逻辑、能力扩展，需要借助其开放能力进行丰富。
例如在某一上层业务上层场景中，我们需要对用户使用的插件的版本进行灰度等管理应用，同时需要将插件的执行稳定性依托监控体系，进行稳定性的治理，匹配团队工程研发服务的质量标准。
在这样的场景下，目前我们也逐步将中心插件市场的能力进一步下沉和抽象，在保证基础插件研发链路的同时，进一步完善开放体系，将底层无直接关联的业务逻辑分摊到上层的实践平台中。一方面越清晰简化的底层越能最大化地保证底层核心的稳定性，具备服务更大场景的基本能力；另一方面对于上层各个业务场景，也能在无关联影响的实现环境下，最大化的保证上层逻辑细节，更好的服务上层的业务研发场景。
KAITIAN 插件体系这块作为 KAITIAN 体系中最重要的部分之一，我们也在陆陆续续从 插件研发 的视角下建设最优链路；在 稳定性 上逐步建设监控、容错的能力；在 性能上 寻求实现上的优化和突破。作为业务逻辑的基础容器，期望在稳定性、性能基础之上，结合业务链路上的催化，实现未来研发模式的基石。
业务上的探索与思考
对于当下 IDE 视角下的研发模式，我们概括为 通过 IDE 集成研发链路中的工具、服务以及流程，发挥链路整合优势的背景下，形成新的研发模式。在这样的主题下，在业务实践过程中也遇到一些比较典型的例子。
链路集成
场景示例
在电商营销活动研发场景中，搭建作为最核心的研发模式，日常研发主要进行对 UI 单元模块的研发，完成页面基础元素的生产。在这个体系下，我们将 编译预览、D2C 代码视觉稿还原能力、工程部署上线 等几个核心链路集成。用户从原有的在各个平台操作、代码逐行实现变成了基础 UI 机器生成，人工代码审核校验，一键上线的流程。在该场景的 UI 实现上大幅节省研发投入，在较大范围的用户上得到认可，也完成了包括双 11、双 12 等较多核心大促场景的验证。
在同样火热的 serverless 场景中，例如以阿里云上场景 云开发工作台 为例，目前云上环境中存在着浩如烟海的产品、服务。在一些场景下夸张的讲，代码只是应用上线 10 个步奏的其中 1 个步奏，从产品服务的了解，到技术方案的设计，到最终上线部署的流水线搭建，每个环节可能都是精力投入成本。
在这样痛点背景下，面向具体业务场景，设计整合解决方案，同时在 IDE 的上下文中借助插件实现的 部署面板、日志面板、调试验证面板 等功能模块，聚集云上的的能力，形成组合体系，让用户能快速、准确最优化地实现业务逻辑的同时，真正借助研发模式上的设计来提升研发体验，同时打通在业务上的赋能渠道。
用户价值
IDE 作为日常研发最高频的使用软件，在一定角度上也是用户要求最高的使用软件。从前文提到的场景中，表面上看是基于 IDE 的模式来建设研发链路，实际上其中一个本质是从用户视角下分析当下研发流程的痛点，借助 IDE 的方式来解决研发痛点。例如营销场景中的 UI 研发的低效率、支付宝小程序场景中的 能力复杂分散 以及在 serverless 场景中的 链路繁琐模糊。
对于新的 IDE 研发模式，本质我们需要做到在不断提升底层基础质量的同时，进一步挖掘用户的研发痛点，从研发工具、服务的整合做到 有效的 研发工具、服务的整合。在工具库丰富的同时，需要对每个问题庖丁解牛，用最合适的方式拿出最合适的工具来解决问题。例如在如今较为常见的多页面前端应用，往往在调试过程中提供一个预览路由页面，用户就从挨个页面链接拼写变成了直接点击，直接从维度上大幅降低用户在不同页面研发、调试之间的操作成本。
IDE 研发范式 - 全链路研发模式
在陆陆续续接入一些业务场景之后，我们思考在面临后续更多研发模式的接入，是否存在一定的 范式 。我们本身建立 IDE 项目，初心是期望借助 IDE 的体系，在内外研发能力的互通的背景下，来带来模式上的变化，提效研发。那么其实从 研发模式 出发，本质不是只有 编码环节、调试环节。研发模式需要关连整个研发链路来一同设计，从项目的初始化、项目的框架方案的设计，以及对项目应用框架针对性的工具、服务设计，以及到最终的应用部署上线，从一个项目的完整生命周期来设计，可能就是所谓的 研发范式。
从 项目框架选型、初始化流程、面向框架研发工具服务、上线部署流程，作为 IDE 研发模式的设计骨骼框架来设计和填充，让一个项目在研发用户手上借助 IDE 体系能力来完成，最终引导出研发模式上的量变到质变。
在当下在业务体系实践在场景上，除了从复杂的例如 Antd、Egg 体系应用研发到轻量的代码审核、冲突合并场景不断找到用户价值，借助 IDE 的能力重新设计、定义研发流程这样的用户角度。同样在团队视角下的数据体系，我们借助 IDE 的基础能力可以无死角地深入到用户的全操作流程中统计数据、信息，作为当选团队的框架方案、工具服务的分析改进基础。在技术落地上，我们期望通过多个位置的换位多角度思考，稳步营造、推进研发模式的变化。
仰望星空
KAITIAN 起源于经济体体系内多个前端团队的共同建设，目前除了基础的前端研发场景。在业务上层也在后端、客户端等研发场景中逐步验证，借助语言服务机制实现对 python、java、groovy、c++ 等语言的支撑。同时目前开源工作也在紧锣密鼓的进行中，期望在未来能将其中的一些最佳实践，通过开源的方式进行分享以及社区的验证和打磨。
