視覺化程式設計能夠取代高階語言嗎？即使現代的計算機技術得到了飛速發展，視覺化程式設計取代高階語言依舊是其行業內最高理想。本文將從國內外流行的視覺化程式設計商業工具入手，分析現階段視覺化程式設計的侷限性，以及未來視覺化程式設計的發展前景。

之前在知乎看到了一則較早的問題 現在的視覺化程式設計發展到什麼程度了，什麼時候可以取代高階語言？ 這在視覺化程式設計行業內可是最高理想。但期中有一個回答真實反應了現實——視覺化程式設計無法取代高階語言。接下來分析幾款國內外視覺化程式設計商業工具（可以做出商業產品），從而分析一下視覺化程式設計的桎梏，以及可能的發展前景。

國內外幾種商業視覺化程式設計工具

1.Mendix

全行業做低程式碼開發幾乎都用積木的方式去做，確實積木的拼接組合操作很容易，也符合程式設計師的操作習慣，但全行業似乎陷入了創意沼澤。這時候 mendix 出現在我眼前，流程圖式程式設計是哪個神經病想的，真有意思（下文的 Outsystems 也是相同的形式）。這裡引用一下別人對 mendix 的基本介紹:

“專攻企業應用開發，面向 B 端使用者，一般是面向有開發團隊的中大型企業，提供模型驅動 IDE 和微流，減少程式碼量，使業務人員可以通過視覺化元件參與到開發過程中，與程式設計師在 Mendix platform 上合作開發本企業的應用。提供一些企業解決方案、模板，開發平臺上也支援自定義 UI 和元件。擁有 Atlas UI Framework 開發框架，根據應用和業務型別，會推薦相關的模板和元件，達到快速開發的目的。內建 DevOps 功能，可以持續交付，也可以使用 Mendix platform API 整合其他 DevOps 工具。”

可以做原生 app，web 系統。但編輯器功能本身並不完善，給定的功能模組無法滿足企業使用者的全部需求。本身有全棧的能力，最近還引入了 socket，但其設計的出發點還不是很適合國內的生態。接入微信等需要額外配置，很煩。編輯器介面本身足夠硬核，流程圖繪製本身就是視覺化的經典與難點，箭頭的直觀性也很強。其工具只能企業或學生郵箱註冊，有興趣的同學可以註冊試試。

2.Outsystems

和 mendix 一樣也是針對企業的視覺化工具，註冊需要企業郵箱。較早版本只包含基本的前端 UI 元件，目前已經豐富了很多。支援資料驅動的 list 元件，每種元件都有封裝的事件（這點大同小異，視每個工具的設計思路，有需要可以發郵件提）。css 樣式的編輯及其複雜，基本就是原生 css，沒有經過任何的封裝，說白了還是給前端程式設計師做的。

其實國外這種商業視覺化程式設計的工具還不少 bpmonline、Zoho Creator、微軟的 Microsoft PowerApps 。功能上各有千秋，但受限於線路問題和工具語言，在國內想推行起來還是有難度，那麼國內前沿的視覺化程式設計水平怎麼樣呢，我就直接四個二加兩個王了哈！

3.iVX

ih5 團隊打造的 v4 版本，在國內網頁編輯器中處於鄙視鏈的最頂層。對於一個程式設計師而言可以利用 js 進行開發才能滿足其工作的成就感，但 ivx 可以做到對沒有程式設計基礎開發人員的有效對接。ivx 的元件數量比起國外的產品不是最多的，但確是最契合中國開發需求的，封裝全面的微信功能，支援方便認證登入（封裝好的取 openid/unionid 的方法），支援微信支付 / 紅包，各種移動端選擇器，直播元件（限企業使用者）。支援微信小程式、web 開發、原生 app（4.1beta），後端介面 / 資料庫的操作也相對簡單。對於國內做外包的從業者而言確實能節省人員和學習成本，但視覺化程式設計即便如此依然有其無解的侷限。

scrtch 在視覺化程式設計領域很具有代表性，但相對初級，僅針對兒童教育。另外像部分 apaas 的 crm 編輯器由於功能太過單一也沒有拿出來說。

侷限

1. 功能 / 效能的侷限

看了之前介紹的產品，即便是當中功能最完備的，相比起一門語言來說是不是依舊顯得單薄無力。即便可以代替傳統程式設計師開發中檔產品，但要說視覺化能取代高階語言無疑是在宣稱制造零件不需要自然資源，不論用什麼新材料新工藝製造零件，其本源都要依賴自然資源。利用高階語言開發好比將礦石做成零件再拼裝，視覺化程式設計好比拿到現有的零件組裝。零件是否好用只能依賴別人，雖然像 ivx、mendix 有自定義元件的功能，但那依舊是對已有元件的封裝，無法真正意義上與 w3c 完美對接。一門高階語言有多少的操作空間？想想 3-4 年前 js 都能寫人工智慧了呢。視覺化工具要想寫深度學習該怎麼做？估計只能引用外部介面。

效能問題就更不用說了，由於視覺化程式設計的目的基於開發商業產品，其限定死了程式的執行只能是單執行緒的，最終將使用者的 js 用 evil 嵌入最終的包。因此沒有一款編輯器敢開放 web worker 功能。

2. 社會因素 / 混亂的生態 / 沒有標準

在大廠呆過的同學一開始一定很好奇為什麼要經常重複造輪子，網上明明有很多封裝好的庫，怎麼不能拿來直接用呢？安全問題、法律問題、技術儲備，這些都是社會屬性性對人類發展的影響。react 中發現存在隱藏協議的時候百度連夜重構程式碼，之後改用修改過的框架開發了。

與開源的框架不同，視覺化編輯器是開發團隊賴以為生的產品，除了麻省的 scratch、pblock 面向教育的公益類視覺化開源專案外，其他不管 to B 還是 to C 的產品基本都要收費（Outsystems、mendix 針對在校生免費，ivx 在一定流量額度下免費，其餘國內大部分產品只要使用都收費）。這導致的第一個問題是生態的缺乏，一個人想要學習使用還要有這樣那樣的條件限制，那在校生或剛入行的人寧願去選擇行業認可的技術。第二個問題是由於市場沒有被某個或某些廠家壟斷（想想 dji 出數字圖傳套件前 fpv 圈子的生態），導致了一家一個標準。一個程式設計師熟練使用 5 個主流語言 3 款框架就差不多了，因為主流語言就那麼多，但是市場上的視覺化程式設計公司幾百家，而且做得好的都是自研，沒有統一的標準，每家的特色和亮點都不同，到底選誰是很大的問題，都選怕你時間不夠。這種混亂導致了小白的迷茫和程式設計師的不屑，不如學好基礎自己開發。

3. 相關研究不足

low code develop 是國外傳入的概念，被中國網際網路人翻譯為低程式碼開發，在國外炒了有一陣了。相關的技術文章有多少呢？先從 eric 查一下國外的研究狀態，完全搜不到相應的研究，怎一個慘子了得：

再來看看 cnki，3 個結果，一篇真相關還是科普文，學教育技術的同學你們的研究方向有了！

學界的研究向來喜歡偏向資本市場或爭議問題，區塊鏈、深度學習、轉基因等課題都要經過一段時間的資本宣傳或輿論發酵才能讓這些教授學者關注這些議題。比起視覺化程式設計的市場綜述研究和發展潛力研究，學界倒是對視覺化程式設計、scratch 等教育學議題更加關注，畢竟現在兒童程式設計有資本注入。當有了一定學術支撐後，研究和使用的人就會逐漸增多，相應的標準或評級也能展開，間接可以讓混亂的學習生態聚焦主流。

總結

視覺化程式設計取代高階語言在短期內不可能實現。首先市場的發展陷入守城之勢，真的得出現類似 dji 參與 fpv 開發、騰訊出小程式等事件，某個大廠介入出一套東西然後主推，改變大家的程式設計習慣然後視覺化程式設計立刻進入大家視野切逐漸形成一套生態。否則視覺化程式設計依然只能是小眾的開發方式。

從技術角度說一款圖形 IDE 無論如何做不到一門語言的完整性，作為一種開發方案，視覺化程式設計極力做到錦上添花，簡化開發流程，節約開發成本，完善最終編譯結果，代替一般 web/ 小程式專案的開發模式是完全沒問題的。