6

流程即代码:低代码 & 云研发 IDE —— Uncode

 3 years ago
source link: https://www.phodal.com/blog/process-as-code-low-code-ide-uncode/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
流程即代码:低代码 & 云研发 IDE —— Uncode

流程即代码:低代码 & 云研发 IDE —— Uncode

Posted by: Phodal Huang March 28, 2021, 8:30 p.m.

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

第一次声明:这是一个概念性 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 的三种类型:flowmodelui,对应于流设计、模型设计和 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,便能完成这一系列的自动化过程操作。

最后,我们还是回到代码上:https://github.com/inherd/uncode/

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

在驱动方式上,由四种模式构成:

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

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

考虑到这是底层开发 + 系统编程,我们:

  1. 使用 Rust 来作为主要开发语言
  2. 在 UI 展示上,暂时使用 Tauri(WebView 容器) + React 来展示需求(本地看板)与设计(建模等)。
  3. 使用 TypeScript 作为 UI 部分开发语言
  4. 使用 RPC 作为与多个 DSL 的通信协议

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

FAQ 及其它

代码:https://github.com/inherd/uncode/

vs Intellij IDEA or VSCode / Theia

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

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

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK