今天想聊聊可視化編程（visual-programming）的未來(lái)發(fā)展，喂喂，咱們這兒還沒(méi)開(kāi)始，各位大佬先別急著(zhù)走啊您……確實(shí)，可視化這個(gè)概念跟任何技術(shù)并稱(chēng)，都是技術(shù)前沿、下一個(gè)風(fēng)口、萬(wàn)億市場(chǎng)的代名詞，數據可視化、可視化分析、神經(jīng)網(wǎng)絡(luò )可視化……唯獨在一個(gè)領(lǐng)域似乎成了 low 和過(guò)時(shí)的象征——可視化編程。無(wú)論資深程序員還是風(fēng)投大佬，只要你跟他提起這個(gè)概念，對方都會(huì )立刻露出一種“不提這個(gè)還能聊”的鄙夷神情。
然而可視化編程本來(lái)是一個(gè)多么朋克且具有未來(lái)感的語(yǔ)匯，它最大的意義在于打破一些我們今天看起來(lái)不可逾越的技術(shù)壁壘，重新定義被稱(chēng)之為底層技術(shù)生態(tài)的一些東西。著(zhù)名的信息技術(shù)分析公司 Gartner 早在 2012 年就提出了“全民開(kāi)發(fā)者”（Citizen Developer）概念，指的是借助于一些組件化的集成代碼可視化平臺，一些不具備專(zhuān)業(yè)代碼技能和開(kāi)發(fā)經(jīng)驗的“小白”人群也能自主組織或參與應用開(kāi)發(fā)，從而把代碼開(kāi)發(fā)由一項程序員專(zhuān)屬職能擴充到更廣泛的人群，甚至是全人類(lèi)。想象一下，你們公司的保潔阿姨將參與下個(gè)季度的核心項目開(kāi)發(fā)，隔壁的王大爺開(kāi)發(fā)了一個(gè)名為“跳了嗎”的程序用來(lái)約小區大媽一起能跳廣場(chǎng)舞……媽耶，這將是一個(gè)多么不可思議而令人神往的時(shí)代，不僅是 IT 行業(yè)，整個(gè)社會(huì )都將發(fā)生天翻地覆的變革。
然而理想是雄壯的，現實(shí)卻是悲壯的。從上世紀 60 年代至今，無(wú)數大佬在這個(gè)領(lǐng)域進(jìn)行了前赴后繼的探索，提出了各種解決方案，并開(kāi)發(fā)出了配套的工具，目前可知的可視化編程工具已超過(guò) 90 余款。上世紀九十年代，還有人嘗試開(kāi)展一場(chǎng)運動(dòng)，即在企業(yè)中普及可視化編程工具，通過(guò) UML CASE 來(lái)定義和生成應用。這種工具的工作原理是通過(guò)可視化方法為系統建模，根據模型生成程序代碼，任何代碼的變更都可以反向反映到模型上。
但是這些實(shí)踐都宣告失敗了。截至目前，可視化編程只在一個(gè)領(lǐng)域取得了一些成果，你猜對了，就是以 Scratch、Blockly 為代表的兒童編程。想到這些，一股悲壯感油然而生，猛虎落淚.jpg。
那么現在問(wèn)題來(lái)了。為什么一個(gè)看似如此潛力非凡的技術(shù)風(fēng)向，卻至今未能爆發(fā)出應有的潛能，反而受到專(zhuān)業(yè)人士唾棄？問(wèn)題到底出在概念本身，還是缺乏有效的實(shí)現路徑？對可視化編程的負面印象到底是一種偏見(jiàn)，還是它從根本上就是個(gè)糟糕的 idea？有沒(méi)有一種解決方案能夠從底層實(shí)現革新，創(chuàng )造真正意義上實(shí)現可視化編程？這就是我們接下來(lái)試圖討論的問(wèn)題。
為了解答可視化編程相較于傳統編程到底差在哪里的問(wèn)題，我們首先和一些程序員聊了一聊。他們是這樣說(shuō)的：
幾乎所有的程序員都首先對現有可視化編程平臺的工作方式提出了質(zhì)疑。他們認為，大多數可視化平臺都采用了 Block Type（積木模塊型），即通過(guò)“拖拽”、拼接并通過(guò)可視化窗口對一些對象屬性進(jìn)行定義的方式來(lái)實(shí)現項目的搭建。這是一種十分低效的編程方式。程序員的基本氣節就是，寧愿用鍵盤(pán)敲出一行行代碼，也不愿拖壞鼠標。
多數受訪(fǎng)程序員們認為，可視化編程工具聽(tīng)起來(lái)只能搭建一些前端頁(yè)面，要么就是通過(guò)圖形化節點(diǎn)的方式來(lái)做一些簡(jiǎn)單的程序序列，做做兒童編程還行，至于具有復雜數據架構的大型應用，別問(wèn)，問(wèn)就是做不了。
可視化編程的基本邏輯是實(shí)現代碼到可視化圖形的映射。一個(gè)簡(jiǎn)單的程序包含數百行代碼的情況是常態(tài)，而當這些代碼成為百上千個(gè)圖形元素，閱讀和理解的抽象程度、維護的困難程度甚至會(huì )超過(guò)以文本形式存在的代碼。
高級語(yǔ)言歷經(jīng)了很長(cháng)的發(fā)展歷程，其實(shí)語(yǔ)言本身并沒(méi)有什么本質(zhì)提升，但是基本架構、代碼庫和配套的 IDE 卻日益完善。而可視化編程目前還只停留在初級階段，只解決了工具層面的核心問(wèn)題，缺乏配套的工作環(huán)境和技術(shù)資源積累，將在很大程度上限制工作效率甚至抑制產(chǎn)能。
可視化編程工具基于對既有代碼邏輯或對象進(jìn)行封裝來(lái)實(shí)現，卻也因此而無(wú)法被輕松解耦，極大地限制了開(kāi)發(fā)的自由度。如果遇到問(wèn)題，是不是還要重新維護和開(kāi)發(fā)可視化工具本身??？何況有很多工具甚至還不是開(kāi)源的。那我要這鐵棒有何用…
程序員們均認為，可視化編程工具開(kāi)發(fā)出來(lái)的東西都是模塊拼接而成的，缺乏有效的可復用機制，首先不具備清晰的數據結構，其次更無(wú)法被模塊化。所以，只能開(kāi)發(fā)一次性應用？？？
除了對于可視乎語(yǔ)言本身的指摘，很多程序員也表現出了對這種新工作方式的抗拒。他們覺(jué)得自己已經(jīng)習慣了代碼化的開(kāi)發(fā)邏輯，很難適應一款從根本上存在歧異的“語(yǔ)言”。而如果在使用中要同時(shí)兼顧，則更加難以協(xié)調思維邏輯的轉換。
可以看出，程序員對于可視化編程的抗拒心理主要圍繞產(chǎn)能、開(kāi)發(fā)效率、使用性、功能性等實(shí)踐方面。盡管很多程序員都承認，可視化編程是一個(gè)好的概念，但是作為一種工具，它從邏輯上并不能真正實(shí)現對高級語(yǔ)言的簡(jiǎn)化，反而在操作層面將其復雜化了。一言以蔽之，所以可視化編程只能做為一種初級工具，作為高級語(yǔ)言的輔助品，而永遠無(wú)法取代高級語(yǔ)言。
可以看出，程序員抗拒可視化編程，本質(zhì)是在說(shuō)，目前還沒(méi)有一款成熟的可視化產(chǎn)品真的能夠讓他們體會(huì )到便利，解決他們后顧之憂(yōu)。這讓我們不禁開(kāi)始思考，本質(zhì)上這或許是一個(gè)技術(shù)發(fā)展階段的問(wèn)題，不是可視化編程這個(gè)思路不好，只是好的工具還沒(méi)有問(wèn)世？為此，我們調研了目前市場(chǎng)上的一些可視化工具，想要看看是否有一些工具已經(jīng)做出了一些突破，或者具備實(shí)現突破的潛質(zhì)。
調查顯示，作為可視化編程的發(fā)源地，目前國外主打可視化編程、低代碼編程的平臺至少有十幾家，其中最具代表性的可以說(shuō)是 OutSystems、Mendix、Salesforce、 Kony 等幾家。而值得欣喜的是，國內這幾年也有一些功能相對完善的競品出現，包括明道云、簡(jiǎn)道云、iVX 等。關(guān)于這些平臺的相關(guān)評測文章已經(jīng)很多了，而這里我們不去比較平臺的優(yōu)劣，主要探討這些產(chǎn)品在可視化編程領(lǐng)域的技術(shù)探索進(jìn)展到了什么地步，對于傳統技術(shù)生態(tài)的改造有哪些貢獻，因此只在國內外產(chǎn)品中各選出一例進(jìn)行討論。
Mendix 一直被視為可視化開(kāi)發(fā)領(lǐng)域的標桿產(chǎn)品，也是全球頂級的 Paas 提供商。雖然它的核心邏輯是早已不被看好的 UML，但不可否認，它確實(shí)在這條路上走出了一些新意，告訴我們可視化開(kāi)發(fā)也可以做很多事情。
首先，Mendix 是一款目標非常明確的產(chǎn)品，它要解決的核心痛點(diǎn)就是可重復開(kāi)發(fā)。而它解決問(wèn)題的核心思路是建立可視化模型，通過(guò)建立模型之間的數據結構來(lái)實(shí)現應用模型的搭建。采用模型解釋方法取代代碼生成方法，一鍵部署和運行，而不需要再編輯、編譯和運行。
在擴展性方面，Mendix 使用 Java 語(yǔ)言編寫(xiě) Java action，擴充 micorflow 來(lái)使用定制代碼，解決復雜業(yè)務(wù)問(wèn)題；如果有更復雜業(yè)務(wù)，還可以使用提供的 DSLs 來(lái)調用。
同時(shí)，Mendix 提供了一套完善的基礎開(kāi)發(fā)框架，允許使用敏捷方法來(lái)應用工具進(jìn)行模型開(kāi)發(fā)，最小模型為領(lǐng)域模型和 GUI 模型，services 和外部數據源等。
可以看到，針對可視化開(kāi)發(fā)可能存在的功能性、開(kāi)源、安全性、開(kāi)發(fā)效率等問(wèn)題，Mendix 至少都提供了一些解決方案。我們目前還無(wú)法完整評估這種解決方案是否高效，但至少在應用層面已經(jīng)完全夠用。從 Mendix 官網(wǎng)所提供的應用實(shí)例來(lái)看，可視化工具已經(jīng)在某些開(kāi)發(fā)領(lǐng)域體現出它相對于傳統編程的優(yōu)越性。
我們選擇 iVX 作為國內可視化開(kāi)發(fā)平臺的代表，是因為它是真的秀，在很多方面讓人耳目一新。來(lái)，讓我們康康，iVX 的首頁(yè)一上來(lái)就號稱(chēng)它重構了一套可視化開(kāi)發(fā)語(yǔ)言，Emmm，感覺(jué)有點(diǎn)暴躁，它是否真的能做到呢？
首先 iVX 告訴我們，“可視化編程”并不一定意味著(zhù)“拖放”。iVX 完全摒棄了被人詬病的塊拼接模式，通過(guò)對象樹(shù)方式來(lái)定義對象結構，通過(guò)事件面板的方式來(lái)定義對象間的交互邏輯和數據邏輯。
可以說(shuō)，iVX 在進(jìn)行編程邏輯可視化的基礎上，很好地保留了了原生的開(kāi)發(fā)邏輯。例如，在事件這部分不是通過(guò)逐一為每個(gè)對象添加響應條件的方式來(lái)進(jìn)行，而視采用條件、循環(huán)、動(dòng)作、回調模塊互相組合的方式來(lái)做，所有事件都被集成在一個(gè)面板里，一目了然。
而尤其值得表?yè)P的是它的 IDE，采用不同的顏色區分各種對象和事件模塊，并支持對所有對象、數據和事件的搜索，能夠添加備注，感覺(jué)有點(diǎn)厲害。
在開(kāi)源性和擴展性方面，iVX 支持接入 API 和 JS 代碼。同時(shí)非常有意思的是，他們還搞了一個(gè)叫小模塊的東西，允許用戶(hù)把自己開(kāi)發(fā)的一部分東西抽象成一個(gè)組件，在可復用性方面還是挺有創(chuàng )意的。
我們還看到，iVX 采用了前后端分離的數據架構，這無(wú)疑是處于對數據的并發(fā)性能和安全性的考慮。在同類(lèi)應用當中這是一個(gè)比較具有前瞻性的布局，但是表現如何，還有待測試。
雖然說(shuō)重新定義編程語(yǔ)言這事兒還不好說(shuō)，但是 iVX 這款產(chǎn)品在很多方面都提出了一些具有創(chuàng )造性的解決方案，已經(jīng)足以讓人感到眼前一亮。它至少重新定義了一種新的零代碼開(kāi)發(fā)模式，幫助企業(yè)做一些建站、開(kāi)發(fā)一些 OA 應用啥的，應該不在話(huà)下。
基于上面的描述，我們可以看出，目前很多可視化開(kāi)發(fā)工具確實(shí)在技術(shù)領(lǐng)域取得了一些突破。核心發(fā)展的方向主要是兩個(gè)，一種在于為特定問(wèn)題或場(chǎng)景提供解決方案，如 Mendix 專(zhuān)注于可重復開(kāi)發(fā)，國內一些云平臺專(zhuān)注于為企業(yè)提供快速開(kāi)發(fā)模組。另外還有一些工具則試圖構建一款底層開(kāi)發(fā)工具，提供一種全局性的開(kāi)發(fā)思路，這個(gè)路無(wú)疑比較困難，但是他們也取得了不少進(jìn)展。從目前已經(jīng)商業(yè)化了的幾款工具來(lái)看，工具功能已經(jīng)發(fā)展到了可以勝任各類(lèi) WEB 應用、OA 應用甚至構建一些平臺的水準，也已經(jīng)建立了基本成熟的 aPaas 平臺的運營(yíng)模式，有一些大企業(yè)入駐并體會(huì )到了可視化開(kāi)發(fā)帶來(lái)的便利。
盡管可視化開(kāi)發(fā)工具并非一無(wú)是處，但它的問(wèn)題也非常明顯，距離真正重構技術(shù)生態(tài)還有著(zhù)漫長(cháng)的距離。例如在大企業(yè)最為看中的安全性和標準化問(wèn)題方面，既有工具都還不能提供完美的解決方案。而對于上下游資源的運營(yíng)和新生技術(shù)生態(tài)的建構，也尚顯幼稚。
可視化編程盡管在發(fā)展過(guò)程中經(jīng)歷了一些挫折，但近年來(lái)所取得的成就也應該受到關(guān)注。盡管開(kāi)發(fā)人員對于代碼的親近和工具的抵觸心理幾乎是無(wú)法解除的魔咒，類(lèi)似于一種精神潔癖。但是如果一款工具足夠完善，勢必能在技術(shù)層面撼動(dòng)這種固有成見(jiàn)。而當更多的開(kāi)發(fā)人員嘗試使用可視化工具，并積極在這一領(lǐng)域探索，可以預見(jiàn)，未來(lái)可視化編程不僅能參與底層的應用架構，還將幫助我們在更高層次上對事物進(jìn)行建模。
聯(lián)系客服
