Link Search Menu Expand Document
云研发：研发即代码

云研发 IDE：Uncode

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

目录

  1. 云研发 IDE 模式：流程即领域语言
  2. 云研发 IDE 模式：一切皆文件
  3. 云研发 IDE 模式：开发环境即流程
  4. 云研发 IDE 模式：填空式/选择式编程
  5. 云研发 IDE 基础要素
    1. 开发即部署 —— 云开发环境
    2. 抽象的抽象：DSL
  6. 胶水设计：API 的 API

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，便能完成这一系列的自动化过程操作。