在先前的一系列《云研發(fā)：研發(fā)即代碼》文章里，我們介紹了軟件工程的代碼化閉環(huán)。同時，在《Water：云研發(fā)架構(gòu)模式》介紹了設(shè)計這樣的開發(fā)環(huán)境里，我們所需要的一些模式。今天呢，作為這一系列的落地實踐，我們將介紹云研發(fā) IDE的設(shè)計思想，以及如何實現(xiàn)，當然還有一點兒早期代碼：https://Github.com/inherd/uncode。

第一次聲明：這是一個概念性 IDE 的設(shè)計，暫不適合任何生產(chǎn)環(huán)境。

在開始真正閱讀之前呢，為了能更好地讓大家理解，我們要回顧一下軟件工程行業(yè)：

• DevOps 理念在國內(nèi)的軟件行業(yè)有了長足的發(fā)展，在包括傳統(tǒng)企業(yè)（銀行、制造業(yè)）在內(nèi)的公司里已經(jīng)廣泛接受，并進行了大規(guī)模推廣。

• 云原生技術(shù)已經(jīng)成為市場的主流趨勢。云遷移與遺留系統(tǒng)上云是市場的一大熱門話題。

• 中臺方法論在實踐上還缺少真正的成功案例。

• 低代碼/無代碼平臺逐漸成為新的建設(shè)目標。

• 云開發(fā)有了越來越多的中小規(guī)模應(yīng)用案例。

• AI 代碼生成正在被小范圍驗證。

從整個行業(yè)而言，人們的關(guān)注點一直是如何提升技術(shù)生產(chǎn)力？現(xiàn)在技術(shù)到了一個新的階段了，而需求的轉(zhuǎn)換大大限制了人們的開發(fā)速度。于是無論我們的 DevOps 和云開發(fā)實施得再好，也會陷入需求與技術(shù)隔離的瓶頸。這就是為什么我們需要云研發(fā) 理論體系 :)，通過代碼化的方式，一站式解決需求到設(shè)計，再到代碼的問題。

對于云研發(fā)理論來說，我已經(jīng)設(shè)計好了理論基礎(chǔ)、軟件架構(gòu)、開發(fā)模式，并且對其中的一系列東西進行了驗證，如：文檔代碼化、需求代碼化、代碼的代碼化 等。

我們需要一個容器，把這些內(nèi)容、模式、代碼整合到一起，這就是 Uncode，一個概念性的云研發(fā) IDE。

Uncode，一個云研發(fā) IDE

Uncode 是一個面向云研發(fā)時代設(shè)計的下一代概念性 IDE。特性：

• 流程化為領(lǐng)域語言。Process as code

• 一切皆 DSL。萬物代碼化

• 開發(fā)環(huán)境即流程。

簡單來說，你可以在這個 IDE 上完成：需求的編寫，轉(zhuǎn)換需求為設(shè)計，設(shè)計關(guān)聯(lián)代碼，禪模式編程，開發(fā)完即可上線。

與之相對比的是，傳統(tǒng)的一站式 DevOps 門戶，盡管你可以通過跳轉(zhuǎn)來完成，但是無法相互關(guān)聯(lián)和設(shè)計。與之相近的是 GitOps，即將應(yīng)用系統(tǒng)的聲明性基礎(chǔ)架構(gòu)和應(yīng)用程序存放在 Git 版本庫中。但是它們都不閉環(huán)，也不完整。

云研發(fā) IDE 模式：流程即領(lǐng)域語言

回到軟件開發(fā)上，我們的軟件開發(fā)需求始于一個大特性或者史詩故事，這些故事會轉(zhuǎn)換為一個 feature，如 Cucumber 中的：

1. # author: Phodal HUANG

2. # status: doing

3. # language: zh-CN

4. 功能: 第一個用戶故事

5. 場景打開 Uncode

6. 假如我在 Terminal工具里

7. 當輸入 uncode

8. 那么則能在 UncodeIDE 里打開當前項目

需求設(shè)計人員在這一步之前，將需求轉(zhuǎn)換為了故事，故事與特性之間的關(guān)系記錄在這個 feature中。開發(fā)人員從 IDE 中看到需求，標記了對應(yīng)的狀態(tài)status，就可以進入代碼的設(shè)計階段。

在設(shè)計這個階段，我們先設(shè)計了 design的三種類型：flow、model、ui，對應(yīng)于流設(shè)計、模型設(shè)計和 UI 設(shè)計。而我們要在 Uncode 中實現(xiàn)的部分便是需求與模型、流和 UI 的綁定。圍繞模型，我們還得構(gòu)造統(tǒng)一的領(lǐng)域語言，用于自動化關(guān)聯(lián)接口與設(shè)計。從模式上來說，這個和無代碼/低代碼的開發(fā)是相似的。

唯一不同的是描述方式。使用領(lǐng)域特定語言來描述內(nèi)容，我們才能對系統(tǒng)進行合理地重構(gòu)。

云研發(fā) IDE 模式：一切皆文件

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

在現(xiàn)今的開發(fā)環(huán)境之下，我們在看板上挑選卡片，又或者是通過低代碼編輯器生成，使用的存儲介質(zhì)都是數(shù)據(jù)庫。而數(shù)據(jù)庫這些東西并不存在于開發(fā)環(huán)境中，而是放置于遠程服務(wù)器上。這就造成了另外一個痛點，無法簡單反向關(guān)聯(lián)、需求與代碼隔離等等。

于是，作為云研發(fā) IDE 的第二個模式，將所有的內(nèi)容使用文件保存，并且使用版本管理工具（如 Git）進行管理。如我們的需求以類似于代碼的形勢存儲在數(shù)據(jù)庫中，可以實現(xiàn)以下特性：

• “不可偽造”

• “全程留痕”

• “可以追溯”

• “公開透明”

• “集體維護”

沒錯，這就是一個區(qū)塊鏈系統(tǒng)。一旦需求發(fā)生了變化 ，你可以即刻感知到。不過，一旦你的代碼與模型不相符合，你的代碼就無法提交，或者模型被自動修改 :(。

云研發(fā) IDE 模式：開發(fā)環(huán)境即流程

作為一個集成開發(fā)環(huán)境，現(xiàn)有的 一站式 DevOps 軟件研發(fā)管理協(xié)作平臺都應(yīng)該只被當作管理和展示用途。而從設(shè)計本身來說，一個 Dashboard 和一個開源工具，本身就分工。

我們在代碼庫上有了需求，那么我們可以借助于 IDE：

1. 將需求以看板的形式在本地重新可視化出來。

2. 將設(shè)計領(lǐng)域的語言在本地可視化出來，并將之與代碼進行關(guān)聯(lián)。

3. 高亮需要所有修改的代碼塊。如 Controller、View 等。

4. 將模型的修改反向關(guān)聯(lián)到設(shè)計上，以實時追蹤設(shè)計的正確性。

我們還可以做一些不那么正確的事情 ，如鎖定開發(fā)人員的修改范圍。

云研發(fā) IDE 模式：填空式/選擇式編程

對于軟件架構(gòu)師來說，人們經(jīng)常有這么一些痛點：

• 面對的是缺乏經(jīng)驗的開發(fā)者，難以快速地推進系統(tǒng)的開發(fā)。

• 開發(fā)者缺乏對系統(tǒng)的了解，在錯誤的地方修改錯誤的代碼。

因此，回到 TypeFlow 的觀點上，我們既然已經(jīng)設(shè)計好了模型，設(shè)計好了輸入和輸出，那么我們一定能生成中間的方法及其返回值，并為其設(shè)計一個 mock 的對象。如：

1. @RequestMapping("/")

2. Stringhome {

3. return"Hello, World!"

4. }

這種模式對于業(yè)務(wù)應(yīng)用開發(fā)來說，非常易于實現(xiàn) —— 生成綁定過程中的各類函數(shù)等等。

選擇式編程。而一旦我們在組織內(nèi)的所有代碼都被索引之外，我們有能力通過識別輸入和輸出，以及對應(yīng)的方法名，就能在 IDE 中推薦對應(yīng)的方法讓你選擇。

云研發(fā) IDE 基礎(chǔ)要素

就這么一看，我們只需要搞好 IDE 的事情即可。然而， 并非如此，我們還要做的事情還有一些：

1. 開發(fā)即部署。即 local dev 便是 dev server，可直接接入現(xiàn)有的系統(tǒng)。

2. 萬物即 DSL。具備一定等級的程序語言設(shè)計能力。

3. API 的 API。即將現(xiàn)有的內(nèi)部、外部 API 進行抽象化設(shè)計，以提供快速可用的 API。

開發(fā)即部署 —— 云開發(fā)環(huán)境

從開發(fā)層面來看，我們一直在往復地浪費本地環(huán)境和線上開發(fā)環(huán)境，與此同時還有對應(yīng)的測試運行時間、構(gòu)建時間等。我們需要一個于云開發(fā)環(huán)境的機制。

加速聯(lián)調(diào)、測試過程。當我們的本地環(huán)境上云之后，一旦需要與其它系統(tǒng)對接時，所有的開發(fā)、測試效率將大大提升。譬如說，我們的接口需要多提供一個參數(shù)，傳統(tǒng)模式之后，我們要在本地運行，再通過流水線構(gòu)建和部署。而現(xiàn)在，不再需要這個過程了，只需要配置好 Gateway，輕輕松松進行開發(fā)。

加速環(huán)境搭建。我們不再需要在本地配置開發(fā)環(huán)境，只需要 1-click 就可以在本地 IDE 里直接調(diào)試。

市面上已經(jīng)有一個勉強配合的概念：Nocalhost

抽象的抽象：DSL

對于需求、設(shè)計、開發(fā)、測試等的抽象，一直是我在去年研究的重點，它包含了：

• 需求的抽象

• 設(shè)計化為抽象

• 架構(gòu)描述語言

• 統(tǒng)一建模語言

• 版本管理抽象

• 構(gòu)建工具抽象

即將這一系列的步驟轉(zhuǎn)換為領(lǐng)域特定語言 —— 只有將流程、工具、行為進行抽象，我們才得以優(yōu)化整個系統(tǒng)。

膠水設(shè)計：API 的 API

軟件開發(fā)是一項復雜的團隊活動。在一個系統(tǒng)里，我們要與大量的內(nèi)、外部系統(tǒng)進行關(guān)聯(lián)。而為了簡化開發(fā)人員的負擔，我們需要提供一個新的 API 來將現(xiàn)有的 API 進行封裝。

如在現(xiàn)有的模式之下，為了記錄一個日志，我們需要在依賴管理工具中引入對應(yīng)的依賴，再添加相當?shù)拇a。而所有的 API 都是在更新的，這一系列應(yīng)該將由 IDE 本身來完成。在這種模式之下，我們只需要輸入對應(yīng)的 snippets，便能完成這一系列的自動化過程操作。

技術(shù)細節(jié)

最后，我們還是回到代碼上：https://github.com/inherd/uncode/

架構(gòu)設(shè)計

我決定使用我設(shè)計的新架構(gòu)設(shè)計套路來展示一上 Uncode IDE 的架構(gòu)。由于不確定性較大，現(xiàn)有的系統(tǒng)是一種介于單體與微架構(gòu) 模塊化的方式設(shè)計的，我想了想后來就稱之為流體模式。一種在持續(xù)演進的過程中，不斷進行不可預料地拆分架構(gòu)單元的模式。

在驅(qū)動方式上，由四種模式構(gòu)成：

• 模塊化。

• 管理和過濾器。主要進行領(lǐng)域特定語言的設(shè)計

• 搭檔模式（sidecar）。將諸如語言解析等獨立為進程，通過進程調(diào)用來實現(xiàn)跨平臺

• 容器橋。將 UI 展示與邏輯相隔離，讓 IDE 的大部分組件與 UI 無關(guān)。

同時系統(tǒng)的物理設(shè)計上，打算采用領(lǐng)域驅(qū)動的方式進行。

框架選型

考慮到這是底層開發(fā) 系統(tǒng)編程，我們：

1. 使用 Rust 來作為主要開發(fā)語言

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

3. 使用 TypeScript 作為 UI 部分開發(fā)語言

4. 使用 RPC 作為與多個 DSL 的通信協(xié)議

5. ……

依舊地，這個項目將繼續(xù)在 Inherd 小組上開發(fā)~~。

FAQ 及其它

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

vs Intellij IDEA or VSCode / Theia

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

Uncode 優(yōu)先解決 DevOps 的本地化，將其融入開發(fā)的開發(fā)過程的問題。

其它

最后一次聲明：這是一個概念性 IDE 的設(shè)計，暫不適合任何生產(chǎn)環(huán)境。 歡迎加入云研發(fā)的微信研討群。