低代碼本身基本上不可能成為“一個標準”，每家公司做法都不一樣，唯一的標準，只有“代碼”本身！
是否具有通用的代碼生成能力關系到很多底層問題，所有低代碼平臺都無法回避，甚至諱莫如深。
低代碼平臺最讓程序員反感的就是“證明我以前工作是沒有意義的，還要讓我買單！”，這里面最核心的問題，就是代碼問題！如果低代碼平臺成為“代碼快速生成器”，成為程序員的助手，應該情況就會好很多，我們來細致分析一下這個敏感的話題。
低代碼平臺能生成代碼嗎！？
注意，這里生成的代碼是“所開發應用的獨立代碼”，這個代碼是可以“脫離”平臺，獨立運行的那種。
這個可以提供程序員或使用的企業——最基礎的“安全感”！
如果沒有代碼生成，代表以后只能在這個平臺上開發，開發出來的應用只能在這個平臺運行，即“開發和運行環境鎖定”！
主要是低代碼平臺有如此之多，自身標準又不統一，你在一個平臺開發的應用并不能在其它平臺打開或運行，這就很尷尬了。如果這個平臺功能受限怎么辦？應用性能不行怎么辦？平臺不運營了怎么辦？
iVX、appgyver等就可以生成代碼，Wix、WordPress、odoo等也可以。
當然代碼生成也包含很多個等級，例如：
（1）是前后臺代碼都能生成？還是只能生成后臺代碼？或只能生成前端代碼？——最大多數低代碼平臺如果生，也是生一種。
（2）能否生成數據庫的代碼？自動生成SQL？
（3）最好生成的后臺代碼能后和運行時資源解耦，能接云計算盡量接云計算？
生成代碼能力方面呢，iVX應該是最強的，在以上這些中。
只有能夠首先生成代碼，才有后面的然后…
平臺生成代碼可以和程序員手寫代碼基本“無差別”嗎！？
什么叫無差別呢？
生成代碼易用性，可以和現有常見開發環境和代碼資源整合
生成的代碼最好采用常見的流行框架，例如前端VUE或者react等，后臺生成JAVA或Node語言。我并不是覺得JQ或PHP不好，而是現在確實會比較小眾一些，這個不屬于我們重點討論的話題。同時，最好能支持mysql、ES、redis、MQ等多類型的數據庫或后臺常見產品。如果能夠和現有的代碼開發流程也能整合那就更好了！例如Git等代碼管理工具。
生成代碼可讀性，程序員可以直接復用或二次開發（要做到這一點，基本上就是低代碼行業的天花板了）
大家常常提到程序員“不喜歡”“至少是不支持”低代碼，可是為什么呢？深層次原因還是程序員將“低代碼”當成了自己飯碗的“競爭者”，而并非是“收入”和“效率”提升的貢獻者！而在一個企業中，技術選型誰說了算？當然還是“程序員”，這就形成了一個悖論。“低代碼平臺想搶程序員的飯碗，還要程序員買單！”。
雖然也有程序員不喜歡ChatGPT或代碼補全工具，但是似乎要溫柔很多，而且更多的程序員還是持贊成態度的。
如果根據這個特征，反思一下低代碼生態，那就很清楚了，低代碼必須要得到程序員的認可才有出路（那么就一次全部毀滅，直接AI生成完整應用，短時間內還很難）。
生成代碼涉及到很多“尖端”技術，例如編譯器/解釋器的開發，AST的開發等等，因此要想生成代碼本來就不容易，生成具有可讀性的代碼就更難了。
iVX 已經能夠自動生成可讀代碼（我們將在文章最后放一點生成代碼片段…）。
生成代碼運行效率還要高…
不是很容易證明誰比誰寫的代碼更好？這是一個比較復雜的問題。但是基本上可以從幾個點來進行判斷：
（1）生成應用打開的速度？運行時卡不卡頓？
（2）寫一個類似的程序，跑一下，打開控制臺看看有什么區別？另外，就是看看加載文件的大小？
（3）后臺可以壓測一下，看看高并發的情況。對于這個問題，我認為最好是把“計算”、“存儲”、“安全”、“帶寬”等都交給云計算平臺來處理和控制。（這是iVX的做法，也就是“只幫用戶生成程序本身，和后臺運行時需要資源解耦”）
調試和運行代碼和以前方式“無差別”
iVX可以生成前端、后臺和數據庫代碼。以生成前端代碼為例，可以直接保存成.vue的文件，直接在現有VScode等流行的代碼IDE中進行動態調試，任意增加代碼，并通過編譯。
甚至可以將iVX的前端代碼編譯成vue和react的component在現有的前端代碼中進行調用。
下面是導出代碼范例，就是一個簡單頁面，但是生成格式應該很多前端同學都是可以看和可以改的。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。