中臺之後，便是無程式碼程式設計。
規模化的組織，經常要面臨這樣的挑戰：每個應用的基礎設施是相同的，部分的程式碼也是相同的，甚至於它們可能只是資料模型不同而已。結果卻導致了，他/她們要一次又一次地重新編寫一個應用。
對於一個新的應用而言，它需要對接大量的三方（非自己團隊）服務。服務之間的不斷變化 ，導致了對應的使用方也需要發生變化。不斷變化的業務，導致了前臺的設計不斷變化。為了應對快速談的的前臺服務，後臺便誕生了中臺，以提供快速的響應能力。而隨著中臺進一步沉澱，從某種形式上趨於穩定，而前臺仍然需要快速地響應能力。
於是乎，作為一個前端開發人員，我們不斷提煉和複用程式碼，想著的模式在上一篇文章 減少程式碼量的 7~8 種方式 中提到了：
- 腳手架
- 元件庫
- 模式庫
- 模板和模板應用
對應的，我們還建立了一系列的 CLI、工具集、程式設計器外掛以及設計系統，以完成整個系統的快速開發。然而，我們還缺少一套有效的工具，來統一化的管理這些工具。
換句話來說，就是：我們需要一個前端的中臺，它便是無程式碼/低程式碼程式設計。
什麼是無程式碼程式設計？
無程式碼/低程式碼是一種建立應用的方法，它可以讓開發人員使用最少的編碼知識，來快速開發應用程式。它可以在圖形介面中，使用視覺化建模的方式，來組裝和配置應用程式。開發人員可以直接跳過所有的基礎架構，只關注於使用程式碼來實現業務邏輯。
當然，從開發人員的角度來看，降低程式碼量，可能是：
- 框架本身處理了複雜性。畢竟 “複雜度同力一樣不會消失，也不會憑空產生，它總是從一個物體轉移到另一個物體或一種形式轉為另一種形式。”
- 程式碼生成減少了工作量。大量的複製、貼上需要更多的時間。
流程
只是憑藉這個概念，我們是無法理解無程式碼程式設計的。於是，我畫了一張圖來展示相應的架構和流程：
依照我的觀點來看，我將無程式碼程式設計分為了兩部分：
- 用於構建 UI 的編輯器——一種線上的拖拽式 UI 設計和頁面構建工具
- 用於編寫業務邏輯的流編輯器——通過流程式設計的方式來編寫業務程式碼（多數是對於資料的處理）
UI 程式設計器。為了設計出我們的 UI 構建器，我們需要準備好一系列的基礎設施：
- UI 程式設計器。用於拖拽式設計 UI。
- 空白腳手架。一個帶有完整的應用生命週期的專案，但是它是一個空白的專案——用於我們在構建 UI 的過程中，隨時隨地的新增元件和程式碼。
- 設計系統。我們需要一個完整的元件庫，大量的頁面模板，以及一定數量的模板應用，減少相應的開發工具量。
- 程式碼片段集。它將設計系統中的元件庫進一步例項化成程式碼段，在完成編輯後通過 CLI 來動態編輯程式碼。
- DSL（領域特定語言，可選）。中間生成物，用於隔離框架與設計。
流程式設計器。隨後，為了在
- 流程式設計器。用於拖拽式、輸入編寫業務程式碼。
- 後端服務。如果不能提供現成的後端服務，則需要擁有一個標準的 API 規範，以及相應的 mock server。
- 模式庫。包含相應的業務處理程式碼，如通用的登入、資料獲取、UI 互動等。
- DSL（領域特定語言，可選）。同上
當然了，我們還需要能實時預覽構建出來的應用。隨後，我們執行了構建，而後構建出了一個半成品應用。開發人員只需要在它的基礎上開發應用即可。而在開發人員開發的過程中，我們可以設計一系列的工具，來幫助開發人員更快速地構建應用。
- 編輯器外掛。包含設計系統、模式庫等的自動完成程式碼，以及組織內部常用的程式碼庫。
- 除錯工具。對於混合型別的應用而言，我們還需要一個開發工具來快速構建應用。
從上述的流程上來看，無程式碼程式設計還具有以下的特點：
- 拖放式介面。又或者是視覺化模型——基於節點和箭頭
- 基於視覺的設計。
- 可擴充套件的設計。如對於外掛、外掛商店，社群等一系列的支援。
- 跨平臺功能。支援 PC Web 應用開發，支援移動應用構架等。
- 強大的部署後。即平臺包含著整個應用的生命週期。
- 擁有豐富的整合支援。可以隨意的找到需要的元件，以及對應的後臺服務。
- 配置化。它也意味著大量的自定義配置。
- 自制的領域特定語言（可選）。用於構建時優化。
優缺點
相應的，它具有以下的一些特點：
- 高效。不用多說，節省時間和開發成本。
- 有限的 Bug，安全性。
- 低成本。其所需的預算非常有限。
- 易用（取決於設計）。
- 開發速度更快。
- 開發過程中的 AI 。
- 維護成本低。
對應的相應的缺點有：
- 仍然需要程式設計技能。
- 受限的自定義能力。
- 可擴充套件性成了新的問題。
- 整合受限。
就當前而言，低程式碼開發平臺通常分為兩大類：
- 對於外部：製作簡單的產品，如網路移動應用程式
- 對於內部：為您的團隊或企業建立業務應用程式
諸如只使用 CRUD、表單、驗證、簡單聚合、分頁等簡易的服務。最常見的例子就是表單構建了，諸如金資料這樣的應用，便是可以直接通過拖拽元素來生成，相應的開源實現有 jQuery Form Builder。對於開發人員來說，我們只需要定義好資料模型，再通過拖拽來決定元素的位置即可。從這種角度來看，只要能使用 Serverless 構建的應用和服務，都可以直接使用低程式碼開發模式。
開發流程對比
從我們的理解來看，傳統應用的開發流程是：
- 分析、設計、確認、規劃需求
- 設計系統架構
- 搭建前後端專案。選擇技術棧、從零開始搭建或者從腳手架中建立。
- 搭建持續整合。
- 建立線框圖和高保真原型。
- 設計資料模型，定義前後端契約，即 API URI、方法、欄位等。
- 前後端實現業務邏輯。
- 前端實現 UI 頁面。
- 整合第三方後端服務。
- 功能需求測試（DEV、QA、ST、UAT）
- 跨功能需求測試（安全性、效能等）
- 部署到生產環境。
而，低程式碼開發流程：
- 分析、設計、確認、規劃需求
- 選擇需要的第三方 API
- 在可視 IDE 中繪製應用程式的工作流程、資料模型和使用者介面。
- 連線 API——通常使用服務、函式發現。
- 編寫業務邏輯（可選）。手動程式碼新增到前端或者自定義自動生成的 SQL 查詢。
- 使用者驗收測試。
- 部署到生產環境。
從步驟上來看，無程式碼程式設計少了幾個步驟。這些步驟都因為大量豐富的內部系統整合，而變得非常簡單。
適用場景
就當前而言，無程式碼程式設計實際上是一種高度的場景預設的模式。因此，它存在一定的適用場景：
- 模型驅動開發。
- 快速 UI 構建。
- 極簡的業務功能。使用這樣的工具，也意味著，我們對於互動和可
- IT 資源受限。在資源受限的情況下，能快速開發出符合業務需求的應用最重要。
而從流程上來看，對於一部分的應用來說，我們並不能實現無程式碼程式設計——存在一些業務上的不同之處。因此，多數場景之下，只是實現了低程式碼程式設計。
若是想真實的無程式碼程式設計，則需要一些更特定的場景：
- 設計表格（輸入資料）
- 建立報告（組織資料）
- 常規排程和自動化過程（操縱資料）
更多的場景正在探索中。
無程式碼程式設計的挑戰
無程式碼程式設計，除了需要準備好上述的一系列基礎設施，還不可避免地會遇到一系列挑戰。
- 誰來寫這部分程式碼？
- 客戶端的基礎設施準備。
- 服務端的服務平臺搭建。
- 統一使用者體驗設計。設計出一系列能便利組合的元件，及對應的模板頁面。與此同時，它們還能適應於不同的風格，即有多樣性的主題支援。
- DevOps 流水線設計。低程式碼程式設計，依賴於一系列的自動化工具，以實現構建、除錯、部署以及維護，同時還包含應用的測試。
- 領域語言設計。
- 自動化測試。如果我們的前端程式碼是自動生成的，那麼我們還需要對它們進行測試嗎？這是一個好問題，而如果程式碼是自動生成的，那麼測試也應該是自動生成的。畢竟要在平臺上，編寫大量的自動化測試，以保證平臺的質量。
其中，有一些部分略微複雜一些，我們大概可以探索一下。
誰來寫這部分程式碼？
在我們建立這樣一個平臺和工具時，我們要考慮的第一個問題是，我們這個工具是為誰寫的？
- 沒有程式設計經驗的人。如業務人員，他/她們對於業務系統有著非常豐富的經驗。這也意味著，我們
- 有程式設計知識，但是沒有經驗的人。
- 有一定經驗的開發人員。
- 有豐富經驗的開發人員。對於專業的人來說，自動化就意味著缺少靈活度。甚至與自己編寫相比，他/她們要花費更多的時間來修復生成的程式碼。
顯然，對於相當有經驗的開發人員而言，這個工具並不一定是他/她們所需要的。
客戶端基礎設施
從我的理解來看，它適合於 快速的 MVP 構建，並且生成的程式碼還應該方便修改，而不是諸如早期的 DreamWeaver 或者 FrontPage 這樣的工具。
而與此同時，由於面向的開發人員水平不同，我們所需要做的工具也不同：
- 支援雲構建和除錯。
- GUI 程式設計應用。
- 程式碼生成。
- 設計系統體系構建。元件庫搭建，模板應用建立等。
- …
更難的是，容易讓開發人員能接受程式碼生成。
服務端
對於一個低程式碼平臺而言，它對應的後端應該：
- 大量可用地現有服務。身份驗證、安全性、推送能力、地圖等等
- 快速構建出後端服務。若是有內部 Serverless 或者 FaaS 方案，可以說是再好不過了。
- 方便與第三方服務整合。
- 靈活性。支援多語言等。
統一的後端服務 API，對於後端服務來說，我們需要一個通用的正規化。所有的 API 應該按照這樣的正規化來設計。不過，作為一個 API 的消費方，我們可能沒有這麼大的權力，但是我們可以採用裝飾器模式，即封裝第三方 API 成統一的方式。為此，我們採用的方式，仍然是：
- 契約。諸如 Swagger UI，它可以直接建立一個簡易可用的服務。
- BFF。即我們一一去按我們的需要，去封裝這些第三方應用。
- 查詢語言。與自己編寫 BFF 相比，更簡單的方式是採用：GraphQL 這樣的後端查詢語言，便捷性更高、模式更加靈活。
在開發前的設計期裡，我們需要首先設計出對應的領域模型。
領域語言設計
低程式碼環境使用（圖形）建模語言來指定整個系統、產品的行為。它意味著：
- 將資料結構、領域模式應用到程式的各個層級中。
- 將業務規則、決策融入到應用中（層級）。
這也就意味著，我們需要設計一個模型語言。而它對於我們而言，實際上是領域特定語言（DSL）。如下是一個簡單的 DSL 示例，用於描述使用到的元件：
{
'style': '',
'id': 2,
'blocks': [
{
'content': {
'content': 'content',
'title': 'hello'
},
'type': 'card'
}
]
}
複製程式碼除此，我們還需要設計對應的佈局 DSL，諸如於：
H:[circle1(circle1.height)] // set aspect-ratio for circle1
HV:[circle2..5(circle1)] // use same width/height for other circles
H:|[circle1]-[circle2]-[circle3]-[circle4]-[circle5]|
V:|~[circle1..5]~| // center all circles vertically
複製程式碼最後，我們還需要將流程式碼，轉換為真實的專案程式碼。三種型別的 DSL 結合下來，都不是一個輕鬆的工具。
原型設計
寫好現有的元件，通用型介面。如常見的登入介面，。對於使用登入介面的業務來說，它們只關心三部分的內容：
- 成功登入。
- 取消登入。
- 登入失敗。對於客戶端而言，可以視為取消登入。對於服務端來說，則可能是密碼錯誤、使用者名稱不存在、賬號被鎖定等。
對應於以上情景，又有一些通用的邏輯處理：
- 登入成功。儲存 Token，並返回歷史頁面。
- 登入失敗。彈出一個自定義內容的提示框。
這些程式碼是相似的。
前端原型
在一些簡單的前端應用裡：
- 模板。只是在使用這些模板，再為這些模板設定相應的屬性，繫結對應的值。
- 資料。其過程都只是在各種儲存變數的值，並 CRUD 這些變數的路上。為此，我們需要一個資料處理的管道架構設計，用於處理這些值。
- 函式。事實上，我們的所有函式都只是一些管理函式，只用於處理這些對應的邏輯。
這些常見的功能都可以做成一些元件，它們對於某些應用來說，程式碼相應的重複。
- 無限載入頁面。只需要繫結上 API，再控制一下元素的顯示與隱藏即可。
- 表單。定義好欄位即型別，對應的前後臺邏輯都有了。除此，我們還需要為它們自定義好常見的規則，如正規表示式。而一旦表單之間有聯動，那麼這個元件的設計就更加麻煩了。
- 卡片式元素。
- 表單和表格展示。
- 常見圖表。事實上，已經有一系列的圖表工具了，我們只是在它們在基礎上，進行了二次封裝而已——使得它們可以變成領域語言的形式。
- 高階的響應式佈局。與每個應用獨立開釋出局不同的是，低程式碼平臺需要提供一套強大的自定義、響應式佈局設計——即要滿足移動端的通用模式，還要滿足桌面版的通用模式。如對於大量資料來說，桌面端使用的是 Pagination，移動端使用的是無限滾動。
後端原型
事實上，對於後端來說，低成本平臺意味著，程式碼生成及服務生成。而服務本身是有限的，既然是業務上發生了一些變化，後端服務也可能並不會發生變化。
它也意味著：
- 微服務化。每個後端服務要儘可能的小。
- API 規範化。即採用統一的 API 格式，接受統一的許可權管理
- 大量的 API 服務。
- 快速整合第三方服務方案。整合第三方服務是開發應用不可避免的情況。為了應對這個問題，我們需要做準備好對應的建立服務邏輯，傳入第三方服務所需要的引數，便可以直接生成我們的轉發服務。
那麼，問題來了，既然如此，我們是否能提供一個定製的工具呢？讓每個人可以建立自己的元件流？
答案，顯然是可以的。
概念證明
於是乎，在我最近設計的 PoC （概念證明）裡，採用的是 Anguar 框架。相應的基本思想如下：
- 使用 Material Design 作為元件庫，使用 CDK 的 Drag 來實現拖拽功能。每個拖拽的元件，稱為 element（元素），由 ElementDispatcher 由根據資料生成對應的元件。可拖拽的部分由兩部分組成：佈局 + 元素。
- UI 構建完後，生成對應的 DSL，目前採用的是 JSON。畢竟資料結構是最簡單的領域特定語言。
- 藉由 Angular Schematics 解析這部分的 DSL，來生成相應的專案程式碼。
其它
相關開源專案：
- 拖拽式 Web 建造工具：grapesjs.com/
- 基於 Flow 的程式設計工具：noflojs.org/
- DSL 佈局生成器：github.com/ijzerenhein…
- 視覺化資料流編輯器：github.com/Gregwar/blo…
- 基於 React 的內容生成器：github.com/vigetlabs/c…
參考資料：