流程即代码：云研发 IDE —— Uncode

在先前的一系列《云研发：研发即代码》文章里，咱们介绍了软件工程的代码化闭环。同时，在《Water：云研发架构模式》介绍了设计这样的开发环境里，咱们所须要的一些模式。今天呢，做为这一系列的落地实践，咱们将介绍云研发 IDE的设计思想，以及如何实现，固然还有一点儿早期代码：github.com/inherd/unco…。

第一次声明：这是一个概念性 IDE 的设计，暂不适合任何生产环境。

在开始真正阅读以前呢，为了能更好地让你们理解，咱们要回顾一下软件工程行业：

• DevOps 理念在国内的软件行业有了长足的发展，在包括传统企业（银行、制造业）在内的公司里已经普遍接受，并进行了大规模推广。
• 云原生技术已经成为市场的主流趋势。云迁移与遗留系统上云是市场的一大热门话题。
• 中台方法论在实践上还缺乏真正的成功案例。
• 低代码/无代码平台逐渐成为新的建设目标。
• 云开发有了愈来愈多的中小规模应用案例。
• AI 生成代码正在被小范围验证。

从整个行业而言，人们的关注点一直是如何提高技术生产力？ 如今技术到了一个新的阶段了，而需求的转换大大限制了人们的开发速度。因而不管咱们的 DevOps 和云开发实施得再好，也会陷入需求与技术隔离的瓶颈。这就是为何咱们须要云研发 理论体系 :)，经过代码化的方式，一站式解决需求到设计，再到代码的问题。

对于云研发理论来讲，我已经设计好了理论基础、软件架构、开发模式，而且对其中的一系列东西进行了验证，如：文档代码化、需求代码化、代码的代码化 等。

咱们须要一个容器，把这些内容、模式、代码整合到一块儿，这就是 Uncode，一个概念性的云研发 IDE。

Uncode，一个云研发 IDE

Uncode 是一个面向云研发时代设计的下一代概念性 IDE。特性：

• 流程化为领域语言。Process as code
• 一切皆 DSL。万物代码化
• 填空式/选择式编程。
• 开发环境即流程。

简单来讲，你能够在这个 IDE 上完成：需求的编写，转换需求为设计，设计关联代码，禅模式编程，开发完便可上线。

与之相对比的是，传统的一站式 DevOps 门户，尽管你能够经过跳转来完成，可是没法相互关联和设计。与之相近的是 GitOps，即将应用系统的声明性基础架构和应用程序存放在 Git 版本库中。可是它们都不闭环，也不完整。

云研发 IDE 模式：流程即领域语言

回到软件开发上，咱们的软件开发需求始于一个大特性或者史诗故事，这些故事会转换为一个 feature，如 Cucumber 中的：

# author: Phodal HUANG
# status: doing
# language: zh-CN
功能: 第一个用户故事

  场景打开 Uncode
  假如我在 Terminal 工具里
  当输入 uncode
  那么则能在 Uncode IDE 里打开当前项目
复制代码

需求设计人员在这一步以前，将需求转换为了故事，故事与特性之间的关系记录在这个 feature 中。开发人员从 IDE 中看到需求，标记了对应的状态 status，就能够进入代码的设计阶段。

在设计这个阶段，咱们先设计了 design 的三种类型：flow、model、ui，对应于流设计、模型设计和 UI 设计。而咱们要在 Uncode 中实现的部分即是需求与模型、流和 UI 的绑定。围绕模型，咱们还得构造统一的领域语言，用于自动化关联接口与设计。从模式上来讲，这个和无代码/低代码的开发是类似的。

惟一不一样的是描述方式。使用领域特定语言来描述内容，咱们才能对系统进行合理地重构。

云研发 IDE 模式：一切皆文件

Linux/Unix下的哲学核心思想是『一切皆文件』。

在现今的开发环境之下，咱们在看板上挑选卡片，又或者是经过低代码编辑器生成，使用的存储介质都是数据库。而数据库这些东西并不存在于开发环境中，而是放置于远程服务器上。这就形成了另一个痛点，没法简单反向关联、需求与代码隔离等等。

因而，做为云研发 IDE 的第二个模式，将全部的内容使用文件保存，而且使用版本管理工具（如 Git）进行管理。如咱们的需求以相似于代码的形势存储在数据库中，能够实现如下特性：

• “不可伪造”
• “全程留痕”
• “能够追溯”
• “公开透明”
• “集体维护”

没错，这就是一个区块链系统。一旦需求发生了变化 ，你能够即刻感知到。不过，一旦你的代码与模型不相符合，你的代码就没法提交，或者模型被自动修改 :(。

云研发 IDE 模式：开发环境即流程

做为一个集成开发环境，现有的 一站式 DevOps 软件研发管理协做平台 都应该只被看成管理和展现用途。而从设计自己来讲，一个 Dashboard 和一个开源工具，自己就分工。

咱们在代码库上有了需求，那么咱们能够借助于 IDE：

1. 将需求以看板的形式在本地从新可视化出来。
2. 将设计领域的语言在本地可视化出来，并将之与代码进行关联。
3. 高亮须要全部修改的代码块。如 Controller、View 等。
4. 将模型的修改反向关联到设计上，以实时追踪设计的正确性。

咱们还能够作一些不那么正确的事情 ，如锁定开发人员的修改范围。

云研发 IDE 模式：填空式/选择式编程

对于软件架构师来讲，人们常常有这么一些痛点：

• 面对的是缺少经验的开发者，难以快速地推动系统的开发。
• 开发者缺少对系统的了解，在错误的地方修改错误的代码。

所以，回到 TypeFlow 的观点上，咱们既然已经设计好了模型，设计好了输入和输出，那么咱们必定能生成中间的方法及其返回值，并为其设计一个 mock 的对象。如：

@RequestMapping("/")
String home() {
		return "Hello, World!"
}
复制代码

这种模式对于业务应用开发来讲，很是易于实现 —— 生成绑定过程当中的各种函数等等。

选择式编程。而一旦咱们在组织内的全部代码都被索引以外，咱们有能力经过识别输入和输出，以及对应的方法名，就能在 IDE 中推荐对应的方法让你选择。

云研发 IDE 基础要素

就这么一看，咱们只须要搞好 IDE 的事情便可。然而， 并不是如此，咱们还要作的事情还有一些：

1. 开发即部署。即 local dev 即是 dev server，可直接接入现有的系统。
2. 万物即 DSL。具有必定等级的程序语言设计能力。
3. API 的 API。即将现有的内部、外部 API 进行抽象化设计，以提供快速可用的 API。

开发即部署 —— 云开发环境

从开发层面来看，咱们一直在往复地浪费本地环境和线上开发环境，与此同时还有对应的测试运行时间、构建时间等。咱们须要一个于云开发环境的机制。

加速联调、测试过程。当咱们的本地环境上云以后，一旦须要与其它系统对接时，全部的开发、测试效率将大大提高。譬如说，咱们的接口须要多提供一个参数，传统模式以后，咱们要在本地运行，再经过流水线构建和部署。而如今，再也不须要这个过程了，只须要配置好 Gateway，轻轻松松进行开发。

加速环境搭建。咱们再也不须要在本地配置开发环境，只须要 1-click 就能够在本地 IDE 里直接调试。

市面上已经有一个勉强配合的概念：Nocalhost

抽象的抽象：DSL

对于需求、设计、开发、测试等的抽象，一直是我在去年研究的重点，它包含了：

• 需求的抽象
• 设计化为抽象
  • 架构描述语言
  • 统一建模语言
• 版本管理抽象
• 构建工具抽象

即将这一系列的步骤转换为领域特定语言 —— 只有将流程、工具、行为进行抽象，咱们才得以优化整个系统。

胶水设计：API 的 API

软件开发是一项复杂的团队活动。在一个系统里，咱们要与大量的内、外部系统进行关联。而为了简化开发人员的负担，咱们须要提供一个新的 API 来将现有的 API 进行封装。

如在现有的模式之下，为了记录一个日志，咱们须要在依赖管理工具中引入对应的依赖，再添加至关的代码。而全部的 API 都是在更新的，这一系列应该将由 IDE 自己来完成。在这种模式之下，咱们只须要输入对应的 snippets，便能完成这一系列的自动化过程操做。

技术细节

最后，咱们仍是回到代码上：github.com/inherd/unco…

架构设计

我决定使用我设计的新架构设计套路来展现一上 Uncode IDE 的架构。因为不肯定性较大，现有的系统是一种介于单体与微架构 + 模块化的方式设计的，我想了想后来就称之为流体模式。一种在持续演进的过程当中，不断进行不可预料地拆分架构单元的模式。

在驱动方式上，由四种模式构成：

• 模块化。
• 管理和过滤器。主要进行领域特定语言的设计
• 搭档模式（sidecar）。将诸如语言解析等独立为进程，经过进程调用来实现跨平台
• 容器桥。将 UI 展现与逻辑相隔离，让 IDE 的大部分组件与 UI 无关。

同时系统的物理设计上，打算采用领域驱动的方式进行。

框架选型

考虑到这是底层开发 + 系统编程，咱们：

1. 使用 Rust 来做为主要开发语言
2. 在 UI 展现上，暂时使用 Tauri（WebView 容器） + React 来展现需求（本地看板）与设计（建模等）。
3. 使用 TypeScript 做为 UI 部分开发语言
4. 使用 RPC 做为与多个 DSL 的通讯协议
5. ……

依旧地，这个项目将继续在 Inherd 小组上开发~~。

FAQ 及其它

代码：github.com/inherd/unco…

vs Intellij IDEA or VSCode / Theia

并不是彻底竞争关系，编码这部分的功能，仍是这两货比较流行。Uncode 不会在前期造这方面的轮子，只是显式地集成它们，或者被集成。

Uncode 优先解决 DevOps 的本地化，将其融入开发的开发过程的问题。

其它

最后一次声明：这是一个概念性 IDE 的设计，暂不适合任何生产环境。