低代碼的定義就不再這里掰扯了，就按照最有名的三家海外的巨頭來：Mendix、Outsystems、PowerApps（Power platforms）。即使最大的企業(yè)也沒有辦法形成“行業(yè)標準和技術標準”，也就是說“低代碼”的做法每家廠商都是不同的，如果沒有辦法實現(xiàn)技術上的統(tǒng)一，我覺得低代碼本身這種“混亂”的野蠻方式必將走向衰落！
今天想說的是，一種全新的物種，應該也是技術發(fā)展的趨勢——圖形化編程語言。之所以叫“編程語言”，是因為其核心特征是“生成全棧代碼”，生成代碼一定是一個重要的分水嶺，凡是重視研發(fā)安全的企業(yè)，不可能輕視代碼。這里面最有代表性的產品是 iVX 和 CodeWave，所幸這兩家都是國內的企業(yè)。
通過分析這三個平臺得出：
低代碼平臺的最核心特征
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ù)據(jù)庫設計器”等等，這些就算做的很好的了。
如果再進一步的，會做“邏輯設計器（或者叫邏輯編排工具）”，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ā)者對“圖形化編程語言”可以做到完全無依賴，可以隨時解綁。在生成代碼方面，由于CodeWave底層使用了開源的工作流產品以及封裝了RBAC等權限，可能無法做到全棧代碼的生成。iVX在這方面有一定優(yōu)勢，能夠生成可編譯的全棧代碼。
B 面向組件編程
要想去掉代碼，比較可行的方式就是“面向組件”編程，并且把“邏輯控制”部分抽象出來。
面向組件編程優(yōu)勢有很多，例如：沉淀復用技術方案，大幅提升開發(fā)效率；但我發(fā)現(xiàn)更重要的是，可以實現(xiàn)“代碼隔離”！什么叫代碼隔離呢？就是學習者可以完全不懂代碼！只需要學習組件相關的知識就可以了，這是一個非常令不起的進步，大幅降低了“編程”領域的進入門檻。
C 需要一個“程序邏輯可視化方案”
如果不想寫代碼，那么通過圖形化的方式表達“程序邏輯”這一步，應該是繞不過的。那么如何設計一個好的圖形化“程序邏輯”表達方案，就非常重要。現(xiàn)在常規(guī)的表達方案，基本上都是基于流程圖的方式，總體來說有以下缺點：浪費空間（信息密度不大）、畫圖操作慢/維護也并不容易（特別是存在大量交叉線的時候）、復雜邏輯難以表達（例如一些非線性的邏輯）、組件和圖形融合困難的問題。
傳統(tǒng)的流程圖方案/大量留白
為了避免上面這些問題，iVX創(chuàng)新了一種全新的更高效的圖形化邏輯表達方案，體驗下來相當驚艷。
iVX邏輯面板方案/信息密度很高
面對未來技術的發(fā)展，國內一定要走出自己的特色，不能全部都照抄照搬國外的技術和產品，在這方面iVX和Code wave已經走在了前面。
除了提供強大了的圖形化IDE和代碼生成能力以外，還提供了“比較完整的企業(yè)級的CI/CD”運維環(huán)境，包括“用戶中心”“權限/角色管理”“日志中心”“消息/微服務管理”“代碼和版本管理”等，為開發(fā)和企業(yè)研發(fā)團隊，提供了一種全新的開發(fā)方式。
最近AIGC非常非?；穑彝ㄟ^研究發(fā)現(xiàn)，主要還是在媒體領域突破和實用價值巨大，例如生圖、生文、生視頻、生聲音，以及這些媒體格式之間的轉換。但是在“生代碼”這種需要超強邏輯和準確性的事物上，我覺得AI還是有待提升的。也或許自然語言本身就不適合用來描述復雜的邏輯過程?。ㄈ绻匀徽Z言本身時候做復雜的邏輯表達，那就沒有必要發(fā)明數(shù)學和編程語言了）
在我看來，相比不可控的“AI”生代碼，圖形化編程語言無論效率還是可控性/準確性上更佳實用，也更靠譜！
版權聲明：本文內容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至 舉報，一經查實，本站將立刻刪除。