低代碼的定義就不再這里掰扯了，就按照最有名的三家海外的巨頭來(lái)：Mendix、Outsystems、PowerApps（Power platforms）。即使最大的企業(yè)也沒(méi)有辦法形成“行業(yè)標(biāo)準(zhǔn)和技術(shù)標(biāo)準(zhǔn)”，也就是說(shuō)“低代碼”的做法每家廠商都是不同的，如果沒(méi)有辦法實(shí)現(xiàn)技術(shù)上的統(tǒng)一，我覺(jué)得低代碼本身這種“混亂”的野蠻方式必將走向衰落！

今天想說(shuō)的是，一種全新的物種，應(yīng)該也是技術(shù)發(fā)展的趨勢(shì)——圖形化編程語(yǔ)言。之所以叫“編程語(yǔ)言”，是因?yàn)槠浜诵奶卣魇恰吧扇珬４a”，生成代碼一定是一個(gè)重要的分水嶺，凡是重視研發(fā)安全的企業(yè)，不可能輕視代碼。這里面最有代表性的產(chǎn)品是 iVX 和 CodeWave，所幸這兩家都是國(guó)內(nèi)的企業(yè)。

通過(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í)解綁。在生成代碼方面，由于CodeWave底層使用了開(kāi)源的工作流產(chǎn)品以及封裝了RBAC等權(quán)限，可能無(wú)法做到全棧代碼的生成。iVX在這方面有一定優(yōu)勢(shì)，能夠生成可編譯的全棧代碼。

B 面向組件編程

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

面向組件編程優(yōu)勢(shì)有很多，例如：沉淀復(fù)用技術(shù)方案，大幅提升開(kāi)發(fā)效率；但我發(fā)現(xiàn)更重要的是，可以實(shí)現(xiàn)“代碼隔離”！什么叫代碼隔離呢？就是學(xué)習(xí)者可以完全不懂代碼！只需要學(xué)習(xí)組件相關(guān)的知識(shí)就可以了，這是一個(gè)非常令不起的進(jìn)步，大幅降低了“編程”領(lǐng)域的進(jìn)入門檻。

C 需要一個(gè)“程序邏輯可視化方案”

如果不想寫代碼，那么通過(guò)圖形化的方式表達(dá)“程序邏輯”這一步，應(yīng)該是繞不過(guò)的。那么如何設(shè)計(jì)一個(gè)好的圖形化“程序邏輯”表達(dá)方案，就非常重要。現(xiàn)在常規(guī)的表達(dá)方案，基本上都是基于流程圖的方式，總體來(lái)說(shuō)有以下缺點(diǎn)：浪費(fèi)空間（信息密度不大）、畫圖操作慢/維護(hù)也并不容易（特別是存在大量交叉線的時(shí)候）、復(fù)雜邏輯難以表達(dá)（例如一些非線性的邏輯）、組件和圖形融合困難的問(wèn)題。

傳統(tǒng)的流程圖方案/大量留白

為了避免上面這些問(wèn)題，iVX創(chuàng)新了一種全新的更高效的圖形化邏輯表達(dá)方案，體驗(yàn)下來(lái)相當(dāng)驚艷。

iVX邏輯面板方案/信息密度很高

面對(duì)未來(lái)技術(shù)的發(fā)展，國(guó)內(nèi)一定要走出自己的特色，不能全部都照抄照搬國(guó)外的技術(shù)和產(chǎn)品，在這方面iVX和Code wave已經(jīng)走在了前面。

除了提供強(qiáng)大了的圖形化IDE和代碼生成能力以外，還提供了“比較完整的企業(yè)級(jí)的CI/CD”運(yùn)維環(huán)境，包括“用戶中心”“權(quán)限/角色管理”“日志中心”“消息/微服務(wù)管理”“代碼和版本管理”等，為開(kāi)發(fā)和企業(yè)研發(fā)團(tuán)隊(duì)，提供了一種全新的開(kāi)發(fā)方式。

最近AIGC非常非?；?，但我通過(guò)研究發(fā)現(xiàn)，主要還是在媒體領(lǐng)域突破和實(shí)用價(jià)值巨大，例如生圖、生文、生視頻、生聲音，以及這些媒體格式之間的轉(zhuǎn)換。但是在“生代碼”這種需要超強(qiáng)邏輯和準(zhǔn)確性的事物上，我覺(jué)得AI還是有待提升的。也或許自然語(yǔ)言本身就不適合用來(lái)描述復(fù)雜的邏輯過(guò)程?。ㄈ绻匀徽Z(yǔ)言本身時(shí)候做復(fù)雜的邏輯表達(dá)，那就沒(méi)有必要發(fā)明數(shù)學(xué)和編程語(yǔ)言了）

在我看來(lái)，相比不可控的“AI”生代碼，圖形化編程語(yǔ)言無(wú)論效率還是可控性/準(zhǔn)確性上更佳實(shí)用，也更靠譜！