精讀《對低代碼搭建的理解》

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 許可證）