開發了一個又一個項目，擼了一個接一個的輪子，已然習慣了各式各樣的軟件開發流程。每一種模式自有自己的優缺點，也各自有自己的適用場景。而隨着歷史車輪的緩緩前進，開發流程都在不斷地演進，以致於諸多的人都在想：未來的開發是怎樣的？
我亦是如此。（PS：為了讓大家更好地理解此文，我先説一下我相關的一些上下文）
2017 年，為了解決微服務和 BFF 的最後一公里問題，我開始研究 Serverless，並寫下了國內第一本 Serverless 相關的電子書《Serverless 應用開發指南》。過程中，有幸進入了一個 APP 插件化的項目，順帶學會了移動端的 “微服務” 相關的思想。
隨後在 2018 年，便思考着在前端如何去做微服務，寫下了國內最早的微前端電子書《微前端的那些事兒》，後來出版《前端架構：從入門到微前端》。自此，大抵説得上是掌握了應對大型應用和輕量級應用的架構設計方案。
2019 年初，我開始思考開發流程的各種自動化，便基於自身的經驗和開源社區的項目，構思了低代碼/無代碼系統架構的設計，也就有了國內最早的低代碼架構設計的文章《無代碼編程》。隨後，我不斷去探索嘗試一些更好的解決方案，其中一個方案便是《雲研發：研發即代碼》。（PS：不好意思走得太快了）
裝逼到此結束。
雲研發路線圖
有了上述的各種蛛絲馬跡，我想很多人已經有了一個大體上也能有點印象：
這個圖略微複雜一點（有些線也沒劃上），它展示的是組織內前後端能力複用的過程。而雲開發、低代碼之所以能在某些組織內落地，很大一部分原因也來自於：持續性的能力複用。有了這張圖，我們可以很容易推層出其中的實施過程。
按照這個路線圖，我把整個過程劃分為四部分：
1. 雲開發。即軟件的開發流程都可以在雲端完成，所有相關人員只需要一瀏覽器就能完成工作。
2. 低代碼。需求的變更，可以影響到代碼的生成。
3. 萬物代碼化。由低代碼到無代碼、雲研發的關鍵技術。
4. 雲研發。某個需求的變更，能直接完成部署。如需求對數值的更改，能直接映射到代碼的修改，並上線。
如果你還沒有放棄此文的話，讓我們繼續往下走。
實施過程
總體來説，我把實施過程劃分為了四步：
1. 構建能力複用平台
2. 精心設計膠水式框架及能力
3. 完成生命週期閉環：定製膠水語言
4. 建立雙向反饋，以持續優化：同構
事實上，如果你熟悉 DevOps 的實施流程的話，它與這個實施過程還是相似：
1. 閉環
2. 建立反饋
3. 持續優化
稍有有點不同的是，雲研發的建立過程要更為精細化許多。
1. 構建能力複用平台
繼續從上圖中的左下角的方塊講起。近幾年，中台十分火熱，不斷有新概念，也不被地被置疑。我並非一箇中台專家，從個人的角度來看待，中台更像是一個垃圾回收站。而受部門牆的影響，大型組織下的部門的核心業務，到底不會交由中台來管理？便是另外一個問題。
但是不論中台的結果怎樣，它做了一件有了不起的事情，引發了管理者對於服務複用的思考。提升複用率，意味着提升組織的整體效能，減少了一定的內部浪費。
同樣的，這種複用的機制，也出現在組織內的前端基礎建設、APP 基礎設施建設等等。它們出現的本質就是為了提升組織級的開發效率，減少創造重複的輪子。
所以，落地組織級別的雲研發有一個很大的前提是，能實現組織內的技術能力複用。這裏的組織是相對的，因為大公司的某一部部門本身類似於中型公司的開發能，以此類推。所以，在公司這一級別上，他們可能會有各種重複的輪子，其主要受限於各自的場景及未來的假設之間的差異。
2. 精心設計膠水式框架及能力
技術能力複用，意味着：我們可以把上述的每個技術能力視為一個個的樂高。在構建應用的時候，我們只需要學會如何去組裝它們即可。而為了組裝它們，我們需要：
1. 編制它們之間的粘合規則。
2. 設計粘合適配層，用於防腐和適配未來的新架構。
3. 製造各種粘合劑，以便於連接系統的各個部分。
因此，我們還需要一些支持快速粘合的技術作為支撐：
後端接口快速適配。從過程中有，微服務 -> BFF -> Serverless -> Serverless Components，直到把基礎設施弱化
前端組件快速複用。這一點上便有：組件 -> 微前端架構 -> Web Components
APP 快速接入。從技術上來説有：小程序、APP 插件化、H5 等
一旦完成了這些技術能力，就可以關注於如何完善膠水層。
3. 完成生命週期閉環：定製膠水語言
只憑上述的兩步，我們大可以完成一個簡易的雲研發系統。但是而為了系統的未來演進，還需要一些更先進的能力，以便於我們解耦各個開發過程。這樣一來，我們可以輕鬆更換其中的組件，而不至於因為組件的替換，引起系統架構的巨大變化。
譬如，我們已經有了 Web 部分的快速開發，現在要支撐起 APP 的快速開發。我們不需要一起改動上下游的代碼，只需根據定義好我們的接口，各自的改動都是獨立的不受影響的。哪怕我們是通過採購的供應商，也可以輕鬆地替換供應商，避免供應商鎖定。這樣的接口包含了結構和數據，所以我傾向於 DSL（領域特定語言）來完成。
通過在線 IDE 隱藏膠水細節。
創建 DSL（領域特定語言）連接生命週期的兩兩節點。（PS：節點間的 DSL 是不同的）
建立起系統的閉環。如通過運營數據節點裏，可以直接創建用户故事，來優化系統
儘管這些膠水語言會在前期增加系統的複雜度，但是它無往而不利。
4. 建立反向反饋，以持續優化：同構
有過使用 DreamWeaver、WinForm 等拖拽式開發經驗的開發人員，都對這種形式的低代碼開發有點反感。其中的主要因由有，當我修改完代碼之後，無法反饋到設計上。也因此造成了一個問題，拖拽只適用於設計階段。當後期代碼發生變更時，便無法進行演進。
解決這個問題的辦法，除了更新代碼生成機制，還有一種方式是通過 DSL （領域特定語言）來建立反向反饋。如設計專用的工具，來將代碼的修改同步設計上，同時改變架構設計的 DSL 代碼。換句話來説，通過 DSL 來建立起步驟之間的橋樑。
架構同構。即已完成的代碼進行解析，其生成的架構設計與模型設計是一致的。
設計同構。對已設計的前端組件進行解析，其與 UI 設計圖生成的模型是一致的。
需求同構。對已編寫的測試用例篩選解析，其與原始的需求是一致的。
……
簡單地來説，我們要保證系統的各個節點的一致性。最終所呈現的結果是：如果節點間不一致的話，那麼只能是原始需求有問題。為此，開發人員進行的代碼修改，應當是通過 DSL 的形式一步步回溯，直至自動修改了需求，或者映射到需求的問題上。
所以，需要把生命週期的每一個過程都代碼化。
三個要素
在那篇《雲研發：研發即代碼》 中，我們介紹了雲研發的三要素，在這裏仍然是我麼有和的。
1. 微架構：膠水。微架構，即以模塊化的組合方式協同構建大型應用（前端、後端、APP等）的架構方式。每個微應用都可以獨立開發、獨立部署、獨立運行，對應的替換的方式有模塊化、子模塊的方式，微服務、APP 插件化（獨立構建、獨立運行）、微前端等。
2. 代碼化：膠水標準化。代碼化，即通過創建領域特定語言來描述某一特定的事物或流程，以用於描述它在數字世界的孿生。
3. 協作設計：文化。從諸多組織實施 DevOps 的過程，我們就可以看到：要打破部門牆並不是一件容易的事。這事實上，這才是雲研發的成功關鍵，要讓打通生命週期，意味着要打通一個個的部門牆。讓各方達到目的一致，怕是得由各種績效來保證。
有了這些理論與要素之後，剩下的就是一步步的往上堆砌代碼了。
雲開發
隨着持續部署、DevOps 在各個企業的推進，越來越多的企業已經有完善的基礎設施，軟件開發團隊只需要一個在線的 IDE，就可以完成開發工作，這就進入了雲開發時代。
什麼是雲開發？
在過去的一二年裏，有越來越多的雲廠商，選擇了雲開發的模式。值得注意的是，我們在這裏定義的雲開發和國內雲廠商定義的雲開發略有不同。國內雲廠商所針對的是輕量級的應用開發，這裏我們所針對的是所有場景下的雲開發模式。換句話來説，支持輕量級應用開發是一個必由之路（MVP）。
對於一個雲開發產品來説，它具備了這麼一些關鍵要素：
1. 雲 IDE。
2. 分鐘級部署的基礎設施
3. 生命週期打通
依舊，最難的仍然是生命週期打通。
1. 雲 IDE
在這裏，我們所討論的是雲 IDE 集成開發環境。它意味着，我們需要將其作為入口，封裝各種細節。也因此，它並不僅僅是一個編輯器能完成的。
只是呢，我們可以基於成熟的開源的雲編輯器來完成基礎部分：
VSCode Online（業內：騰訊雲 Coding）
Eclipse Theia （兼容 VS Code，業內：華為 DevCloud）
Monaco Editor（VS Code 基於 Monaco）
隨後，通過插件來擴展我們所需要的各種能力，打通一個個的環節。
2. 分鐘級部署的基礎設施
在雲開發的模式下，我們需要多種模式的快速部署：
輕量級場景。如 BFF / Serverless 小程序
開發態容器化（可選）。即在瀏覽器修改代碼時，有一台類本地的環境在後台運行，並實現快速預覽。
常規部署。
這些模式都已經具備一定的成熟度，只是需要基礎設施來配套上開發者的手速。
3. 生命週期打通
在我們解決了代碼問題之後，我們還需要做各種集成，以保證：
1. IDE 支持與需求的相關聯。
2. 代碼與版本控制系統的關聯。
3. 臨時的流水線與部署環境。
……
當然了，各個地方有了 API 之後，就不是問題了，唯一要考慮的可能是服務器成本。而這個成本呢，可以從開發機器上補回來。
如何驗證雲開發是成熟的？
如何驗證一個雲開發平台是成熟的？
關於這一點非常的簡單：自舉—— 它用於雲開發的代碼使用雲開發環境完成的。
低代碼
雲開發和低代碼並沒有太多的聯繫，既然我們不在雲環境開發，依舊可以選擇低代碼技術。唯一有意思的是，它們所需求的基礎設施是相似的。既然如此，那麼為什麼我們在選擇架構的時候，不多走一步呢？
什麼是低代碼？
PS：關於『無代碼編程』 的更多內容可以在我的 GitHub 上查看如何設計：
https://github.com/phodal/lowcode 。
這裏我們只是介紹它的幾個關鍵因素：
1. 生命週期自動化
2. 流程代碼化、數據化
3. 持續完善的基礎設施
過程同樣不復雜，但是它的場景比較有限，遠不如雲開發來得實在一點。不過，對於這些有限的場景來説，低代碼有非常大的優勢 —— 特定的場景，模式是特定的，能大大節省成本。
1. 生命週期自動化
低代碼最吸引人的一點是，拖拉拽就可以快速預覽和上線。這意味着，在這種模式之下，融合了軟件開發生命週期幾個步驟，需求、設計、編碼、構建、部署、運營（ 運維），並實現了部分的自動化。
為此在這個要素上，它同理於雲開發模式，只是要求的範圍更大。所以，我們需要打通更多地環節，才能實現更多的自動化。
2. 流程代碼化、數據化
在低代碼的流轉過程中，系統需要存儲中間態的結構化數據，或者是領域特定語言編寫的數據，以解耦不同環節。
對於一個組織而言，如果計劃購買一個低/無代碼編程平台，那麼需要一箇中間態的語言或者數據。我們已經在先前解釋了其目的，這裏就不重複介紹了。
3. 持續完善的基礎設施
在實施低代碼時，它需要大量的基礎設施，如：
大量快速可用的後端 API
分鐘級部署後端 API
UI 組件集豐富
……
除此，過程中還會有各種的新需求接入，因此還需要不斷地完善：
方便與第三方服務集成。
靈活性。支持多語言等。
對應基礎設施接入機制。
低代碼的複雜度
我們嘗試降低一部分開發者得難度的同時，也意味着我們需要將這部分複雜度拉由自身來不來解決。
萬物代碼化
代碼化是我們實現從低代碼到無代碼的一個過程，關於如何實踐其的代碼化，可以關注我後續的文章。在那一篇《雲研發：研發即代碼》中，我們把其劃為了六步：
1. 需求代碼化。使用 DSL 描述需求，並能轉換為設計 DSL。
2. 設計代碼化。完善設計 DSL，併成架構模型和 UI 設計。同時，實現設計結果到需求的反饋。
3. 代碼代碼化。創建通用語言，以生成不同語言的代碼。同時，代碼來反饋到設計。
4. 構建構建化。代碼提交自動創建構建，構建自動銷燬。
5. 部署代碼化。代碼描述部署方式，並實現各個環境的自動化、自部署。
6. 運營代碼化。所有運營、運維操作都可以通過 DSL 來描述；根據線上反饋結果，能自動創建需求優化。
為了配合它，還需要其它的代碼化模式：
文檔代碼化。
合規代碼化。
……
嗯，這就是人生的樂趣。所以，是時候準備招一些能造飛機的程序員了。從畢業生中培養，或許是一個更好的主意。
雲研發
最後，讓我再稍微總結一下這篇文章。
什麼是雲研發
它需要我們在這篇文章裏提到的一系列要素，並整合起來：
1. 代碼化。
2. 全生命週期打通。
3. 協作式設計。
所以，整體的實施過程便是：
1. 具備基本的遠程編程能力及自動化部署。即代碼無需在本地
2. 在雲端能完成軟件開發的完整生命週期。能在雲端完成所有的軟件開發的工作，並且配套
3. 雲研發平台上的雲研發平台。（自舉）
4. 藉助於代碼化的方式，將軟件開發的每一個步驟都變成代
5. 實現開發全流程的自動優化。如自動化的藍綠部署，自動化選擇方案，自動化優化。
6. 無人編程。Human Over
無代碼
真正的無代碼，可以使得碳基生物已經不需要存在了。
再回顧一下這圖：
其它
就這麼多，湊點字數到 5000。
示例代碼：
https://github.com/phodal/story
https://github.com/phodal/design
https://github.com/phodal/code
https://github.com/phodal/chapi