今天呢,作为这一系列的落地实践,我们将介绍云研发 IDE的设计思想,以及如何实现,当然还有一点儿早期代码:github.com/inherd/unco…。
第一次声明:这是一个概念性 IDE 的设计,暂不适合任何生产环境。
在开始真正阅读之前呢,为了能更好地让大家理解,我们要回顾一下软件工程行业:
从整个行业而言,人们的关注点一直是如何提升技术生产力? 现在技术到了一个新的阶段了,而需求的转换大大限制了人们的开发速度。于是无论我们的 DevOps 和云开发实施得再好,也会陷入需求与技术隔离的瓶颈。这就是为什么我们需要云研发 理论体系 :),通过代码化的方式,一站式解决需求到设计,再到代码的问题。
对于云研发理论来说,我已经设计好了理论基础、软件架构、开发模式,并且对其中的一系列东西进行了验证,如:文档代码化、需求代码化、代码的代码化 等。
我们需要一个容器,把这些内容、模式、代码整合到一起,这就是
Uncode,一个云研发 IDE
Uncode 是一个面向云研发时代设计的下一代概念性 IDE。特性:
简单来说,你可以在这个 IDE 上完成:需求的编写,转换需求为设计,设计关联代码,禅模式编程,开发完即可上线。
与之相对比的是,传统的一站式 DevOps 门户,尽管你可以通过跳转来完成,但是无法相互关联和设计。与之相近的是 GitOps,即将应用系统的声明性基础架构和应用程序存放在 Git 版本库中。但是它们都不闭环,也不完整。
回到软件开发上,我们的软件开发需求始于一个大特性或者史诗故事,这些故事会转换为一个 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 的绑定。围绕模型,我们还得构造统一的领域语言,用于自动化关联接口与设计。从模式上来说,这个和无代码/低代码的开发是相似的。
唯一不同的是描述方式。使用领域特定语言来描述内容,我们才能对系统进行合理地重构。
Linux/Unix下的哲学核心思想是『一切皆文件』。
在现今的开发环境之下,我们在看板上挑选卡片,又或者是通过低代码编辑器生成,使用的存储介质都是数据库。而数据库这些东西并不存在于开发环境中,而是放置于远程服务器上。这就造成了另外一个痛点,无法简单反向关联、需求与代码隔离等等。
于是,作为云研发 IDE 的第二个模式,将所有的内容使用文件保存,并且使用版本管理工具(如 Git)进行管理。如我们的需求以类似于代码的形势存储在数据库中,可以实现以下特性:
没错,这就是一个区块链系统。一旦需求发生了变化 ,你可以即刻感知到。不过,一旦你的代码与模型不相符合,你的代码就无法提交,或者模型被自动修改 :(。
作为一个集成开发环境,现有的 一站式 DevOps 软件研发管理协作平台 都应该只被当作管理和展示用途。而从设计本身来说,一个 Dashboard 和一个开源工具,本身就分工。
我们在代码库上有了需求,那么我们可以借助于 IDE:
我们还可以做一些不那么正确的事情 ,如锁定开发人员的修改范围。
对于软件架构师来说,人们经常有这么一些痛点:
因此,回到 TypeFlow 的观点上,我们既然已经设计好了模型,设计好了输入和输出,那么我们一定能生成中间的方法及其返回值,并为其设计一个 mock 的对象。如:
@RequestMapping("/") String home() { return "Hello, World!" }
这种模式对于业务应用开发来说,非常易于实现 —— 生成绑定过程中的各类函数等等。
选择式编程。而一旦我们在组织内的所有代码都被索引之外,我们有能力通过识别输入和输出,以及对应的方法名,就能在 IDE 中推荐对应的方法让你选择。
就这么一看,我们只需要搞好 IDE 的事情即可。然而, 并非如此,我们还要做的事情还有一些:
从开发层面来看,我们一直在往复地浪费本地环境和线上开发环境,与此同时还有对应的测试运行时间、构建时间等。我们需要一个于云开发环境的机制。
加速联调、测试过程。当我们的本地环境上云之后,一旦需要与其它系统对接时,所有的开发、测试效率将大大提升。譬如说,我们的接口需要多提供一个参数,传统模式之后,我们要在本地运行,再通过流水线构建和部署。而现在,不再需要这个过程了,只需要配置好 Gateway,轻轻松松进行开发。
加速环境搭建。我们不再需要在本地配置开发环境,只需要 1-click 就可以在本地 IDE 里直接调试。
市面上已经有一个勉强配合的概念:Nocalhost
对于需求、设计、开发、测试等的抽象,一直是我在去年研究的重点,它包含了:
需求的抽象
设计化为抽象
架构描述语言 统一建模语言
版本管理抽象
构建工具抽象
即将这一系列的步骤转换为领域特定语言 —— 只有将流程、工具、行为进行抽象,我们才得以优化整个系统。
软件开发是一项复杂的团队活动。在一个系统里,我们要与大量的内、外部系统进行关联。而为了简化开发人员的负担,我们需要提供一个新的 API 来将现有的 API 进行封装。
如在现有的模式之下,为了记录一个日志,我们需要在依赖管理工具中引入对应的依赖,再添加相当的代码。而所有的 API 都是在更新的,这一系列应该将由 IDE 本身来完成。在这种模式之下,我们只需要输入对应的 snippets,便能完成这一系列的自动化过程操作。
最后,我们还是回到代码上:github.com/inherd/unco…
我决定使用我设计的新架构设计套路来展示一上 Uncode IDE 的架构。由于不确定性较大,现有的系统是一种介于单体与微架构 + 模块化的方式设计的,我想了想后来就称之为流体模式。一种在持续演进的过程中,不断进行不可预料地拆分架构单元的模式。
在驱动方式上,由四种模式构成:
同时系统的物理设计上,打算采用领域驱动的方式进行。
考虑到这是底层开发 + 系统编程,我们:
使用 Rust 来作为主要开发语言
在 UI 展示上,暂时使用 Tauri(WebView 容器) + React 来展示需求(本地看板)与设计(建模等)。
使用 TypeScript 作为 UI 部分开发语言
使用 RPC 作为与多个 DSL 的通信协议
……
依旧地,这个项目将继续在 Inherd 小组上开发~~。
代码:github.com/inherd/unco…
并非完全竞争关系,编码这部分的功能,还是这两货比较流行。Uncode 不会在前期造这方面的轮子,只是显式地集成它们,或者被集成。
Uncode 优先解决 DevOps 的本地化,将其融入开发的开发过程的问题。
最后一次声明:这是一个概念性 IDE 的设计,暂不适合任何生产环境。
作者:Phodal
链接:https://juejin.cn/post/6959186488395300894
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。