如你所見，在過去的幾年里，發(fā)生了快速的變化（這句話，我已經(jīng)說爛了）。好比如說：

• 編程門檻的降低。大量的低編程能力水平可以進入這個行業(yè)；

• 基礎設施的完善。只需要執(zhí)行 git push，便能完成 push to production（盡管四年前我們在項目上實踐過）；

• 云主機開發(fā)。遠程開發(fā)機器，代碼不在本地機器上；

• 多人實時開發(fā)編輯技術。諸如 Visual Studio Live Share，可以多人實時協(xié)作編程；

• 5G。更快速的網(wǎng)絡連接，更好的通信質量。

• ……

在經(jīng)歷了與公司大佬、同事、社區(qū)大佬等的一系列的技術討論之后，以及近年來開始云代碼開發(fā)，我又有了一些新的頓悟。于是，我就擼了這篇文章。

在你失去繼續(xù)往下閱讀的興趣之前，讓我先說第一個結論：

因此云開發(fā)是一種解決方案，它解決的問題是：如何以更高效的方式進行軟件開發(fā)？

作為 v0.1.0 的定義，我對它的定義可能還不是非常準確，但是重點有這么幾個：

• 以共同協(xié)作的方式開發(fā)軟件；

• 軟件開發(fā)的在線閉環(huán)；

• 應用生命周期的代碼化和可追溯。

你看吧，我們過去解決了一個又一個的線下協(xié)作問題，現(xiàn)在構建新的線上協(xié)作平臺的時機已經(jīng)逐漸成熟了，是時候開始準備構建你們的云開發(fā)平臺。

我知道你想說市面上已經(jīng)有這樣的工具，比如 xx 的 xx。但是，一來它朝著一個錯誤的方向前進，你知道的某公司更懂 2B；二來，它包含了大量的功能，但是卻沒有閉上環(huán)。當然了，我只是從官方的首頁看到的功能，一眼得到這個所謂的結論。

PS：只要是它們沒辦法體現(xiàn)我總結的核心三要素，笑~。套不上我的理論，他們一定是錯的，手動滑稽，逃~。

引子 1：核心三要素

這三個要素是軟件開發(fā)的要素，只有深入要素本身，才能成為真正的云平臺。

我不想多說廢話了，手疼。

如果基礎設施真的已經(jīng)是基礎設施，那么你不應該在云平臺強調它們。這就是為什么盡管基礎設施很重要，但是卻不是核心要素之一?；A設施已經(jīng)是一個通用域，作為一家時髦的公司，如果你們還沒有……

微架構

微架構，即以模塊化的組合方式協(xié)同構建大型應用（前端、后端、App 等）的架構方式。每個微應用都可以獨立開發(fā)、獨立部署、獨立運行，對應的替換的方式有模塊化、子模塊的方式，微服務、App 插件化（獨立構建、獨立運行）、微前端等。

微架構是一個模式，它不是銀彈，它以技術的方式拆解了復雜軟件架構，適合于復雜場景下的問題，還有人類腦容易不夠大的問題。

• 后端：服務導向架構

五年前，Martin Fowler 和 James Lewis 一起寫下了那篇《微服務架構》，微服務成為了今天新項目的主流架構之一。最近幾年來，它結合著《領域驅動設計》這把錘子，已經(jīng)成為了一個利器。

作為服務導向架構的一種實現(xiàn)方式，掌握它背后的設計與實現(xiàn)模式，是云開發(fā)中不可或缺的重要一環(huán)。

• 后端：函數(shù)即服務

兩年多以前，我在 GitHub 寫下了我的第 N 本電子書《Serverless 架構應用開發(fā)指南》，而在最近 Serverless 終于在國內慢慢有一點的熱度。兩年前，我陸續(xù)收到阿里云、騰訊云的 Serverless 嘗鮮體驗（作為一個 MVP 還是沒白混），但是它們并不成熟，甚至于無法調用自己的云服務。而今天，越來越多的云廠商的 Serverless 終于可以跑起來了。

同理于服務導向架構 BAAS （Backend as a service）又或者是 Serverless，也是如此，它們進一步拆解了復雜問題到人能 handle 的范圍。

• App：應用即『插件』

最近幾年，對于 App 來說，開發(fā)者也探索出了大量的微架構方案。我習慣地稱它們?yōu)閼眉础翰寮?，因?App 作為一個基座，提供了各式各樣的能力。就目前來說有三種展現(xiàn)方式：

• App 內 Web 應用。
• App 插件化。市面上已經(jīng)有大量這一類的方案，諸如于 RePlugin、Atlas、VirtualAPK、DynamicAPK。
• App 小程序。即功能以小程序的運行在容器化，即可以像 Web 容器一樣實現(xiàn)遠程更新，還能有效地控制開發(fā)商的權限，培養(yǎng)自己的生態(tài)。

盡管讓人們下載 App 的成本越來越高，App 平臺化成為了一種趨勢。

哪怕 App 的原生仍占很重要的一部分，但是 App 平臺的方案 + 應用插件化模式的生態(tài)構建，也是云開發(fā)要考慮的重要因素。

• 前端：微前端與應用組件化

今年是微前端開始火爆的一年，微前端框架層出不窮：SingleSPA、Mooa、qiankun、ngx-planet，還有諸如于《前端架構：從入門到微前端》這樣的書籍。它讓越來越多的企業(yè)開始思考前端架構的未來，也完善豐富的微前端相關的基礎設施。從某種意義上來說，這是組件化的一種方式，只是原先的組件只是簡單的 UI 組件，而現(xiàn)在的組件是一個完整功能的應用。只需要設計好對應的 pipe，就能完成一個應用的開發(fā)。

而隨著 5G 的到來，微 “服務化” 前端應用、Web Component 的體積已經(jīng)變得讓人可以接受。進行功能編排，將成為云開發(fā)的一個重要組成——畢竟，插件市場的不斷火爆，可以看出一些端倪。

代碼化

對于這部分的一句話總結是：

• Given Future[Dev]

• When Everything as Code，

• Then you can Guard

• Then you can Refactoring or Rewrite it.

然后，以下大概就是三種完全不同的模式。

• 設計到代碼：填空式開發(fā)

起先我只有兩種模式，直到月初在公司內部聽到了相關的分享，Get 了第三種模式：面向于大型組織的類型流 (https://github.com/notyy/TypeFlow) 開發(fā)。

這種方式頗為適合大型組織的軟件開發(fā)模式，由高級工程師設計出基本的模型與軟件架構，生成對應的方法名稱，以及其所需要的返回結果。這種模式事實上在過去已經(jīng)有了，剩下的就是普通的開發(fā)人員去填充對應的代碼。再結合 Serverless 等基礎設施，便可以直接集成上線。

它表面上看它是設計生成的代碼，實則設計即代碼。

• 需求到上線：無代碼編程

年初，我寫下了那篇《無代碼編程》，通過這篇文章，我結交了更多無代碼/低代碼已經(jīng)有大量的案例表明，這是一種可行的開發(fā)模式。

無代碼編程的本質是業(yè)務模式 + 編程模式的抽象化，以領域特定的場景解決領域特定的問題。所以，低代碼編程 / 無代碼編程它只能解決領域特定、簡單場景的需求，無法解決大部分的問題。

無代碼編程做了一件了解不起的事情是，直接對于業(yè)務和設計即需求的抽象，實現(xiàn)了直接由需求到代碼的直達。

• 代碼化：DSL as DSL

DSL 即 DSL，即把每件事物都變成 DSL?？紤]到我正在編寫一篇關于 DSL 如何設計的文章，我就不展開詳細的討論：

• 汲取領域名詞
• 模型分析與抽象
• 模型行為抽象
• 尋找關鍵抽象
• 場景代入
• 實現(xiàn) DSL
• 迭代優(yōu)化

而代碼本身也應該是一種 DSL，才能進一步完成云平臺的建議。需求、設計、代碼、構建、部署、運營都應該抽象成 DSL，才能完成真正意義上的云平臺。

協(xié)作設計文化

軟件開發(fā)是一個集體行為，軟件設計也是一個集體行為。所以，一個好的云開發(fā)平臺應該要融入共同協(xié)作的基因。

• 軟件開發(fā)文化

采用了敏捷，卻始終敏捷不起來，有一部分的原因在于：部門墻。對于非互聯(lián)網(wǎng)公司來說（對于大部分互聯(lián)網(wǎng)公司也是如此），開發(fā)一個軟件往往需要在多個部門甩鍋：業(yè)務部門、技術部門、測試部門、市場部門……

• 業(yè)務（領域）驅動設計

以我多年的讀書經(jīng)驗來看，人們采用開發(fā)出失敗軟件的原因，無非就是兩點：『缺少協(xié)作設計』和『知識傳遞』。對了，還有技術水平不行，這個反而不是那么重要。

而 《DDD （領域驅動設計）》和事件風暴，正是軟件開發(fā)文化的一種實踐，通過協(xié)作設計的方式，傳遞知識，以妥協(xié)出符合大家需要的應用。

• 服務端服務中臺與客戶端組件中臺

可能是我對于中臺的誤解，我習慣性稱中臺為『不可清空的垃圾回收站』。但是，它做了一件不可思議的事件，將 “基礎設施服務” 化，成為了一個 common 的 common 的 common。好了，調侃到此結束。

隨著中臺建設的進一步完善，大量的基礎設施，將從原先的各個業(yè)務部分，統(tǒng)一到了這個 ~~垃圾回收站~~ 大平臺。

有了這個基礎部分，我們才能邁向下一步。

引子 2：編程的本質

好了，我要繼續(xù)瞎扯了，首先再次回答那個問題，如何以更高效地方式進行軟件開發(fā)？那么，首先我們需要找到一個解決方案，以應對那個問題：如何解決人類智商不夠的問題？

解決復雜問題

于是，首先，讓我們引入 Cynefin 框架來解決復雜問題。

PS：復制和粘貼大法好啊，一時爽一直爽。

• 簡單（Simple），該域中的因果關系顯而易見，方法是感知——分類——響應（Sense - Categorise - Respond），我們能夠應用最佳實踐。

• 繁雜（Complicated），該域中的因果關系需要分析，或者需要一些其他形式的調查和 / 或專業(yè)知識的應用，方法是感知——分析——響應（Sense - Analyze - Respond ），我們能夠應用好的實踐。

• 復雜（Complex），該域中的因果關系僅能夠從回想中感應，不能提前，方法是探索——感知——響應（Probe - Sense - Respond ），我們能夠感知涌現(xiàn)實踐（emergent practice）。

• 混沌（Chaotic），該域中沒有系統(tǒng)級別的因果關系，方法是行動——感知——響應（Act - Sense - Respond ），我們能夠發(fā)現(xiàn)新穎的實踐（novel practice）。

• 第 5 個域是失序，該域中不清楚存在什么樣的因果關系，這種狀態(tài)下人們將會恢復到自己舒服的域做決定。Cynefin 框架擁有子域，簡單和混亂之間的一線之隔是災難性的：驕傲自滿導致失敗。

有了這個框架之后，我們便來到了第一個結論。對于編程來說，我們的關鍵性問題在于：如何將復雜問題繁雜化？因為簡單的問題便簡單，繁雜的問題也容易解決。

復雜問題的應對之道

什么是復雜問題？

引用公司大佬的三句話：

• 場景多且復雜；

• 人類的智商不夠；

• 語言不統(tǒng)一。

這三個問題的答案暫不免費公開，有意者可以咨詢我 —— 其實都在本文里。

看完文章后，回過頭來回顧一下這個問題。

大型組織的軟件開發(fā)模式

為了解決上述的問題，對于大型組織來說，采用的第一個模式就是：拆解。

• 資深開發(fā)人員，設計架構；

• 中級開發(fā)人員，review 代碼；

• 普通開發(fā)人員，完成開發(fā)；

• 新手開發(fā)人員，寫寫測試。

而就當前而言，這幾個部分存在一些割裂。代碼反應架構，架構實現(xiàn)代碼。缺少相應的架構守護、質量門禁等等，并且諸如于 review 的工作是由機器完成的。

云開發(fā)

好了，看到這里不容易。因為剩下的內容已經(jīng)不重要了。

什么是云開發(fā)？

再一次地，讓我們看一下定義：

于是乎，它不同于云主機 / 遠程主機開發(fā)模式，只需要一個瀏覽器 / 客戶端 / IDE，便可以在線完成：

• 實例化需求

• 架構、交互的設計

• 編碼的代碼化

• 自動集成與構建

• 無環(huán)境部署

• 人工智能運營

舉起我的炒板栗：

• （調試）輸入一個 console.log 或者 fmt.Println 便可以在生產(chǎn)環(huán)境對應地打出日志。

• （需求直接上線）改一個 Icon 的需求，在圖標上傳到 Kanban 的時候。NLP 后，自動提交到代碼庫，部署到生產(chǎn)環(huán)境。

• （代碼創(chuàng)建需求）把默認字體的色彩，由 #000 改成 #384452 的時候，能反觸發(fā)對應的需求變更——不過就是 commit message，反向地創(chuàng)建需求嘛。

• （設計同步）模型上添加一個新的字段，對應的完成前端、后端模型的自動化更新。

• （代碼構建同步）新的分支，新的 pipeline，用完即刪。

• ……

它基于這么一些原則：

• 代碼化優(yōu)于過程化數(shù)據(jù)；

• 流程自閉環(huán)優(yōu)于交互；

• 度量內建優(yōu)于可視化。

要的就是這么簡單，對于開發(fā)來說，只是對應于領域建模、詳細設計、填空式開發(fā)等。

如何構建云開發(fā)平臺？

成熟度模型

就定義來說，我們可以將其劃分為五個階段：

• 具備基本的遠程編程能力及自動化部署。即代碼無需在本地

• 在云端能完成軟件開發(fā)的完整生命周期。能在云端完成所有的軟件開發(fā)的工作，并且配套

• 云開發(fā)平臺上的云開發(fā)平臺。（自舉）

• 借助于代碼化的方式，將軟件開發(fā)的每一個步驟都變成代碼

• 實現(xiàn)開發(fā)全流程的自動優(yōu)化。如自動化的藍綠部署，自動化選擇方案，自動化優(yōu)化。

• 無人編程。Human Over

第一個階段。靠人海戰(zhàn)術就可以實現(xiàn)了。

第二個階段。依賴于抽象軟件開發(fā)模式。

第三個階段。證明自己，體力勞動。

第四個階段。進一步抽象軟件開發(fā)。

第五個階段。抽象人工部分，智能完成。

所以，嗯，大概要 N 的時間才能完成這個系統(tǒng)的設計。畢竟，云開發(fā)是一個復雜問題，我們需要不斷拆解系統(tǒng)，結合微架構、代碼化、協(xié)作設計三個核心要素，以免我們在歷史的長河中消失。

云開發(fā)平臺基石

雖然，我一直在強調實現(xiàn)只是一個細節(jié)，但是還是得大致了解一下實現(xiàn)機制。

• 集成開發(fā)環(huán)境

編碼環(huán)境 + 設計環(huán)境。

微信小程序、支付寶小程序、在線 Web IDE，VS Code / Monaco Editor 幾乎已經(jīng)當前成為了定制編輯器 / IDE 的最好選擇。這樣一看，JetBrains 再不努力，可能會失去未來，就像當年的 Delphi 一樣，笑~。

這方面的技術在業(yè)內已經(jīng)相當成熟了，不就是加一些插件嘛。

不過呢，它們只是在堆砌一些功能，缺乏閉環(huán)上的設計：

• 需求關聯(lián)設計，關聯(lián)代碼；
• 代碼展示設計，關聯(lián)需求；
• 構建關聯(lián)代碼，連接部署。

如你所知的提交信息規(guī)范是一種形式，它可以關聯(lián)到需求；如你所知的領域建模是一種形式，讓代碼關聯(lián)到設計上。

• 基礎設施

盡管，在文章開頭的時候，我說了基礎設施不重要。但是到真正需要實施的時候，我們不得不強調它的重要性。我們需要的東西有：

• 微架構支持
• 部署和構建支持
• 自動配置化管理
• ……

而圍繞在它背后的是各種模式的提煉。

• 模式提煉

無論是在哪個行業(yè)，值錢的東西在于原則與模式。原則與模式是用來快速提升能力的方式，換句話來說，就是讓新手能像以大牛一樣的方式工作——盡管會濫用模式。所以：

• 代碼的模式類庫
• 開發(fā)流程模式
• 用戶體驗設計模式
• ……

這些是核心所在，抽象、提取、模式化。

• 全流程閉環(huán)

如你所猜想的一樣，構建這樣一個平臺的難點，不在于實現(xiàn)功能，而在于設計。只需要保證在當前階段的信息，能夠傳遞到下一階段即可，而不在于你使用什么工具。

你可以使用 Jira、Trello、Mingle 或者基于 Git + DSL 的方式，只需要保證它們能關聯(lián)到下一階段，即可。一步步往下，將信息關聯(lián)到設計、代碼、構建、部署、運營，運營再反應到需求上，就能完成上的設計。

So？

原型設計與關鍵因子

作為模式的拆解，我做了一個簡單的分級，以便于一步步實現(xiàn)整個系統(tǒng)：

需求

事實上，采用諸如 Cucumber 一樣的 Given-When-Then 三段式設計就夠了。所以在我的 story 工具里，利用了注釋作為額外的信息擴充。Cucumber 使用的 DSL 已經(jīng)有豐富的：

有了這個設計，我們可以將這個設計結合到我們的下一步設計中。

設計

其實 UML 本身也是一個不錯的原型，只需要創(chuàng)建一個 DSL 將其中的一部分轉成 UML，再結合一下 UI 上的 DSL 便能實現(xiàn)流程上的設計：

flow login {
    SEE HomePage
    DO [Click] Login.Button
        REACT Success: SHOW Login Success.Toast with ANIMATE(bounce)
        REACT Failure: SHOW Login Failure.Dialog

    SEE Login Failure.Dialog
    DO [Click] ForgotPassword.Button
        REACT: GOTO ForgotPasswordPage

    SEE ForgotPasswordPage
    DO [Click] RESET PASSWORD.Button
        REACT: SHOW Please Check Email.Message
}

最近，我們在做一個對應的架構設計平臺，結合我的 https://github.com/phodal/design 用于代碼生成設計，設計轉為代碼。

代碼

代碼生成并不是一件新鮮的事物，有大量的人在做大量的事件。編寫一個 DSL，用這個 DSL 結合編程語言描述 DSL 來生成不同的編程語言，這便是我最近在做的事情之一。它并不復雜，只是繁瑣。

嗯，我花了很多時間在設計這個步驟的兩個 DSL，其中一個是生成語言的 DSL，一個則是獨立的編程 DSL。

與此同時，對于代碼來說，我們關注于：驗收標準和適應度函數(shù)。

驗收標準

• 設計生成代碼，代碼反應設計

• DSL 生成代碼

適應度函數(shù)

• 軟件質量門檻

• 自動化架構守護

• 自動化測試生成（回錄）

• 系統(tǒng)演進設計

借助于此，我們才能承上啟下。

構建

對于持續(xù)集成來說，需要手動去配置是一個糟糕的事情。所以，我們 Jenkins 使用了 Pipeline as Code 來抽象流水線的構建。但是，它沒有真正解決問題，因為現(xiàn)實的軟件開發(fā)是非常復雜的。對于一個項目來說，它存在過多的分支，不同的構建。所以，真正意義上的持續(xù)構建，應該采用諸如于 Pipeline as Pipeline 這樣的方式。

部署

事實上，DevOps 技術已經(jīng)足夠的成熟，我們已經(jīng)能實施相關的步驟：

• 部署自動化

• 部署代碼化

• 提交即上線

• 部署自治

代碼質量的控制，自動化測試，決定了部署成熟度。

運營

這一步，我還不是非常擅長，以我有限的經(jīng)驗來看，現(xiàn)有的工具就夠了。唯一要做的事情是，收集數(shù)據(jù)，抽象模式，構建 DSL，串聯(lián)起來。

• 運營可視化

• 運營中心化

• 代碼化運營

• 運營需求化

需求 -> 代碼 -> 運營，運營反饋需求。

云開發(fā)平臺成熟度模型

嗯，看標題就夠了。

• Level 1：可追述、電子化

• Level 2：全流程閉環(huán)

• Level 3：云平臺上的云平臺

• Level 4：代碼化云平臺

• Level 5：自動化優(yōu)化流程

• Level 6：human over

結論

最后，再讓我們回到這張圖上：

這就是核心所在。

哦，對了，做平臺是一件苦逼的事情。

作者簡介：黃峰達（Phodal），ThoughtWorks Senior Consultant，CSDN 博客專家。長期活躍于 GitHub、CSDN，專注于物聯(lián)網(wǎng)和前端領域。出版著作《自己動手設計物聯(lián)網(wǎng)》，以及《Growth：全棧增長工程師指南》等六本電子書，并譯有《物聯(lián)網(wǎng)實戰(zhàn)指南》。

【END】