1 引言
在說低程式碼搭建之前，首先要理解什麼是搭建（本文搭建指通過 Web 互動搭建一個自定義的新頁面）。
我認為搭建的本質是提效 ，而提效又分為對研發人員的提效，以及對客戶的提效：
- 對研發人員的提效：相對於 Pro Code 模式，搭建的抽象程度更高，通過犧牲部分定製性換來更高效的開發方式。
- 對客戶的提效：如果使用者有任何搭建 Web 應用的訴求，本質上從阿里雲購買伺服器自建是最普適的方案，但由於專業性要求高，使用者群會很窄，因此需要針對不同使用者的訴求開發定製方案，本質上是通過降低通用性換取更低的上手成本，或者針對某個領域降低上手成本，比如 BI 搭建。
提效雖然被說爛了，但軟體工程發展中，幾乎大部分工作都能歸結到在提效。比如 Vscode、Typescript 提升編碼效率；React、Vue 框架提升程式研發效率；工作臺、可持續整合提升協同開發效率，等等，連微軟都稱自己的使命是賦能全球每一人、每個組織成就不凡，很大程度上就是在說提升整個社會的生產效能。
低程式碼開發平臺（Low-Code Development Platform）則更進一步，允許通過零程式碼或少量程式碼就可以快速建立應用。
從實踐結果來看，完全零程式碼想要覆蓋所有領域是不可能的，而 100% 全程式碼是可以覆蓋所有領域，但研發成本太高，所以介於兩者之間的低程式碼模式是值得嘗試的，因為許多定製場景往往不需要太多高深的程式碼就能搞定，很多複雜邏輯可能幾個簡單的賦值語句、或者條件語句就可以搞定，但如果不允許寫程式碼，其使用成本甚至比寫少量程式碼還要高。
所以搭建本質解決的是提效問題，考慮提效就要看價效比，是使用者學習幾行簡單程式碼後，利用低程式碼平臺效率更高，還是使用者堅持不寫程式碼，使用繁瑣的搭建互動成本更高？有人說程式碼學不會，但簡單程式碼本質和搭建無異，都是對電腦指令的輸入。
還有一些場景將背後複雜度轉移到了其他鏈路，比如資料搭建場景，雖然搭建器沒有低程式碼能力，但卻能實現複雜業務邏輯，原因是這個複雜度被 SQL 層吃掉了，既然複雜度無法消除，那麼哪一層實現的效率更高，就由哪一層去做才是合理的。
2 精讀
低程式碼不僅僅包括 “能寫程式碼”，主要具備如下四個特性：物料接入、編排能力、渲染能力、出碼能力。
物料接入
通用搭建引擎要能夠接入通用物料，即元件自身不關心搭建環境，就可以被搭建平臺所使用。
這需要搭建平臺本身不對元件程式碼實現有入侵，可以對元件暴露的 props 做完全控制，要做到自動識別元件有哪些 props 變數，並根據型別自動推薦編輯表單型別。
除了簡單的文字、數字、下拉框等編輯器 Setter 之外，還有如下幾種複雜編輯器：
- 回撥函式編輯器。
- Node 節點編輯器。
- 文字國際化編輯器。
- 表示式編輯器。
回撥函式編輯器與表示式編輯器都是低程式碼能力的體現，本質上就是利用程式碼描述某個變數值或者回撥。
Node 節點編輯器專門處理節點型別 props 引數，比如 props.header、propder.footer，在程式碼模式描述為元件，在視覺化模式需轉化為畫布下鑽模式進行編輯。
編排能力
編排能力包含頁面編排與邏輯編排，是低程式碼搭建的核心能力。
頁面編排
頁面編排包含很多互動行為，比如拖拽元件、佈局，其中佈局大有可為，比如雲鳳蝶的編輯模式，通過自由拖拽佈局，降低了使用者對 DOM 流式佈局的理解成本，但通過自適應四周邊距模擬出了流式佈局自動撐開容器，容器間碰撞擠壓的效果。
元件與元件形成的組合可以形成一個新的物料，一般稱為模版，比如一個頁面整體也可以稱為模版，這個模版元件的 id 就是頁面根節點的容器元件。但模版也有不能滿足的場景，比如期望元件形成的組合擁有一套全新配置，此時就延伸出低程式碼業務元件的概念，可以認為將模版當作一個整體編輯，可以為模版設定任意的編輯表單，這個編輯表單的值可以透傳到裡面每個元件中讀取。
邏輯編排
邏輯編排是低程式碼能力的核心，在低程式碼引擎中，所有元件引數都可以用低程式碼描述，比如一個 props.color 可以通過顏色選擇器選一個固定值，也可以轉換為表示式模式寫一段程式碼。
這段程式碼除了擁有普通 JS 能力外，還擁有基本狀態管理的能力，即可以訪問當前作用域下的狀態 this.state，而狀態作用域又被容器所分割，容器分為持有狀態的容器與不持有狀態的，一個持有狀態容器內的子元件狀態是互通的。
除了基本狀態管理能力外，還擁有訪問上下文能力，即呼叫引擎一些 API 對畫布進行操作，一般都用於元件回撥，在回撥裡呼叫 this.setState 設定狀態也屬於操作上下文的行為。除了上下文外，還有風格化、國際化、取數等能力可以通過 this 訪問到，其中取數能力專門抽到引擎層做，就是為了讓所有元件與取數邏輯解耦，元件只要拿到資料、isFetching，而不需要真正傳送取數請求。
邏輯編排的另一個維度就是視覺化，將上述低程式碼能力通過視覺化方式表達為邏輯節點與線條，在描述與維護複雜邏輯時有一定優勢。
渲染能力
搭建特殊之處在於，搭建過程幾乎只能在 PC 端完成，但釋出後的應用往往有多端渲染的訴求，比如越來越多的公司使用手機檢視 BI 報表，甚至報表需要嵌入到微信、支付寶小程式中；PC 搭建的表單往往也有大量手機端填報的訴求。
所以編輯和渲染端應該是分離的，但為了保證邏輯一致性，核心程式碼需要複用，所以搭建引擎最好採用 UI 無關的核心 + 業務層擴充 UI 實現方式來做，UI 無關的核心只負責儲存、操作畫布資料，排除設計器附加的一堆 Panel 後，渲染時可以複用邏輯核心往往就足夠了。
元件的跨端複用也是必須的，現在跨端渲染的技術方案也有不少。
出碼能力
LowCode 與 ProCode 互轉也是一大難題，首先互轉的好處不必多說，可以自由的在提效與定製間切換，一定是最理想的開發模式，但實現起來有不少阻礙。
首先是 LowCode 轉 ProCode，這個比較簡單，原因是 LowCode 本身用 JSON 定義，程式碼是 JSON 的超集，從子集轉換到超集本身沒有技術障礙。
從 ProCode 轉換到 LowCode 就麻煩了，一種方式是限定 ProCode 的能力，甚至用一種新的語法替代原生 JS，本質上都是通過將 ProCode 的能力範圍限制住，使得 LowCode 可以接住。另一種方式是不對稱轉換，即從 ProCode 轉換為 LowCode 後會存在功能缺失，或者即便功能不缺失，但 LowCode 無法對應的功能無法在搭建平臺編輯。
執行時能力
只擁有上述低程式碼能力的搭建平臺還是太通用了，雖然功能很強大，但在具體的業務場景不一定有多大的提效，具體的業務場景要有具體的解決方案，搭建本質是提效的，如果原子化、低程式碼的內容太多，就本末倒置，只是用另一種方式寫程式碼罷了，並沒有真正做到利用搭建提升開發效率。
通用的業務定製方式有如下三種：
- 定製業務元件：比如將某個複雜業務系統 80% 場景都要用到的元件固化為一個業務定製元件，省去了大部分配置時間，讓使用者感受到提效。
- 定製業務模版和低程式碼業務元件：更進一步，將業務模版固化下來，本質上類似程式碼模版，或者利用低程式碼業務元件，在不開發新元件的前提下，製作一個針對某個業務場景的混合元件。
- 定製業務配置項：有些業務場景專業度很高，一方面是使用者群不一樣，一方面是搭建效率考慮，都應該提供一種基於業務角度出發的配置項，既符合業務思考邏輯，又節省配置步驟。
以上通用方式都是通過引擎已有的開放能力可以做到的，但對資料場景來說，有一些依賴引擎執行時能力場景，需要將引擎執行時能力抽象出來，配合低程式碼實現。
比如讓當前頁面所有配置相同資料集的元件自動建立篩選聯動關聯，雖然篩選聯動關聯可以通過低程式碼方式配置，但當畫布元件數量變化時，或者有元件動態呼叫 API 新增元件時，靜態的配置很難滿足動態關聯場景，此時我們可以擴充出一些全域性執行時能力，讓元件實現這些執行時能力時可以拿到畫布資訊，在引擎實際呼叫時再動態執行，而不是編輯生成一份靜態 JSON 與渲染完全割裂。
執行時能力在不同平臺針對不同垂直場景時會存在差異，如果希望打通底層引擎，可以提供擴充插槽，提供動態註冊引擎執行時能力的機制。
3 總結
一個低程式碼搭建平臺通吃一切場景是不可能的，只要有人願意為垂直業務場景做 “量身定製”，使用者就會立刻覺得搭建效率得到了提升，我們應當站在使用者的角度，以使用者利益最大化的方式做平臺。
但搭建平臺維護成本很高，每個業務場景都單獨維護一套肯定不是長久之計，我們需要設計一套有彈性的低程式碼核心引擎，各個業務都可以基於他為自己的使用者群 “量身定製” 一套專屬設計器，共享搭建引擎通用的能力與協議，並自由擴充定製能力。
所以不僅渲染態是多型的，設計器也應該是多型的，其中可以被固化為標準的部分需要沉澱下來，比如物料接入規範、編排能力、出碼能力、執行時能力，讓各個搭建平臺做到合而不同。
國內外都有非常多做的相當不錯的搭建系統，但要不就太通用，具體場景提效不明顯，要不就太垂直，換一個業務場景做不了。現在阿里中後臺低程式碼搭建組織就在制定規範，將引擎通用能力固化為標準協議，讓不同搭建平臺可以對齊規範與功能，未來還會不斷收斂核心引擎實現，基於它可以打造出千千萬萬個垂直領域的搭建平臺，貼著業務做搭建提效，同時引擎核心與規範還能保持互通。
筆者所在阿里資料中臺體驗技術團隊就是中後臺低程式碼搭建組織的一員，將資料搭建領域做到極致。在技術上，我們在打通中後臺搭建與資料搭建的技術方案，在產品上，我們正在逐漸統一阿里集團資料搭建平臺，對外也攜 QuickBI 成為國內唯一一家進入 Gartner 象限的 BI 產品，未來可期。
阿里資料中臺體驗技術團隊正在火熱招人中，如果感興趣可以聯絡 ziyi.hzy@alibaba-inc.com 。
討論地址是：精讀《對低程式碼搭建的理解》· Issue #260 · dt-fe/weekly
如果你想參與討論，請 點選這裡，每週都有新的主題，週末或週一釋出。前端精讀 - 幫你篩選靠譜的內容。
關注 前端精讀微信公眾號
版權宣告：自由轉載-非商用-非衍生-保持署名（創意共享 3.0 許可證）