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

通過分析這三個平臺得出：

低代碼平臺的最核心特征

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

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

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

PowerApps生成 .msapp 文件。

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

B 面向模型編程

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

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

BPM模型

表單模型

在線表格模型

BI報表畫圖模型

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

如果再進一步的，會做“邏輯設計器（或者叫邏輯編排工具）”，Mendix和Outsystems在這方面都做得很不錯。

C 面向最終用戶收費

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

無代碼就是“SaaS”

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

圖形化編程語言的基本特征

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

但是，國內已經有兩家企業(yè)做得很不錯了，一家是iVX，另外一家是CodeWave。（我在這里就不做更多比較，因為我覺得往這個方向發(fā)展的，都很了不起！海外還沒有怎么看到可以商用的產品。）

圖形化編程語言的基本特征：

A 直接生成全棧代碼

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

B 面向組件編程

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

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

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

C 免費的（如果要收也不會面向最終用戶收費）

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

但是，由于“編程語言”本身是面向“開發(fā)者設計”，而非“面向企業(yè)設計”，因此，最多就是和Ideal J一樣收IDE的license費用，不太可能收最終用戶的費用（因為原則上完全不知到最終有多少用戶，運行時應該是“未知”的）。

如何選擇呢？

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

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

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

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