低代碼能力模型

寫在前面

low-code 大旗之下，各式各樣的低代碼平台熙熙攘攘：

• 應用場景：PC 中後台、移動 H5、小程序，也有 React Native 等跨端

• 核心功能：UI 編排、（邏輯）流程編排，甚至服務編排

• 交互方式：表單配置、拖拽，甚至還有富文本擴展

不禁有幾個問題：

• 與它們相比，我正在做（或將要做）的低代碼平台有什麼特殊之處？只能靠自己解決的關鍵問題是什麼？

• 手裡的平台目前處於哪個階段？下一階段在哪裡？如何通往下一階段？

為了解開這些疑惑，我們嘗試建立一個能力模型，讓低代碼平台的變化有跡可循。

一.業務場景

能力模型的第一維是業務場景，覆蓋到的業務場景越多，低代碼能力越強。

從不同角度可對業務場景進行不同的劃分，例如：

• 產品：2C、中後台

• 業務：營銷活動、反饋表單、常規圖文展現、複雜富交互

• 端：移動端、PC Web、小程序

這樣的大類不一定適合所有業務，可根據業務重要性（核心、重要、邊緣）、差異程度（所用的技術體系、面向的用戶群體）等進行具體劃分，必要的話，還可以細分出各個子維度。目的是將現有的低代碼能力對目標業務場景的支持程度定量地描述清楚，平台已經能滿足哪幾類業務場景，未來還能夠滿足哪些？

在垂直場景劃分的基礎上，還可以衍生出跨業務線投放、跨端搭投、一搭多投等混合的探索方向。

二.用戶群體

第二維是低代碼平台面向的用戶群，用戶群體越大，低代碼能力越強。

一般按用戶的專業程度分為：

• 特定技術人員：前端、後端、DBA 等專業人員

• 一般技術人員：有一定邏輯編碼能力的開發人員，能夠快速理解並運用表達式、事件等概念

• 非技術人員：沒有開發經驗的產品、運營、商務、行政人員

如果平台的最終目標是面向非技術人員，那麼就要求對功能進行高度抽象，屏蔽下層技術細節，以降低使用門檻，將更廣泛的用戶納入進來。另一方面，用戶的數量也是衡量低代碼能力的重要指標，覆蓋用戶量越大、不同屬性（團隊、部門、第三方）的用戶越多，越能體現低代碼平台的成熟度。

三.能力完整性

第三維是能力完整性（即技術表達力的完備程度），完整性越高，低代碼能力越強。

目標業務場景中，能力完備的低代碼開發平台具有與源碼開發等同的技術表達力，即，人工寫代碼能實現的東西，就一定能通過低代碼開發平台來完成。

以 Web App 為例，能力完整性要求低代碼平台能夠表達 UI（含交互效果）、前端業務邏輯、接口調用、甚至後端業務邏輯、數據模型等，能夠替代源碼開發，目標用戶可通過平台完成目標需求的全部開發工作，而不是受限於平台能力，只能完成某一部分工作。

四.原料包容性

第四維是原料包容性，即低代碼平台對不同輸入的接受能力，例如：

• 是否支持錄入現有業務組件、模塊？

• 是否支持引用任意第三方模塊？

• 是否支持引入非標準模塊？

源碼開發的一大優勢在於能夠最大限度地復用現有代碼，無論是公共組件/業務組件、第三方模塊，甚至非標準模塊，都可以隨時通過封裝引入，甚至源碼拷貝的方式來復用。而低代碼平台則不同，對於組件、模塊大都有明確的准入規則，只有符合標準的「原料」才能進入到池子中，供平台用戶復用。

一種簡單的做法是按組件的通用程度分為公共組件與業務組件（模塊的處理與組件類似，本節不再嚴格區分），平台只收錄通用的公共組件，極大地簡化了組件版本管理，但這種劃分對於長期持續迭代的業務並不適用，由於無法復用現成的代碼，低代碼模式下開發效率遠低於高度復用的源碼開發。

因此，更好的做法是按標準程度將組件分為標準組件與定製組件：

• 標準組件：平台預置的組件

• 定製組件：平台用戶可隨時引入的其它組件

只有允許用戶錄入定製組件，才能夠滿足其代碼復用需求，讓開發效率重新回到同一水平。因為對於長期迭代的業務而言，日常使用最頻繁的一定是業務組件，而不是通用的公共組件。這種情況下，如何錄入定製組件、如何支持定製組件與標準組件混用是值得深入探索的方向。

五.產物豐富度

第五維是產物豐富度，平台輸出的產物形態越豐富，低代碼能力越強。

輸出產物可分為 3 類：

• 最終產物：功能模塊、頁面、應用

• 中間產物：業務組件、區塊、模版

• 初級產物：UI 組件

最終產物的完成度最高，但可復用程度最低，初級產物與之相反。多種形態的輸出產物意味著強大的可復用性和靈活的集成方式，例如：

• 低代碼開發與源碼開發混合使用，允許平滑過渡

• 基於低代碼平台產出的半成品二次開發，減輕一部分工作量

也就是說，能力完整性決定了目標應用場景，而產物的豐富度決定著低代碼平台的實際應用場景。

六.鏈路覆蓋度

第六維是鏈路覆蓋度，表示對完整生產鏈路的覆蓋程度，覆蓋度越高，低代碼能力越強。

完整的生產鏈路一般包括需求 - 設計 - 開發 - 測試 - 發布 - 運維，低代碼平台對生產鏈路的覆蓋越完整，協作流程越順暢，效率提升也越明顯。不同業務環境中，具體的生產鏈路可能不盡相同，但都需要明確低代碼平台的鏈路覆蓋範圍，不斷優化覆蓋範圍內的環節，同時盡可能降低與範圍外各個環節的協作成本。

具體的，提升鏈路覆蓋度有 2 種方式：

• 併入：將範圍外的環節也拿進來，比如在支持開發的基礎上，提供測試、發布流程管理，以及相應的一鍵部署能力，對必要流程提供盡可能完善的支持，避免將低代碼平台與生產鏈路上下游的接縫暴露給用戶，由人工來填補。

• 連通：與範圍外的環節連接起來，例如，一個表達力很有限的低代碼平台可能需要與源碼開發模式配合使用，此時可以考慮與源碼開發中的代碼倉庫聯動，將產物一鍵上傳至代碼庫，或者反過來將低代碼能力嵌入到 IDE 中，輔助源碼開發。

要覆蓋生產全鏈路不一定非要把所有環節都納入到低代碼開發平台中，只需要打通數據鏈路，與現有工具、平台聯動起來即可，例如：

          原���協議
物料資產 ----------> 低代碼平台
           產物協議
低代碼平台 ----------> 發布平台/代碼倉庫
             中間產物協議
UED 設計工具 --------------> 低代碼平台
            接口描述協議
API 管理平台 ------------> 低代碼平台
           數據描述協議
低代碼平台 -------------> 數據 Mock 平台

七.協作效率

第七維是協作效率，指的是不同角色在低代碼模式下的協同工作效率，協作效率越高，低代碼能力越強。

不同於源碼開發，低代碼開發作為一種新的研發模式，在協作效率方面有很大的想像空間，例如：

• 產品經理：可通過低代碼平台產出高保真原型，交由研發人員進一步開發，甚至能夠自行快速調整文案、圖片素材等。

• UED：設計工具對接低代碼平台，無需人工標註、走查效果。

Design2Code（設計稿轉代碼）是解決 UED 與研發人員的協作效率問題的另一種思路，相比之下，低代碼平台的核心優勢在於降低了專業性要求，使得產品經理、UED 等非技術人員也有能力自主調整，甚至獨立完成部分需求。

八.智能程度

第八維是智能程度，越智能，低代碼能力越強。

首先，如何定義智能？

簡單定義為幫助甚至代替人工決策的能力，也就是說，程序能夠自動做出（我也認為正確的）決定，那麼它就是智能的。例如現代 IDE 能夠根據海量代碼庫詞頻特徵、當前輸入上下文、用戶編碼習慣等信息綜合計算得到最有可能的幾個備選項作為補全提示，大概率是我想要輸入的內容，所以稱之為智能提示。

配置化（數據化）的低代碼開發是走向智能化開發的必經之路，因為智能的基礎是數據，基於大數據集分析得出的規律是程序決策的重要依據。而源碼開發由於其靈活性，並不能提供細緻的有效輸入，低代碼平台限制了人工編碼的靈活性，提供了一種配置化的程序表達方式，產生的配置數據能夠作為推薦算法的輸入，進而幫助人工決策：

• 自動推薦/選擇內容，如佈局模版、組件樣式（字號、顏色）、圖片素材等

• 自動推薦/選擇文案，如關鍵字、句式、風格等

• 甚至自動產生大量 UI 組合，均等投放驗證效果，根據效果反饋自動選擇最佳

讓部分生產環節從人工決策走向自動化的數據驅動決策，低代碼平台在這樣的智能化進程中起著不可替代的作用。

至此，8 維低代碼能力模型已經建立起來了，如下圖：

[caption id="attachment_2311" align="alignnone" width="500"] low code model[/caption]