低代碼無法走出的困境——低代碼平臺(tái)的三大悖論！（低代碼平臺(tái)的實(shí)現(xiàn)方式）

【iVX不在這個(gè)討論之列，iVX生成完整代碼，應(yīng)歸入“圖形化編程語言”大類?！?/p>

低代碼平臺(tái)架構(gòu)的三大悖論之一：為“企業(yè)服務(wù)”量身定制，但又“平臺(tái)鎖定”！

幾乎所有的低代碼平臺(tái)，包括低代碼概念的提出者“Mendix/Outsystems/Appian/Power Apps…”幾乎都存在“平臺(tái)鎖定”的現(xiàn)象。而且這種“鎖定”機(jī)制有一點(diǎn)像當(dāng)年的Oracle，是“不斷積累”的鎖定（不像SaaS產(chǎn)品切換起來相對(duì)比較容易），低代碼平臺(tái)由于需要把研發(fā)資源不停在平臺(tái)上積累，所以一旦大規(guī)模投入之后，由于無法生成源代碼（或無法生成完整源代碼），企業(yè)就很難脫離平臺(tái)，這就是所謂的平臺(tái)鎖定。

這也是這么多年“低代碼”很難快速發(fā)展的核心“阻礙”，沒有企業(yè)愿意重蹈覆轍，讓當(dāng)年的“Oracle模式”再次上演。只要企業(yè)還能生存下去，可持續(xù)的安全還是企業(yè)的“Priority One”。

低代碼平臺(tái)架構(gòu)的三大悖論之二：把“開發(fā)者”和“業(yè)務(wù)人員”放在同一產(chǎn)品中！

從產(chǎn)品角度來講，“開發(fā)者”和“業(yè)務(wù)人員”壓根兒就是屬性和背景知識(shí)完全不同的兩波人，甚至“思維模式”可能都是完全沖突的。低代碼平臺(tái)由于“產(chǎn)品設(shè)計(jì)”上的問題，不得不做成“一個(gè)平臺(tái)”，然后忽悠出了“Citizen Developer”的概念。最終的結(jié)果就是搞的“研發(fā)的同學(xué)使用起來非常不方便”而“業(yè)務(wù)的同學(xué)完全看不懂和學(xué)不會(huì)”，兩邊都不討好！

其實(shí)，在我看來，把不同的人員拉到同一個(gè)平臺(tái)，實(shí)則“無奈之舉”，沒有想出更好解決方案的“權(quán)宜之計(jì)”。所以低代碼平臺(tái)在企業(yè)內(nèi)部，兩邊得不到待見，推行起來自然也就阻力重重了。

低代碼平臺(tái)架構(gòu)的三大悖論之三：“簡單應(yīng)用”沒必要，“復(fù)雜應(yīng)用”比寫代碼慢！

如果是簡單應(yīng)用，那么“SaaS”就已經(jīng)很好使了，沒有必要引入“低代碼”（之所以叫低代碼，就是開發(fā)過程中還是很難避免“代碼”的）。那么用“低代碼”來開發(fā)復(fù)雜應(yīng)用呢？對(duì)于很多平臺(tái)來說，由于很多原因，其實(shí)很可能比使用代碼開發(fā)還要慢！

原因大體有那么幾種：

（一）需要使用很多工具或引擎，沒有完整的開發(fā)IDE。

操作繁瑣，步驟和窗口太多，功能分散，導(dǎo)致雖然有一些代碼省下來，但是整體操作次數(shù)和操作時(shí)間并沒有縮短。

（二）“畫流程圖”來表達(dá)邏輯，過于復(fù)雜。

不知到從哪一家低代碼開始，大家都喜歡通過“畫圖”的方式來表達(dá)“程序邏輯”，而畫圖的方式往往帶來的直接解決就是“很慢”?。ㄎ抑酪サ舸a，必須使用“圖形化”的方式來表達(dá)邏輯，但是“圖形化”不只有“畫圖”，我傾向iVX鼠標(biāo) 面板的模式，明顯效率會(huì)高很多。感覺大家都被“流程圖”帶偏了。）

（三）組件太少或組件的抽象和封裝還沒有做好。（這個(gè)就不細(xì)說了）