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

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

• 基礎(chǔ)設(shè)施的完善。只需要執(zhí)行 git push，便能完成 push to production（盡管四年前我們?cè)陧?xiàng)目上實(shí)踐過）；

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

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

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

• ……

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

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

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

作為 v0.1.0 的定義，我對(duì)它的定義可能還不是非常準(zhǔn)確，但是重點(diǎn)有這么幾個(gè)：

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

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

• 應(yīng)用生命周期的代碼化和可追溯。

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

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

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

引子 1：核心三要素

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

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

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

微架構(gòu)

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

微架構(gòu)是一個(gè)模式，它不是銀彈，它以技術(shù)的方式拆解了復(fù)雜軟件架構(gòu)，適合于復(fù)雜場(chǎng)景下的問題，還有人類腦容易不夠大的問題。

• 后端：服務(wù)導(dǎo)向架構(gòu)

五年前，Martin Fowler 和 James Lewis 一起寫下了那篇《微服務(wù)架構(gòu)》，微服務(wù)成為了今天新項(xiàng)目的主流架構(gòu)之一。最近幾年來，它結(jié)合著《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》這把錘子，已經(jīng)成為了一個(gè)利器。

作為服務(wù)導(dǎo)向架構(gòu)的一種實(shí)現(xiàn)方式，掌握它背后的設(shè)計(jì)與實(shí)現(xiàn)模式，是云開發(fā)中不可或缺的重要一環(huán)。

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

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

同理于服務(wù)導(dǎo)向架構(gòu) BAAS （Backend as a service）又或者是 Serverless，也是如此，它們進(jìn)一步拆解了復(fù)雜問題到人能 handle 的范圍。

• App：應(yīng)用即『插件』

最近幾年，對(duì)于 App 來說，開發(fā)者也探索出了大量的微架構(gòu)方案。我習(xí)慣地稱它們?yōu)閼?yīng)用即『插件』，因?yàn)?App 作為一個(gè)基座，提供了各式各樣的能力。就目前來說有三種展現(xiàn)方式：

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

盡管讓人們下載 App 的成本越來越高，App 平臺(tái)化成為了一種趨勢(shì)。

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

• 前端：微前端與應(yīng)用組件化

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

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

代碼化

對(duì)于這部分的一句話總結(jié)是：

• Given Future[Dev]

• When Everything as Code，

• Then you can Guard

• Then you can Refactoring or Rewrite it.

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

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

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

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

它表面上看它是設(shè)計(jì)生成的代碼，實(shí)則設(shè)計(jì)即代碼。

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

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

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

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

• 代碼化：DSL as DSL

DSL 即 DSL，即把每件事物都變成 DSL。考慮到我正在編寫一篇關(guān)于 DSL 如何設(shè)計(jì)的文章，我就不展開詳細(xì)的討論：

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

而代碼本身也應(yīng)該是一種 DSL，才能進(jìn)一步完成云平臺(tái)的建議。需求、設(shè)計(jì)、代碼、構(gòu)建、部署、運(yùn)營都應(yīng)該抽象成 DSL，才能完成真正意義上的云平臺(tái)。

協(xié)作設(shè)計(jì)文化

軟件開發(fā)是一個(gè)集體行為，軟件設(shè)計(jì)也是一個(gè)集體行為。所以，一個(gè)好的云開發(fā)平臺(tái)應(yīng)該要融入共同協(xié)作的基因。

• 軟件開發(fā)文化

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

• 業(yè)務(wù)（領(lǐng)域）驅(qū)動(dòng)設(shè)計(jì)

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

而 《DDD （領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）》和事件風(fēng)暴，正是軟件開發(fā)文化的一種實(shí)踐，通過協(xié)作設(shè)計(jì)的方式，傳遞知識(shí)，以妥協(xié)出符合大家需要的應(yīng)用。

• 服務(wù)端服務(wù)中臺(tái)與客戶端組件中臺(tái)

可能是我對(duì)于中臺(tái)的誤解，我習(xí)慣性稱中臺(tái)為『不可清空的垃圾回收站』。但是，它做了一件不可思議的事件，將 “基礎(chǔ)設(shè)施服務(wù)” 化，成為了一個(gè) common 的 common 的 common。好了，調(diào)侃到此結(jié)束。

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

有了這個(gè)基礎(chǔ)部分，我們才能邁向下一步。

引子 2：編程的本質(zhì)

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

解決復(fù)雜問題

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

PS：復(fù)制和粘貼大法好啊，一時(shí)爽一直爽。

• 簡(jiǎn)單（Simple），該域中的因果關(guān)系顯而易見，方法是感知——分類——響應(yīng)（Sense - Categorise - Respond），我們能夠應(yīng)用最佳實(shí)踐。

• 繁雜（Complicated），該域中的因果關(guān)系需要分析，或者需要一些其他形式的調(diào)查和 / 或?qū)I(yè)知識(shí)的應(yīng)用，方法是感知——分析——響應(yīng)（Sense - Analyze - Respond ），我們能夠應(yīng)用好的實(shí)踐。

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

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

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

有了這個(gè)框架之后，我們便來到了第一個(gè)結(jié)論。對(duì)于編程來說，我們的關(guān)鍵性問題在于：如何將復(fù)雜問題繁雜化？因?yàn)楹?jiǎn)單的問題便簡(jiǎn)單，繁雜的問題也容易解決。

復(fù)雜問題的應(yīng)對(duì)之道

什么是復(fù)雜問題？

引用公司大佬的三句話：

• 場(chǎng)景多且復(fù)雜；

• 人類的智商不夠；

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

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

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

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

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

• 資深開發(fā)人員，設(shè)計(jì)架構(gòu)；

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

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

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

而就當(dāng)前而言，這幾個(gè)部分存在一些割裂。代碼反應(yīng)架構(gòu)，架構(gòu)實(shí)現(xiàn)代碼。缺少相應(yīng)的架構(gòu)守護(hù)、質(zhì)量門禁等等，并且諸如于 review 的工作是由機(jī)器完成的。

云開發(fā)

好了，看到這里不容易。因?yàn)槭Ｏ碌膬?nèi)容已經(jīng)不重要了。

什么是云開發(fā)？

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

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

• 實(shí)例化需求

• 架構(gòu)、交互的設(shè)計(jì)

• 編碼的代碼化

• 自動(dòng)集成與構(gòu)建

• 無環(huán)境部署

• 人工智能運(yùn)營

舉起我的炒板栗：

• （調(diào)試）輸入一個(gè) console.log 或者 fmt.Println 便可以在生產(chǎn)環(huán)境對(duì)應(yīng)地打出日志。

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

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

• （設(shè)計(jì)同步）模型上添加一個(gè)新的字段，對(duì)應(yīng)的完成前端、后端模型的自動(dòng)化更新。

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

• ……

它基于這么一些原則：

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

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

• 度量?jī)?nèi)建優(yōu)于可視化。

要的就是這么簡(jiǎn)單，對(duì)于開發(fā)來說，只是對(duì)應(yīng)于領(lǐng)域建模、詳細(xì)設(shè)計(jì)、填空式開發(fā)等。

如何構(gòu)建云開發(fā)平臺(tái)？

成熟度模型

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

• 具備基本的遠(yuǎn)程編程能力及自動(dòng)化部署。即代碼無需在本地

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

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

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

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

• 無人編程。Human Over

第一個(gè)階段?？咳撕?zhàn)術(shù)就可以實(shí)現(xiàn)了。

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

第三個(gè)階段。證明自己，體力勞動(dòng)。

第四個(gè)階段。進(jìn)一步抽象軟件開發(fā)。

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

所以，嗯，大概要 N 的時(shí)間才能完成這個(gè)系統(tǒng)的設(shè)計(jì)。畢竟，云開發(fā)是一個(gè)復(fù)雜問題，我們需要不斷拆解系統(tǒng)，結(jié)合微架構(gòu)、代碼化、協(xié)作設(shè)計(jì)三個(gè)核心要素，以免我們?cè)跉v史的長(zhǎng)河中消失。

云開發(fā)平臺(tái)基石

雖然，我一直在強(qiáng)調(diào)實(shí)現(xiàn)只是一個(gè)細(xì)節(jié)，但是還是得大致了解一下實(shí)現(xiàn)機(jī)制。

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

編碼環(huán)境 + 設(shè)計(jì)環(huán)境。

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

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

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

• 需求關(guān)聯(lián)設(shè)計(jì)，關(guān)聯(lián)代碼；
• 代碼展示設(shè)計(jì)，關(guān)聯(lián)需求；
• 構(gòu)建關(guān)聯(lián)代碼，連接部署。

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

• 基礎(chǔ)設(shè)施

盡管，在文章開頭的時(shí)候，我說了基礎(chǔ)設(shè)施不重要。但是到真正需要實(shí)施的時(shí)候，我們不得不強(qiáng)調(diào)它的重要性。我們需要的東西有：

• 微架構(gòu)支持
• 部署和構(gòu)建支持
• 自動(dòng)配置化管理
• ……

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

• 模式提煉

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

• 代碼的模式類庫
• 開發(fā)流程模式
• 用戶體驗(yàn)設(shè)計(jì)模式
• ……

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

• 全流程閉環(huán)

如你所猜想的一樣，構(gòu)建這樣一個(gè)平臺(tái)的難點(diǎn)，不在于實(shí)現(xiàn)功能，而在于設(shè)計(jì)。只需要保證在當(dāng)前階段的信息，能夠傳遞到下一階段即可，而不在于你使用什么工具。

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

So？

原型設(shè)計(jì)與關(guān)鍵因子

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

需求

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

有了這個(gè)設(shè)計(jì)，我們可以將這個(gè)設(shè)計(jì)結(jié)合到我們的下一步設(shè)計(jì)中。

設(shè)計(jì)

其實(shí) UML 本身也是一個(gè)不錯(cuò)的原型，只需要?jiǎng)?chuàng)建一個(gè) DSL 將其中的一部分轉(zhuǎn)成 UML，再結(jié)合一下 UI 上的 DSL 便能實(shí)現(xiàn)流程上的設(shè)計(jì)：

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
}

最近，我們?cè)谧鲆粋€(gè)對(duì)應(yīng)的架構(gòu)設(shè)計(jì)平臺(tái)，結(jié)合我的 https://github.com/phodal/design 用于代碼生成設(shè)計(jì)，設(shè)計(jì)轉(zhuǎn)為代碼。

代碼

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

嗯，我花了很多時(shí)間在設(shè)計(jì)這個(gè)步驟的兩個(gè) DSL，其中一個(gè)是生成語言的 DSL，一個(gè)則是獨(dú)立的編程 DSL。

與此同時(shí)，對(duì)于代碼來說，我們關(guān)注于：驗(yàn)收標(biāo)準(zhǔn)和適應(yīng)度函數(shù)。

驗(yàn)收標(biāo)準(zhǔn)

• 設(shè)計(jì)生成代碼，代碼反應(yīng)設(shè)計(jì)

• DSL 生成代碼

適應(yīng)度函數(shù)

• 軟件質(zhì)量門檻

• 自動(dòng)化架構(gòu)守護(hù)

• 自動(dòng)化測(cè)試生成（回錄）

• 系統(tǒng)演進(jìn)設(shè)計(jì)

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

構(gòu)建

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

部署

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

• 部署自動(dòng)化

• 部署代碼化

• 提交即上線

• 部署自治

代碼質(zhì)量的控制，自動(dòng)化測(cè)試，決定了部署成熟度。

運(yùn)營

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

• 運(yùn)營可視化

• 運(yùn)營中心化

• 代碼化運(yùn)營

• 運(yùn)營需求化

需求 -> 代碼 -> 運(yùn)營，運(yùn)營反饋需求。

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

嗯，看標(biāo)題就夠了。

• Level 1：可追述、電子化

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

• Level 3：云平臺(tái)上的云平臺(tái)

• Level 4：代碼化云平臺(tái)

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

• Level 6：human over

結(jié)論

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

這就是核心所在。

哦，對(duì)了，做平臺(tái)是一件苦逼的事情。

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

【END】