随着近十多年来云计算的逐渐普及，各行各业都发生了变革。开发者们几乎每天都要使用的 IDE（Integrated Development Environment） 自然也不例外。因此，在线编辑器、Cloud IDE 应运而生。在线编辑器发展至今，已然成为了一个专门的领域。其复杂度在日益上升的同时，各式的需求也在不断增大。那我们在面对这类“庞然大物”的时候，是否还能一窥其核心，打造一款最小化的 Cloud IDE 呢？
在线编辑器（Cloud IDE） 的需求点
我们经常能听到一些与 Cloud IDE 非常类似的概念，如 Web IDE、远程开发等等。尤其是远程开发，在早期的时候，我们能够通过 SSH 这类方式直接连上远端机器，使用基于 TUI（Terminal User Interfaces）的代码编辑器如 GUN nano、Vim、Emacs 这些直接来修改服务器上的代码。
但不管从开发体验，还是配置门槛等方面来说，都远远不够。可以这么说，如果完成不了本地 IDE 大部分功能的话，在线编辑器（Cloud IDE）其实是不合格的。除此之外，在线编辑器（Cloud IDE）显然是需要发挥出“云”的优势，这才是它的立身之本。常见的一些关键点如：
- 在线编辑器，随时随地编码。这是它最基本也是最原始的需求。
- 高效，快速接入环境。环境本身在云端，得益于云端资源的弹性以及丰富性，高效计算的同时还能有大量预先配置好的环境可立即使用，免安装。
- 分享，降低协作门槛。云端环境下，同一套开发环境可以多人接入，使得共同协作开发成为了可能。
- 安全，隔离开发环境。开发者不仅能快速切换开发环境，每个环境及每份数据都是各自独立。且依托于网络安全不断地发展，安全性得到了保障。
但随着行业的发展，各种多元化的行业需求又对在线编辑器（Cloud IDE）提出了新的需求，如：
- 可控，可管理。过去，往往一些大体量的公司会对员工的设备进行统一安装和管理，后续升级维护的成本不低，且效率低下。软件行业也一样。而在线编辑器（Cloud IDE）自带的环境优势，会给这一方面带来极大的便利。但这同时又对在线编辑器（Cloud IDE）本身的提出了更高的要求。
- 多元化，可扩展，可定制。行业壮大后，往往会产生行业自身的一些特定开发内容和开发模式。甚至是一些特定领域，由于传统的 IDE 无法覆盖到每个专业领域，在线编辑器（Cloud IDE）借助自身的技术特点，可将扩展性充分发挥了出来。
- 集成化。也正因 Cloud IDE 依托于云，将整个研发流程的链路串起来就成了一件比较自然的事。
打造在线编辑器（Cloud IDE）所需的核心点
虽然要打造一款功能完善的在线编辑器内容比较多，但其基础结构还是能够被推演出来的，再利用扩展性的优势逐步实现各方面的需求。首先要感谢多年来容器技术的发展，让云端环境的构建极大地降低了门槛。再者开源社区的力量也是日益强大，各个领域几乎都能找到优秀的工具，极大地方便了开发者。剩下的主要工作就集中在满足上文提到的一些关键点的前提下，如何去打造这个轻量级 IDE 本身了。
首先是便携，开发者不仅仅能够在浏览器环境下，还需要能够在本地 IDE 上直接远程连接到开发环境。这就表明了在线编辑器（Cloud IDE）不仅是一个 Web IDE，也说明了 Cloud IDE 本身是一个分体式的 Client-Server（Frontend-Backend） 结构，且 Server 不直接依赖于 Client，可独立运行。而协作的需求，又预示着 Server 本身不仅是可以接入多种 Client，也是能同时接入多个 Client。多种 Client 又意味着，Server 与 Client 之间必须要定下某种协议，才能保证 Server 的最小化和独立性。尤其是 Client 存在平台差异性，有了这层协议，也就自然而然实现了跨平台。类似的，Server 和 Client 可以分体，就意味着可以分布式运行。而分布式又注定了各功能点能够一定程度上被独立运行，这也能充分发挥云的优势。
有了这些基调之后，剩下的似乎就是具体的功能点了。但在线编辑器（Cloud IDE）本身的灵活性需要这些功能点也都是最小化的，这样才能够最快速启动，最快速响应。于是，按需加载就成了另一块基石，而这里的按需加载还隐含了按需卸载。我们通常所使用的插件系统，如 VSCode 的插件系统，就是这方面的典型。有了插件之后，也同样意味着会有一定的配置文件，记录着 IDE 的各种状态，以便下次打开后恢复。 插件系统在加载方面的设计同样也要考虑到满足之前提到的分布式需求。
众多的插件，众多的功能点，也驱使着整个 IDE 有一套管理方案能够协调各方面的运行。那么消息系统是必不可少的。消息传递的方式和处理模型有许多，各有优缺点。但核心的消息体中，还是有些通用的必要元素。如消息发送者和接收者的唯一标识，用于定向传递消息。又如消息体唯一标识，用于区分消息本身，在此基础上可完成消息回调，消息依赖等一系列具体行为。再回到分布式的需求上来看，这些插件是可以分布式运行的，那消息处理方面自然也要有相应的设计，包括各方面同步也是要考虑进去的。
至此，我们已经梳理了整体上的基础结构，但如果仅仅是功能块的简单堆砌，依旧非常混乱。IDE 本身是有一些核心功能的，如代码编辑、智能提示、调试、命令行等等。纯粹利用插件系统的组合方式会显得缺乏重心和对插件的约束力。这些最基础的核心功能也是没有必要像插件那样分布式运行的，否则不但会影响性能，还会带来许多安全隐患。所以有选择地挑选核心功能作为一个最小化的内核以及对插件扩展能力的限制，会给 IDE 带来体验和安全上的保证。而之前提到的那些核心功能，开源社区都有着优秀的工具和方案。如微软提出的 LSP（Language Server Protocol）规范直接革命性地统一了 IDE 中针对具体编程语言方面的一些基础功能，诸如自动完成、跳转至定义、查找引用等。这又极大地降低了打造 IDE 的门槛。另外，IDE 毕竟是一款软件，Client 部分有着交互界面，好的交互方式是对功能的再一次包装，也是用户最直接的感受。因此这一方面也是 IDE 核心所不可缺少的。
总结
我们再次回顾一下在线编辑器（Cloud IDE）核心内容的时候可以发现，抛开运行环境之后，总的来说，只有两大块主题：内核与插件生态。
- 内核分别包含了 Server 和 Client 两部分，各部分拥有自己的核心功能和插件系统。插件系统的核心包含了加载管理与消息管理两大块。Client 需要额外关注交互内容。Server 需要额外处理分布式运行与多 Client 协作的相关内容。
- 插件生态就是对 IDE 功能的扩展了，甚至一些主要，但分体运行不影响使用的功能同样可以插件的形式去开发。配合上领域专业化的一些插件，也为 IDE 在各领域的定制化铺下了一条路。 虽然细节的内容依旧不少，但至少有了可以动手的方向。
