低代碼本身基本上不可能成為“一個標準”，每家公司做法都不一樣，唯一的標準，只有“代碼”本身！

是否具有通用的代碼生成能力關系到很多底層問題，所有低代碼平臺都無法回避，甚至諱莫如深。

低代碼平臺最讓程序員反感的就是“證明我以前工作是沒有意義的，還要讓我買單！”，這里面最核心的問題，就是代碼問題！如果低代碼平臺成為“代碼快速生成器”，成為程序員的助手，應該情況就會好很多，我們來細致分析一下這個敏感的話題。

低代碼平臺能生成代碼嗎?。?/p>

注意，這里生成的代碼是“所開發(fā)應用的獨立代碼”，這個代碼是可以“脫離”平臺，獨立運行的那種。

這個可以提供程序員或使用的企業(yè)——最基礎的“安全感”！

如果沒有代碼生成，代表以后只能在這個平臺上開發(fā)，開發(fā)出來的應用只能在這個平臺運行，即“開發(fā)和運行環(huán)境鎖定”！

主要是低代碼平臺有如此之多，自身標準又不統(tǒng)一，你在一個平臺開發(fā)的應用并不能在其它平臺打開或運行，這就很尷尬了。如果這個平臺功能受限怎么辦？應用性能不行怎么辦？平臺不運營了怎么辦？

iVX、appgyver等就可以生成代碼，Wix、WordPress、odoo等也可以。

當然代碼生成也包含很多個等級，例如：

（1）是前后臺代碼都能生成？還是只能生成后臺代碼？或只能生成前端代碼？——最大多數低代碼平臺如果生，也是生一種。

（2）能否生成數據庫的代碼？自動生成SQL？

（3）最好生成的后臺代碼能后和運行時資源解耦，能接云計算盡量接云計算？

生成代碼能力方面呢，iVX應該是最強的，在以上這些中。

只有能夠首先生成代碼，才有后面的然后…

平臺生成代碼可以和程序員手寫代碼基本“無差別”嗎?。?/p>

什么叫無差別呢？

生成代碼易用性，可以和現有常見開發(fā)環(huán)境和代碼資源整合

生成的代碼最好采用常見的流行框架，例如前端VUE或者react等，后臺生成JAVA或Node語言。我并不是覺得JQ或PHP不好，而是現在確實會比較小眾一些，這個不屬于我們重點討論的話題。同時，最好能支持mysql、ES、redis、MQ等多類型的數據庫或后臺常見產品。如果能夠和現有的代碼開發(fā)流程也能整合那就更好了！例如Git等代碼管理工具。

生成代碼可讀性，程序員可以直接復用或二次開發(fā)（要做到這一點，基本上就是低代碼行業(yè)的天花板了）

大家常常提到程序員“不喜歡”“至少是不支持”低代碼，可是為什么呢？深層次原因還是程序員將“低代碼”當成了自己飯碗的“競爭者”，而并非是“收入”和“效率”提升的貢獻者！而在一個企業(yè)中，技術選型誰說了算？當然還是“程序員”，這就形成了一個悖論。“低代碼平臺想搶程序員的飯碗，還要程序員買單！”。

雖然也有程序員不喜歡ChatGPT或代碼補全工具，但是似乎要溫柔很多，而且更多的程序員還是持贊成態(tài)度的。

如果根據這個特征，反思一下低代碼生態(tài)，那就很清楚了，低代碼必須要得到程序員的認可才有出路（那么就一次全部毀滅，直接AI生成完整應用，短時間內還很難）。

生成代碼涉及到很多“尖端”技術，例如編譯器/解釋器的開發(fā)，AST的開發(fā)等等，因此要想生成代碼本來就不容易，生成具有可讀性的代碼就更難了。

iVX 已經能夠自動生成可讀代碼（我們將在文章最后放一點生成代碼片段…）。

生成代碼運行效率還要高…

不是很容易證明誰比誰寫的代碼更好？這是一個比較復雜的問題。但是基本上可以從幾個點來進行判斷：

（1）生成應用打開的速度？運行時卡不卡頓？

（2）寫一個類似的程序，跑一下，打開控制臺看看有什么區(qū)別？另外，就是看看加載文件的大??？

（3）后臺可以壓測一下，看看高并發(fā)的情況。對于這個問題，我認為最好是把“計算”、“存儲”、“安全”、“帶寬”等都交給云計算平臺來處理和控制。（這是iVX的做法，也就是“只幫用戶生成程序本身，和后臺運行時需要資源解耦”）

調試和運行代碼和以前方式“無差別”

iVX可以生成前端、后臺和數據庫代碼。以生成前端代碼為例，可以直接保存成.vue的文件，直接在現有VScode等流行的代碼IDE中進行動態(tài)調試，任意增加代碼，并通過編譯。

甚至可以將iVX的前端代碼編譯成vue和react的component在現有的前端代碼中進行調用。

下面是導出代碼范例，就是一個簡單頁面，但是生成格式應該很多前端同學都是可以看和可以改的。