流程即代碼：雲研發、低代碼 IDE —— Uncode

我們需要一個容器，把這些內容、模式、代碼整合到一起，這就是 Uncode，一個概念性的雲研發 IDE。

Uncode，一個雲研發 IDE

簡單來說，你可以在這個 IDE 上完成：需求的編寫，轉換需求爲設計，設計關聯代碼，禪模式編程，開發完即可上線。

與之相對比的是，傳統的一站式 DevOps 門戶，儘管你可以通過跳轉來完成，但是無法相互關聯和設計。與之相近的是 GitOps，即將應用系統的聲明性基礎架構和應用程序存放在 Git 版本庫中。但是它們都不閉環，也不完整。

雲研發 IDE 模式：流程即領域語言

回到軟件開發上，我們的軟件開發需求始於一個大特性或者史詩故事，這些故事會轉換爲一個 feature，如 Cucumber 中的：

1# author: Phodal HUANG
2# status: doing
3# language: zh-CN
4功能: 第一個用戶故事
5場景打開 Uncode
6假如我在 Terminal 工具裏
7當輸入 uncode
8那麼則能在 Uncode IDE 裏打開當前項目
9

需求設計人員在這一步之前，將需求轉換爲了故事，故事與特性之間的關係記錄在這個 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 的對象。如：

1@RequestMapping("/")
2String home() {
3return "Hello, World!"
4}
5

這種模式對於業務應用開發來說，非常易於實現 —— 生成綁定過程中的各類函數等等。

選擇式編程。而一旦我們在組織內的所有代碼都被索引之外，我們有能力通過識別輸入和輸出，以及對應的方法名，就能在 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 的架構。由於不確定性較大，現有的系統是一種介於單體與微架構 + 模塊化的方式設計的，我想了想後來就稱之爲流體模式。一種在持續演進的過程中，不斷進行不可預料地拆分架構單元的模式。

在驅動方式上，由四種模式構成：

同時系統的物理設計上，打算採用領域驅動的方式進行。

框架選型

考慮到這是底層開發 + 系統編程，我們：

  1. 使用 Rust 來作爲主要開發語言

  2. 在 UI 展示上，暫時使用 Tauri（WebView 容器） + React 來展示需求（本地看板）與設計（建模等）。

  3. 使用 TypeScript 作爲 UI 部分開發語言

  4. 使用 RPC 作爲與多個 DSL 的通信協議

  5. ……

依舊地，這個項目將繼續在 Inherd 小組上開發~~。

FAQ 及其它

代碼：https://github.com/inherd/uncode/

vs Intellij IDEA or VSCode / Theia

並非完全競爭關係，編碼這部分的功能，還是這兩貨比較流行。Uncode 不會在前期造這方面的輪子，只是顯式地集成它們，或者被集成。

Uncode 優先解決 DevOps 的本地化，將其融入開發的開發過程的問題。

其它

最後一次聲明：這是一個概念性 IDE 的設計，暫不適合任何生產環境。 歡迎加入雲研發的微信研討羣。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/wG9WbxNvuZ7RLFxr6EdrqQ

猜你喜歡