如你所見，在過去的幾年里，發(fā)生了快速的變化（這句話，我已經(jīng)說爛了）。好比如說：
編程門檻的降低。大量的低編程能力水平可以進入這個行業(yè)；
基礎(chǔ)設(shè)施的完善。只需要執(zhí)行 git push，便能完成 push to production（盡管四年前我們在項目上實踐過）；
云主機開發(fā)。遠程開發(fā)機器，代碼不在本地機器上；
多人實時開發(fā)編輯技術(shù)。諸如 Visual Studio Live Share，可以多人實時協(xié)作編程；
5G。更快速的網(wǎng)絡(luò)連接，更好的通信質(zhì)量。
……
在經(jīng)歷了與公司大佬、同事、社區(qū)大佬等的一系列的技術(shù)討論之后，以及近年來開始云代碼開發(fā)，我又有了一些新的頓悟。于是，我就擼了這篇文章。
在你失去繼續(xù)往下閱讀的興趣之前，讓我先說第一個結(jié)論：
云開發(fā)，是一種生于云上的閉環(huán) + 代碼化的軟件開發(fā)方式。它可以讓業(yè)務(wù)人員、開發(fā)人員、運營人員等在同一個云端共同協(xié)作、透明化地完成整個軟件的生命周期（需求、設(shè)計、編碼、構(gòu)建、部署、運營），而非相互隔離，又或者是借助于多個軟件才能完成工作。
因此云開發(fā)是一種解決方案，它解決的問題是：如何以更高效的方式進行軟件開發(fā)？
作為 v0.1.0 的定義，我對它的定義可能還不是非常準確，但是重點有這么幾個：
以共同協(xié)作的方式開發(fā)軟件；
軟件開發(fā)的在線閉環(huán)；
應(yīng)用生命周期的代碼化和可追溯。
你看吧，我們過去解決了一個又一個的線下協(xié)作問題，現(xiàn)在構(gòu)建新的線上協(xié)作平臺的時機已經(jīng)逐漸成熟了，是時候開始準備構(gòu)建你們的云開發(fā)平臺。
我知道你想說市面上已經(jīng)有這樣的工具，比如 xx 的 xx。但是，一來它朝著一個錯誤的方向前進，你知道的某公司更懂 2B；二來，它包含了大量的功能，但是卻沒有閉上環(huán)。當然了，我只是從官方的首頁看到的功能，一眼得到這個所謂的結(jié)論。
PS：只要是它們沒辦法體現(xiàn)我總結(jié)的核心三要素，笑~。套不上我的理論，他們一定是錯的，手動滑稽，逃~。
引子 1：核心三要素
這三個要素是軟件開發(fā)的要素，只有深入要素本身，才能成為真正的云平臺。
我不想多說廢話了，手疼。
如果基礎(chǔ)設(shè)施真的已經(jīng)是基礎(chǔ)設(shè)施，那么你不應(yīng)該在云平臺強調(diào)它們。這就是為什么盡管基礎(chǔ)設(shè)施很重要，但是卻不是核心要素之一?；A(chǔ)設(shè)施已經(jīng)是一個通用域，作為一家時髦的公司，如果你們還沒有……
微架構(gòu)
微架構(gòu)，即以模塊化的組合方式協(xié)同構(gòu)建大型應(yīng)用（前端、后端、App 等）的架構(gòu)方式。每個微應(yīng)用都可以獨立開發(fā)、獨立部署、獨立運行，對應(yīng)的替換的方式有模塊化、子模塊的方式，微服務(wù)、App 插件化（獨立構(gòu)建、獨立運行）、微前端等。
微架構(gòu)是一個模式，它不是銀彈，它以技術(shù)的方式拆解了復(fù)雜軟件架構(gòu)，適合于復(fù)雜場景下的問題，還有人類腦容易不夠大的問題。
后端：服務(wù)導(dǎo)向架構(gòu)
五年前，Martin Fowler 和 James Lewis 一起寫下了那篇《微服務(wù)架構(gòu)》，微服務(wù)成為了今天新項目的主流架構(gòu)之一。最近幾年來，它結(jié)合著《領(lǐng)域驅(qū)動設(shè)計》這把錘子，已經(jīng)成為了一個利器。
作為服務(wù)導(dǎo)向架構(gòu)的一種實現(xiàn)方式，掌握它背后的設(shè)計與實現(xiàn)模式，是云開發(fā)中不可或缺的重要一環(huán)。
后端：函數(shù)即服務(wù)
兩年多以前，我在 GitHub 寫下了我的第 N 本電子書《Serverless 架構(gòu)應(yīng)用開發(fā)指南》，而在最近 Serverless 終于在國內(nèi)慢慢有一點的熱度。兩年前，我陸續(xù)收到阿里云、騰訊云的 Serverless 嘗鮮體驗（作為一個 MVP 還是沒白混），但是它們并不成熟，甚至于無法調(diào)用自己的云服務(wù)。而今天，越來越多的云廠商的 Serverless 終于可以跑起來了。
同理于服務(wù)導(dǎo)向架構(gòu) BAAS （Backend as a service）又或者是 Serverless，也是如此，它們進一步拆解了復(fù)雜問題到人能 handle 的范圍。
App：應(yīng)用即『插件』
最近幾年，對于 App 來說，開發(fā)者也探索出了大量的微架構(gòu)方案。我習慣地稱它們?yōu)閼?yīng)用即『插件』，因為 App 作為一個基座，提供了各式各樣的能力。就目前來說有三種展現(xiàn)方式：
盡管讓人們下載 App 的成本越來越高，App 平臺化成為了一種趨勢。
哪怕 App 的原生仍占很重要的一部分，但是 App 平臺的方案 + 應(yīng)用插件化模式的生態(tài)構(gòu)建，也是云開發(fā)要考慮的重要因素。
前端：微前端與應(yīng)用組件化
今年是微前端開始火爆的一年，微前端框架層出不窮：SingleSPA、Mooa、qiankun、ngx-planet，還有諸如于《前端架構(gòu)：從入門到微前端》這樣的書籍。它讓越來越多的企業(yè)開始思考前端架構(gòu)的未來，也完善豐富的微前端相關(guān)的基礎(chǔ)設(shè)施。從某種意義上來說，這是組件化的一種方式，只是原先的組件只是簡單的 UI 組件，而現(xiàn)在的組件是一個完整功能的應(yīng)用。只需要設(shè)計好對應(yīng)的 pipe，就能完成一個應(yīng)用的開發(fā)。
而隨著 5G 的到來，微 “服務(wù)化” 前端應(yīng)用、Web Component 的體積已經(jīng)變得讓人可以接受。進行功能編排，將成為云開發(fā)的一個重要組成——畢竟，插件市場的不斷火爆，可以看出一些端倪。
代碼化
對于這部分的一句話總結(jié)是：
Given Future[Dev]
When Everything as Code，
Then you can Guard
Then you can Refactoring or Rewrite it.
然后，以下大概就是三種完全不同的模式。
設(shè)計到代碼：填空式開發(fā)
起先我只有兩種模式，直到月初在公司內(nèi)部聽到了相關(guān)的分享，Get 了第三種模式：面向于大型組織的類型流 (https://github.com/notyy/TypeFlow) 開發(fā)。
這種方式頗為適合大型組織的軟件開發(fā)模式，由高級工程師設(shè)計出基本的模型與軟件架構(gòu)，生成對應(yīng)的方法名稱，以及其所需要的返回結(jié)果。這種模式事實上在過去已經(jīng)有了，剩下的就是普通的開發(fā)人員去填充對應(yīng)的代碼。再結(jié)合 Serverless 等基礎(chǔ)設(shè)施，便可以直接集成上線。
它表面上看它是設(shè)計生成的代碼，實則設(shè)計即代碼。
需求到上線：無代碼編程
年初，我寫下了那篇《無代碼編程》，通過這篇文章，我結(jié)交了更多無代碼/低代碼已經(jīng)有大量的案例表明，這是一種可行的開發(fā)模式。
無代碼編程的本質(zhì)是業(yè)務(wù)模式 + 編程模式的抽象化，以領(lǐng)域特定的場景解決領(lǐng)域特定的問題。所以，低代碼編程 / 無代碼編程它只能解決領(lǐng)域特定、簡單場景的需求，無法解決大部分的問題。
無代碼編程做了一件了解不起的事情是，直接對于業(yè)務(wù)和設(shè)計即需求的抽象，實現(xiàn)了直接由需求到代碼的直達。
代碼化：DSL as DSL
DSL 即 DSL，即把每件事物都變成 DSL。考慮到我正在編寫一篇關(guān)于 DSL 如何設(shè)計的文章，我就不展開詳細的討論：
而代碼本身也應(yīng)該是一種 DSL，才能進一步完成云平臺的建議。需求、設(shè)計、代碼、構(gòu)建、部署、運營都應(yīng)該抽象成 DSL，才能完成真正意義上的云平臺。
協(xié)作設(shè)計文化
軟件開發(fā)是一個集體行為，軟件設(shè)計也是一個集體行為。所以，一個好的云開發(fā)平臺應(yīng)該要融入共同協(xié)作的基因。
軟件開發(fā)文化
采用了敏捷，卻始終敏捷不起來，有一部分的原因在于：部門墻。對于非互聯(lián)網(wǎng)公司來說（對于大部分互聯(lián)網(wǎng)公司也是如此），開發(fā)一個軟件往往需要在多個部門甩鍋：業(yè)務(wù)部門、技術(shù)部門、測試部門、市場部門……
業(yè)務(wù)（領(lǐng)域）驅(qū)動設(shè)計
以我多年的讀書經(jīng)驗來看，人們采用開發(fā)出失敗軟件的原因，無非就是兩點：『缺少協(xié)作設(shè)計』和『知識傳遞』。對了，還有技術(shù)水平不行，這個反而不是那么重要。
而 《DDD （領(lǐng)域驅(qū)動設(shè)計）》和事件風暴，正是軟件開發(fā)文化的一種實踐，通過協(xié)作設(shè)計的方式，傳遞知識，以妥協(xié)出符合大家需要的應(yīng)用。
服務(wù)端服務(wù)中臺與客戶端組件中臺
可能是我對于中臺的誤解，我習慣性稱中臺為『不可清空的垃圾回收站』。但是，它做了一件不可思議的事件，將 “基礎(chǔ)設(shè)施服務(wù)” 化，成為了一個 common 的 common 的 common。好了，調(diào)侃到此結(jié)束。
隨著中臺建設(shè)的進一步完善，大量的基礎(chǔ)設(shè)施，將從原先的各個業(yè)務(wù)部分，統(tǒng)一到了這個 ~~垃圾回收站~~ 大平臺。
有了這個基礎(chǔ)部分，我們才能邁向下一步。
引子 2：編程的本質(zhì)
好了，我要繼續(xù)瞎扯了，首先再次回答那個問題，如何以更高效地方式進行軟件開發(fā)？那么，首先我們需要找到一個解決方案，以應(yīng)對那個問題：如何解決人類智商不夠的問題？
解決復(fù)雜問題
于是，首先，讓我們引入 Cynefin 框架來解決復(fù)雜問題。
PS：復(fù)制和粘貼大法好啊，一時爽一直爽。
簡單（Simple），該域中的因果關(guān)系顯而易見，方法是感知——分類——響應(yīng)（Sense - Categorise - Respond），我們能夠應(yīng)用最佳實踐。
繁雜（Complicated），該域中的因果關(guān)系需要分析，或者需要一些其他形式的調(diào)查和 / 或?qū)I(yè)知識的應(yīng)用，方法是感知——分析——響應(yīng)（Sense - Analyze - Respond ），我們能夠應(yīng)用好的實踐。
復(fù)雜（Complex），該域中的因果關(guān)系僅能夠從回想中感應(yīng)，不能提前，方法是探索——感知——響應(yīng)（Probe - Sense - Respond ），我們能夠感知涌現(xiàn)實踐（emergent practice）。
混沌（Chaotic），該域中沒有系統(tǒng)級別的因果關(guān)系，方法是行動——感知——響應(yīng)（Act - Sense - Respond ），我們能夠發(fā)現(xiàn)新穎的實踐（novel practice）。
第 5 個域是失序，該域中不清楚存在什么樣的因果關(guān)系，這種狀態(tài)下人們將會恢復(fù)到自己舒服的域做決定。Cynefin 框架擁有子域，簡單和混亂之間的一線之隔是災(zāi)難性的：驕傲自滿導(dǎo)致失敗。
有了這個框架之后，我們便來到了第一個結(jié)論。對于編程來說，我們的關(guān)鍵性問題在于：如何將復(fù)雜問題繁雜化？因為簡單的問題便簡單，繁雜的問題也容易解決。
復(fù)雜問題的應(yīng)對之道
什么是復(fù)雜問題？
引用公司大佬的三句話：
場景多且復(fù)雜；
人類的智商不夠；
語言不統(tǒng)一。
這三個問題的答案暫不免費公開，有意者可以咨詢我 —— 其實都在本文里。
看完文章后，回過頭來回顧一下這個問題。
大型組織的軟件開發(fā)模式
為了解決上述的問題，對于大型組織來說，采用的第一個模式就是：拆解。
資深開發(fā)人員，設(shè)計架構(gòu)；
中級開發(fā)人員，review 代碼；
普通開發(fā)人員，完成開發(fā)；
新手開發(fā)人員，寫寫測試。
而就當前而言，這幾個部分存在一些割裂。代碼反應(yīng)架構(gòu)，架構(gòu)實現(xiàn)代碼。缺少相應(yīng)的架構(gòu)守護、質(zhì)量門禁等等，并且諸如于 review 的工作是由機器完成的。
云開發(fā)
好了，看到這里不容易。因為剩下的內(nèi)容已經(jīng)不重要了。
什么是云開發(fā)？
再一次地，讓我們看一下定義：
云開發(fā)，是一種生于云上的閉環(huán) + 代碼化的軟件開發(fā)方式。它可以讓業(yè)務(wù)人員、開發(fā)人員、運營人員等在同一個云端共同協(xié)作、透明化地完成整個軟件的生命周期（需求、設(shè)計、編碼、構(gòu)建、部署、運營），而非相互隔離，又或者是借助于多個軟件才能完成工作。
于是乎，它不同于云主機 / 遠程主機開發(fā)模式，只需要一個瀏覽器 / 客戶端 / IDE，便可以在線完成：
實例化需求
架構(gòu)、交互的設(shè)計
編碼的代碼化
自動集成與構(gòu)建
無環(huán)境部署
人工智能運營
舉起我的炒板栗：
（調(diào)試）輸入一個 console.log 或者 fmt.Println 便可以在生產(chǎn)環(huán)境對應(yīng)地打出日志。
（需求直接上線）改一個 Icon 的需求，在圖標上傳到 Kanban 的時候。NLP 后，自動提交到代碼庫，部署到生產(chǎn)環(huán)境。
（代碼創(chuàng)建需求）把默認字體的色彩，由 #000 改成 #384452 的時候，能反觸發(fā)對應(yīng)的需求變更——不過就是 commit message，反向地創(chuàng)建需求嘛。
（設(shè)計同步）模型上添加一個新的字段，對應(yīng)的完成前端、后端模型的自動化更新。
（代碼構(gòu)建同步）新的分支，新的 pipeline，用完即刪。
……
它基于這么一些原則：
代碼化優(yōu)于過程化數(shù)據(jù)；
流程自閉環(huán)優(yōu)于交互；
度量內(nèi)建優(yōu)于可視化。
要的就是這么簡單，對于開發(fā)來說，只是對應(yīng)于領(lǐng)域建模、詳細設(shè)計、填空式開發(fā)等。
如何構(gòu)建云開發(fā)平臺？
成熟度模型
就定義來說，我們可以將其劃分為五個階段：
具備基本的遠程編程能力及自動化部署。即代碼無需在本地
在云端能完成軟件開發(fā)的完整生命周期。能在云端完成所有的軟件開發(fā)的工作，并且配套
云開發(fā)平臺上的云開發(fā)平臺。（自舉）
借助于代碼化的方式，將軟件開發(fā)的每一個步驟都變成代碼
實現(xiàn)開發(fā)全流程的自動優(yōu)化。如自動化的藍綠部署，自動化選擇方案，自動化優(yōu)化。
無人編程。Human Over
第一個階段。靠人海戰(zhàn)術(shù)就可以實現(xiàn)了。
第二個階段。依賴于抽象軟件開發(fā)模式。
第三個階段。證明自己，體力勞動。
第四個階段。進一步抽象軟件開發(fā)。
第五個階段。抽象人工部分，智能完成。
所以，嗯，大概要 N 的時間才能完成這個系統(tǒng)的設(shè)計。畢竟，云開發(fā)是一個復(fù)雜問題，我們需要不斷拆解系統(tǒng)，結(jié)合微架構(gòu)、代碼化、協(xié)作設(shè)計三個核心要素，以免我們在歷史的長河中消失。
云開發(fā)平臺基石
雖然，我一直在強調(diào)實現(xiàn)只是一個細節(jié)，但是還是得大致了解一下實現(xiàn)機制。
集成開發(fā)環(huán)境
編碼環(huán)境 + 設(shè)計環(huán)境。
微信小程序、支付寶小程序、在線 Web IDE，VS Code / Monaco Editor 幾乎已經(jīng)當前成為了定制編輯器 / IDE 的最好選擇。這樣一看，JetBrains 再不努力，可能會失去未來，就像當年的 Delphi 一樣，笑~。
這方面的技術(shù)在業(yè)內(nèi)已經(jīng)相當成熟了，不就是加一些插件嘛。
不過呢，它們只是在堆砌一些功能，缺乏閉環(huán)上的設(shè)計：
如你所知的提交信息規(guī)范是一種形式，它可以關(guān)聯(lián)到需求；如你所知的領(lǐng)域建模是一種形式，讓代碼關(guān)聯(lián)到設(shè)計上。
基礎(chǔ)設(shè)施
盡管，在文章開頭的時候，我說了基礎(chǔ)設(shè)施不重要。但是到真正需要實施的時候，我們不得不強調(diào)它的重要性。我們需要的東西有：
而圍繞在它背后的是各種模式的提煉。
模式提煉
無論是在哪個行業(yè)，值錢的東西在于原則與模式。原則與模式是用來快速提升能力的方式，換句話來說，就是讓新手能像以大牛一樣的方式工作——盡管會濫用模式。所以：
這些是核心所在，抽象、提取、模式化。
全流程閉環(huán)
如你所猜想的一樣，構(gòu)建這樣一個平臺的難點，不在于實現(xiàn)功能，而在于設(shè)計。只需要保證在當前階段的信息，能夠傳遞到下一階段即可，而不在于你使用什么工具。
你可以使用 Jira、Trello、Mingle 或者基于 Git + DSL 的方式，只需要保證它們能關(guān)聯(lián)到下一階段，即可。一步步往下，將信息關(guān)聯(lián)到設(shè)計、代碼、構(gòu)建、部署、運營，運營再反應(yīng)到需求上，就能完成上的設(shè)計。
So？
原型設(shè)計與關(guān)鍵因子
作為模式的拆解，我做了一個簡單的分級，以便于一步步實現(xiàn)整個系統(tǒng)：
需求
事實上，采用諸如 Cucumber 一樣的 Given-When-Then 三段式設(shè)計就夠了。所以在我的 story 工具里，利用了注釋作為額外的信息擴充。Cucumber 使用的 DSL 已經(jīng)有豐富的：
# id: OGr9CObWR
# startDate: 2019-11-21T23:44:27Z
# endDate: 2019-11-21T23:44:27Z
# priority:
# status:
# author:
# title: add executable bin file
# language: zh-CN
@math
功能:add executable bin file
場景:
假設(shè):
當:
并且:
那么:有了這個設(shè)計，我們可以將這個設(shè)計結(jié)合到我們的下一步設(shè)計中。
設(shè)計
其實 UML 本身也是一個不錯的原型，只需要創(chuàng)建一個 DSL 將其中的一部分轉(zhuǎn)成 UML，再結(jié)合一下 UI 上的 DSL 便能實現(xiàn)流程上的設(shè)計：
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
}最近，我們在做一個對應(yīng)的架構(gòu)設(shè)計平臺，結(jié)合我的 https://github.com/phodal/design 用于代碼生成設(shè)計，設(shè)計轉(zhuǎn)為代碼。
代碼
代碼生成并不是一件新鮮的事物，有大量的人在做大量的事件。編寫一個 DSL，用這個 DSL 結(jié)合編程語言描述 DSL 來生成不同的編程語言，這便是我最近在做的事情之一。它并不復(fù)雜，只是繁瑣。
嗯，我花了很多時間在設(shè)計這個步驟的兩個 DSL，其中一個是生成語言的 DSL，一個則是獨立的編程 DSL。
與此同時，對于代碼來說，我們關(guān)注于：驗收標準和適應(yīng)度函數(shù)。
驗收標準
設(shè)計生成代碼，代碼反應(yīng)設(shè)計
DSL 生成代碼
適應(yīng)度函數(shù)
軟件質(zhì)量門檻
自動化架構(gòu)守護
自動化測試生成（回錄）
系統(tǒng)演進設(shè)計
借助于此，我們才能承上啟下。
構(gòu)建
對于持續(xù)集成來說，需要手動去配置是一個糟糕的事情。所以，我們 Jenkins 使用了 Pipeline as Code 來抽象流水線的構(gòu)建。但是，它沒有真正解決問題，因為現(xiàn)實的軟件開發(fā)是非常復(fù)雜的。對于一個項目來說，它存在過多的分支，不同的構(gòu)建。所以，真正意義上的持續(xù)構(gòu)建，應(yīng)該采用諸如于 Pipeline as Pipeline 這樣的方式。
部署
事實上，DevOps 技術(shù)已經(jīng)足夠的成熟，我們已經(jīng)能實施相關(guān)的步驟：
部署自動化
部署代碼化
提交即上線
部署自治
代碼質(zhì)量的控制，自動化測試，決定了部署成熟度。
運營
這一步，我還不是非常擅長，以我有限的經(jīng)驗來看，現(xiàn)有的工具就夠了。唯一要做的事情是，收集數(shù)據(jù)，抽象模式，構(gòu)建 DSL，串聯(lián)起來。
運營可視化
運營中心化
代碼化運營
運營需求化
需求 -> 代碼 -> 運營，運營反饋需求。
云開發(fā)平臺成熟度模型
嗯，看標題就夠了。
Level 1：可追述、電子化
Level 2：全流程閉環(huán)
Level 3：云平臺上的云平臺
Level 4：代碼化云平臺
Level 5：自動化優(yōu)化流程
Level 6：human over
結(jié)論
最后，再讓我們回到這張圖上：
這就是核心所在。
哦，對了，做平臺是一件苦逼的事情。
作者簡介：黃峰達（Phodal），ThoughtWorks Senior Consultant，CSDN 博客專家。長期活躍于 GitHub、CSDN，專注于物聯(lián)網(wǎng)和前端領(lǐng)域。出版著作《自己動手設(shè)計物聯(lián)網(wǎng)》，以及《Growth：全棧增長工程師指南》等六本電子書，并譯有《物聯(lián)網(wǎng)實戰(zhàn)指南》。
【END】
