低代碼開發(fā)平臺這兩年突然呈爆發(fā)狀態(tài)，各類低代碼廠商如雨后春筍般冒出。但究其根本，具體的形式都大同小異，基本可以總結為四類：表單類型、頁面區(qū)塊類型、表格(Excel)類型、類語言級類型。

以下對這幾種類型進行大體描述，不涉及細節(jié)，如果疏漏，歡迎交流。

一、表單類型

表單類型是低代碼開發(fā)平臺最常見的一種形式。

表單的核心為表單編輯器，流程編輯器，部分低代碼開發(fā)平臺還有業(yè)務流編輯器（對數(shù)據(jù)的增刪改流程進行后續(xù)操作），有的低代碼開發(fā)平臺業(yè)務編輯器與流程編輯器是一體的。

這類低代碼開發(fā)平臺由表單編輯器出發(fā)，根據(jù)表單組件的類型直接生成列表頁，由其中的特殊組件（例如子表組件，關聯(lián)數(shù)據(jù)組件）定義關聯(lián)關系。

這類低代碼開發(fā)平臺的列表頁面一般比較固定，基本上每一種頁面類型都需要定向（用代碼）擴展。

在數(shù)據(jù)模型有了之后，一般由一個可視化數(shù)據(jù)編排工具，例如ETL，進行數(shù)據(jù)的分析，生成圖表。

圖表展示頁一般由一個可拖拽的布局器去引用生成的圖表。

此類型一般用在一些比較簡單的后臺數(shù)據(jù)管理、分析等場景，缺少一些更多場景的靈活性。

二、頁面區(qū)塊類型

以頁面為單元進行編排，直接從菜單出發(fā)，每新增一個菜單就是一個頁面，所有的數(shù)據(jù)建模都來自于頁面上存在的部分。

其核心為頁面編輯器，組件列表，以及一個邏輯編排器。

頁面編輯器中，由列表或者表單等形成數(shù)據(jù)建模，各個組件之間的邏輯關系，直接被解析為數(shù)據(jù)模型之間的關聯(lián)。

頁面上所有的部分都被解釋為組件，可以自建數(shù)據(jù)模型，也可以引用其他的模型。

此類低代碼開發(fā)平臺，弱化數(shù)據(jù)建模（后端邏輯）的獨立性，直接從菜單（或者路由）作為起點，一切的邏輯都收縮頁面上存在。

只要頁面上的組件（包括有一定業(yè)務屬性的組件）足夠地豐富，邏輯編排的方式足夠地多，那么可覆蓋的場景就越廣。

此類型市面上也比較多，各類大屏編輯器也屬于這一類型，其能力強依賴于其組件的豐富程度和邏輯編排能力的完整度。

三、表格（Excel）類型

直接以表格進行建模，利用Excel強大的函數(shù)公式能力。

這一類低代碼開發(fā)平臺在幾年前比較常見，現(xiàn)在的流行度逐漸在降低了。

直接以一張Excel表作為數(shù)據(jù)模型，定義每一列是什么意思。

所有的表單、表格、流程等，都表現(xiàn)為一個Excel表。

需要擴充部分動態(tài)的公式，甚至數(shù)據(jù)表之間的影響公式。

權限、組織、人員、菜單等都放在外面，其數(shù)據(jù)也可以由Excel管理。

由于Excel的流行性，這類低代碼開發(fā)平臺的上手難度較低，尤其是對Excel比較熟悉的用戶來說，只需要稍微學習一點新的公式和編排邏輯即可上手。

但是同樣，由于這類平臺過于依賴于Excel，想做更復雜業(yè)務的時候，需要用戶對Excel的復雜功能和業(yè)務抽象邏輯都有極深地了解才能繼續(xù)，無形中的學習成本實際上是極高的。

同時，由于對Excel的依賴性，也喪失了一部分頁面上的靈活性。

這類低代碼開發(fā)平臺常用于一些本身業(yè)務就依賴于Excel，同時對單據(jù)還原度要求比較高的場景。

四、類語言級類型

這類低代碼開發(fā)平臺目前市場出現(xiàn)較少，嚴格來說已經(jīng)快脫離低代碼平臺的范疇了。

這類開發(fā)平臺將所有的操作都細化到一個最小單元，幾乎與寫代碼等同，但是更強化可視化編排這個能力。

一般來說這類低代碼開發(fā)平臺比較像“古老“的VB語言，將所有的組件都拆分為 屬性、行為、事件。

然后用一個可視化語法樹的形式，允許你對各個組件的事件進行捕獲，然后執(zhí)行一些其他的行為。如數(shù)據(jù)處理等，也是一個組件，主要用于可視化編排邏輯使用。

對于后端的邏輯處理也類似，提供幾個原生的系統(tǒng)能力組件，在可視化語法樹中進行邏輯編排調(diào)用。

只要邏輯單元，系統(tǒng)能力單元，組件單元足夠豐富，“理論上”可以做到代碼能做的所有功能。(底層能力除外)

這類低代碼開發(fā)平臺一般會提供完整的入門方案，生態(tài)市場，擴展文檔，調(diào)試流程、發(fā)布流程等，如一門語言一般。可以說是一個可視化寫代碼的方式。

上手難度較高，需要一定的編碼邏輯基礎才能上手，但是比較學一門語言的難度，還是要低一些的。

總結：

所有低代碼開發(fā)平臺都是在將代碼過程分塊后進行某個方向的抽象，并進行可視化邏輯編排，將最細節(jié)的那一部分代碼留在組件或者邏輯塊內(nèi)部，因此，這四種類型也可以認為是四種邏輯抽象的方向。

而從目前來看，所有低代碼開發(fā)平臺都無法完全地解決所有的問題，其更像是一個同類業(yè)務模型的高級抽象，以便在短時間內(nèi)解決更多類似的問題，甚至可以自動化地解決一些問題( 如果樣本足夠多，個人相信可以做到根據(jù)描述生成一部分的功能出來 )。

大多數(shù)的低代碼開發(fā)平臺都無法繞過元數(shù)據(jù)（數(shù)據(jù)建模）建立這一關，表單組件的拖拽、列表組件的數(shù)據(jù)列、Excel的列定義、或者更直接的數(shù)據(jù)表定義等，可以說都是在進行數(shù)據(jù)建模。

大多數(shù)的低代碼開發(fā)平臺都在弱化元數(shù)據(jù)的具體概念，將其分化到各個操作之中。

大多數(shù)的低代碼開發(fā)平臺都留有一定的代碼擴展性，例如表單代碼塊，腳本，組件生命周期，或者直接就是組件的擴展等，以應對過于復雜的業(yè)務邏輯。

從某種程度上來說，留下的代碼擴展點越少，代表其抽象程度越高，但是抽象程度越高可能配置的過程就會越繁瑣，有些部分甚至不比寫代碼的工作量小，因此需要在具體場景下去平衡抽象組件與代碼擴展點。