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