初次接觸低代碼的程序員大多會糾結一個問題，為什么功能越強大的低代碼開發平臺越不會提供導出源代碼的功能？
要想回答這個問題，我們得回顧一下低代碼開發的發展史。事實上，支持導出源代碼的低代碼工具，是上一個時代的產品了。現在，大多數還有研發能力而且愿意推進產品化的低代碼廠商都已經完成了或者正在進行向元數據驅動的轉型。
站在2023年，國內低代碼行業的廠商多樣性太強，魚龍混雜。為了說清代碼生成器和元數據驅動的差異和優缺點，我們可以用Windows桌面程序的可視化開發作為類比，畢竟Visual Studio可以算是低代碼的鼻祖之一了。
最初Visual Studio和更早期的Visual Basic在設計界面時采用了代碼生成器的技術方案，IDE將用戶拖拽控件、設置屬性的動作直接翻譯成操作這些控件的代碼。用戶可以直接獲取到這些代碼，如果有需要則可以通過修改這些代碼來實現對VS可視化開發能力的擴展。
（Visual Studio 生成的WinForm代碼）
這種做法歷史悠久，可以上溯到90年代。有點很明顯，這種做法對IDE來說，實現起來最簡單，用戶動手修改起來也是比較方便的。然而，如果用戶真的使用這種做法開發一個大型的項目并長期維護，就會發現放任開發人員對designer generated code部分進行修改，先不提如何讀懂設計器生成的沒有注釋的代碼，很容易導致后續的可視化操作沖掉一部分手工修改的代碼，甚至連可視化設計頁面都無法打開。可視化開發成了“一錘子買賣”，長期來看，可視化開發帶來的開發效率和可維護性優勢都非常有限。畢竟，軟件不是一蹴而就的，而是需要長期的維護和迭代，才能充分發揮出價值。
為了解決這個問題，讓可視化開發可以長期發揮效用，微軟在做新一代桌面應用開發方式時參考了Web中使用的HTML技術，2008年推出了WPF技術。使用Visual Studio開發WPF應用的界面時，IDE將用戶拖拽控件、設置屬性的結果保存為XAML格式（一種XML）的元數據。因為XAML本身就是可視化設計的結果，可以和可視化設計器一一對應，用戶對XAML的修改可以實時反饋到可視化設計頁面，這就是Visual Studio默認的Split視圖。用戶可以隨時在可視化開發和編碼擴展之間切換，適配開發階段和維護階段。
（Visual Studio生成的WPF元數據）
將面向過程的代碼切換為面向結果的元數據，可視化開發從“一錘子買賣”到持續覆蓋，可視化開發終于發揮出了應有的價值。下面是兩種技術路線的特性對比：
|
評價標準 | 生成源代碼 | 生成元數據 |
產品化程度 | 低（需通過混淆來保護版權） | 高 |
擴展開發的推薦方式 | 修改生成的源代碼 | 開發插件（元數據標簽） |
可視化開發覆蓋度 | 創建時 | 全生命周期 |
總體的可維護性 | 差 | 好 |
總體的開發效率 | 低（與編碼開發接近） | 高 |
回到文章開頭的問題。作為一名程序員，如果你希望使用低代碼開發工具構建并長期維護一個軟件項目，請趁早拋棄“導出源代碼”的想法，因為低代碼最大的價值并不是像可配置的代碼模板一樣，初次創建一個頁面或業務邏輯，而是降低長期的開發和維護成本。選擇一個產品化程度高（重點關注頁面和邏輯設計的靈活度、文檔、教程和開發者社區），采用元數據驅動技術路線的低代碼開發平臺吧，比如葡萄城的活字格低代碼開發平臺，如果有必要按照廠商提供的類似于“插件”或“子系統集成”的方式進行擴展開發。
如果你做的是“一錘子買賣”的項目，后續將維護工作完全移交給甲方，那就別用低代碼。讀別人寫的代碼很痛苦，讀機器生成的沒有注釋的代碼簡直是噩夢。大家都是程序員，同行何苦為難同行？
如果想了解更多低代碼信息，歡迎私信回復“低代碼”了解更多~
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
