低代碼的定義就不再這里掰扯了，就按照最有名的三家海外的巨頭來(lái)：Mendix、Outsystems、PowerApps（Power platforms）。這三家應(yīng)該很具有代表性了，應(yīng)該也是低代碼平臺(tái)里面做的最好的（應(yīng)該不會(huì)有太多人有異議）。

通過(guò)分析這三個(gè)平臺(tái)得出：

低代碼平臺(tái)的最核心特征

A 不直接生成可以部署的代碼（一般是某種打包格式）

其中，Mendix生成 .mpk 文件，應(yīng)該是一種Java的打包格式，也有部分JS代碼；

Outsystems生成 .osp 文件，應(yīng)該整體上和Mendix類似的方案；

PowerApps生成 .msapp 文件。

也就是說(shuō)，比較“杰出”的低代碼平臺(tái)，是可以導(dǎo)出文件，并部署在自身“系統(tǒng)”內(nèi)部的，但是無(wú)法部署在“非自身定制系統(tǒng)”。也就是說(shuō)，低代碼平臺(tái)直接“互不兼容”，低代碼平臺(tái)生標(biāo)準(zhǔn)的代碼運(yùn)行環(huán)境也是“互不兼容”（例如不能直接在Java環(huán)境運(yùn)行）。

B 面向模型編程

低代碼平臺(tái)，設(shè)計(jì)時(shí)主要是針對(duì)企業(yè)內(nèi)部管理場(chǎng)景服務(wù)的（設(shè)計(jì)初衷）。在我看來(lái)，低代碼平臺(tái)，不能算是一種“新技術(shù)”，而是一種為“企業(yè)服務(wù)定制的產(chǎn)品”，這一點(diǎn)和SaaS有點(diǎn)像。因此，免不了會(huì)有一些局限性，無(wú)論是功能和性能上都很難和編寫代碼的系統(tǒng)相比并論。但是，在一些固定場(chǎng)景下，低代碼平臺(tái)效率會(huì)很高。

幾乎所有低代碼平臺(tái)都可以涵蓋在這其中基本模型中：

BPM模型

表單模型

在線表格模型

BI報(bào)表畫圖模型

在這個(gè)基礎(chǔ)上，有一些進(jìn)一步做了“頁(yè)面編輯器”“數(shù)據(jù)庫(kù)設(shè)計(jì)器”等等，這些就算做的很好的了。

如果再進(jìn)一步的，會(huì)做“邏輯設(shè)計(jì)器（或者叫邏輯編排工具）”，Mendix和Outsystems在這方面都做得很不錯(cuò)。

C 面向最終用戶收費(fèi)

這是一個(gè)商業(yè)模式的特征，但是由于產(chǎn)品是“運(yùn)行時(shí)”的配置產(chǎn)品，也就導(dǎo)致了這種“收費(fèi)方式”。這一點(diǎn)和“圖形化編程語(yǔ)言”按開(kāi)發(fā)者license進(jìn)行收費(fèi)有很大不同。

無(wú)代碼就是“SaaS”

在我的理解里面，所謂無(wú)代碼就是SaaS，兩者沒(méi)有什么區(qū)別！最多無(wú)代碼平臺(tái)把多個(gè)SaaS集成起來(lái)，具有一定的“互操作性”而已。多數(shù)情況下，無(wú)代碼產(chǎn)品更希望“在線使用”，而不是“本地部署”，這樣更符合SaaS的特征（但國(guó)內(nèi)已經(jīng)卷得面目全非了）。

圖形化編程語(yǔ)言的基本特征

圖形化編程語(yǔ)言：這個(gè)是新興起的技術(shù)方向（同時(shí)也具備很強(qiáng)的產(chǎn)品屬性），其實(shí)很多產(chǎn)品早就開(kāi)始嘗試，其實(shí)沒(méi)有引起足夠的重視。在一些領(lǐng)域“圖形化編程語(yǔ)言”占領(lǐng)著絕對(duì)的統(tǒng)治地位，最明顯的就是“Scratch”，兒童/青少年編程，這個(gè)一說(shuō)，應(yīng)該很多人就知道了。但是，作為“通用”編程語(yǔ)言而存在，能夠?qū)崿F(xiàn)各種企業(yè)/工業(yè)和個(gè)人應(yīng)用的開(kāi)發(fā)場(chǎng)景，這是一個(gè)非常大的挑戰(zhàn)。

但是，國(guó)內(nèi)已經(jīng)有兩家企業(yè)做得很不錯(cuò)了，一家是iVX，另外一家是CodeWave。（我在這里就不做更多比較，因?yàn)槲矣X(jué)得往這個(gè)方向發(fā)展的，都很了不起！海外還沒(méi)有怎么看到可以商用的產(chǎn)品。）

圖形化編程語(yǔ)言的基本特征：

A 直接生成全棧代碼

作為一種新型編程語(yǔ)言，必須可以往前兼容，也就是最好能夠自動(dòng)生成“高級(jí)語(yǔ)言”，以iVX為例，前端可以生成Vue/React/flutter/小程序等，后臺(tái)可以生成Java/Node.js代碼，代碼可讀/可改，且全棧代碼可以直接編譯運(yùn)行。這意味著，開(kāi)發(fā)者對(duì)“圖形化編程語(yǔ)言”可以做到完全無(wú)依賴，可以隨時(shí)解綁。

B 面向組件編程

要想去掉代碼，比較可行的方式就是“面向組件”編程，并且把“邏輯控制”部分抽象出來(lái)。

例如iVX組件層可以抽象成這樣，其中包括“變量”和各種類型的組件，可以說(shuō)“一切皆組件”！Scratch其實(shí)也是類似的方式：

但是，Scratch由于是給小朋友理解“文本編程Coding”這種模式的，因此并沒(méi)有做進(jìn)一步的“優(yōu)化”，而iVX則進(jìn)一步把“邏輯的控制結(jié)構(gòu)”也給抽象出來(lái)，這樣更方便用戶使用和編程。

C 免費(fèi)的（如果要收也不會(huì)面向最終用戶收費(fèi)）

iVX和Scratch都是免費(fèi)的圖像化編程語(yǔ)言，iVX更適合企業(yè)和程序員學(xué)習(xí)，而Scratch是針對(duì)小朋友學(xué)習(xí)和使用的，CodeWave好像現(xiàn)在是收費(fèi)的。

但是，由于“編程語(yǔ)言”本身是面向“開(kāi)發(fā)者設(shè)計(jì)”，而非“面向企業(yè)設(shè)計(jì)”，因此，最多就是和Ideal J一樣收IDE的license費(fèi)用，不太可能收最終用戶的費(fèi)用（因?yàn)樵瓌t上完全不知到最終有多少用戶，運(yùn)行時(shí)應(yīng)該是“未知”的）。

如何選擇呢？

從企業(yè)安全考慮，我覺(jué)得 企業(yè)應(yīng)該盡量避免使用“低代碼”平臺(tái)，理由如下（歡迎大家指正）：

低代碼和SaaS平臺(tái)用完即走不同，低代碼平臺(tái)需要企業(yè)長(zhǎng)時(shí)間的“投入和迭代”，往“低代碼平臺(tái)注入知識(shí)”，這樣使用過(guò)程中會(huì)“越來(lái)越重”，以至于無(wú)法剝離。對(duì)于被選擇低代碼廠商來(lái)說(shuō)“也許是個(gè)好消息”，對(duì)企業(yè)也不傻，很少愿意“被鎖定”在某一個(gè)平臺(tái)。

從快速開(kāi)發(fā)考慮，是可以少量使用“低代碼”和“無(wú)代碼SaaS”平臺(tái)的，特別是“SaaS”平臺(tái)，用完即走的特性，肯定對(duì)企業(yè)會(huì)更加友好。

如果從技術(shù)升級(jí)，中臺(tái)建設(shè)（我個(gè)人其實(shí)還是挺中臺(tái)的，只是中臺(tái)要求較高，如果用圖形化編程可以試一下，成本會(huì)降低很多），降本增效來(lái)講，“圖形化編程語(yǔ)言”應(yīng)該是不錯(cuò)的選擇，效率上相比代碼提升明顯，能力邊界和代碼開(kāi)發(fā)非常接近。