無代碼程式設計

中台之後，便無代碼。

規模化的組織，經常要面臨這樣的挑戰：每個應用的基礎設施是相同的，部分的代碼也是相同的，甚至於它們可能只是數據模型不同而已。結果卻導致了，他/她們要一次又一次地重新編寫一個應用。

對於一個新的應用而言，它需要對接大量的三方（非自己團隊）服務。服務之間的不斷變化，導致了對應的使用方也需要發生變化。不斷變化的業務，導致了前台的設計不斷變化。為了應對快速談的的前台服務，後台便誕生了中臺，以提供快速的回應能力。而隨著中台進一步沉澱，從某種形式上趨於穩定，而前臺仍然需要快速地回應能力。

於是乎，作為一個前端開發人員，我們不斷提煉和復用代碼，想著的模式在上一篇文章《代碼複用到低代碼（上）：提升開發效率的 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 建造工具：https://grapesjs.com/
基於 Flow 的程式設計工具：https://noflojs.org/
DSL 佈局產生器：https://github.com/ijzerenhein/autolayout.js/
視覺化資料串流編輯器：https://github.com/Gregwar/blocks.js
基於 React 的內容產生器：https://github.com/vigetlabs/colonel-kurtz

參考資料：

1. What are Low-Code Platforms? How to Pick the Best Development for Your Business | Process Street | Checklist, Workflow and SOP Software

2. https://medium.com/@stefan.dreverman/decisions-to-take-for-your-low-code-architecture-c0768b606f

3. https://medium.com/@stefan.dreverman/analyzing-coinmarketcap-data-with-neo4j-4930ba0068e1

4. What Is Low-Code?

5. https://medium.com/@stefan.dreverman/starting-a-low-code-application-architecture-13170fcd6fc7

6. https://www. quora.com/What-is-low-code

7. Phodal - A Growth Engineer

無代碼程式設計

無代碼程式設計

什麼是無代碼程式設計？

流程