為什麼現代的低程式碼開發平臺都不支援匯出原始碼？

摘要：本文由葡萄城技術團隊於部落格園原創並首發。轉載請註明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。

初次接觸低程式碼的程式設計師大多會糾結一個問題，為什麼功能越強大的低程式碼開發平臺越不會提供匯出原始碼的功能？

要想回答這個問題，我們得回顧一下低程式碼開發的發展史。事實上，支援匯出原始碼的低程式碼工具，是上一個時代的產品了。現在，大多數還有研發能力而且願意推進產品化的低程式碼廠商都已經完成了或者正在進行向後設資料驅動的轉型。

站在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後設資料）

將程式導向的程式碼切換為面向結果的後設資料，視覺化開發從「一錘子買賣」到持續覆蓋，視覺化開發終於發揮出了應有的價值。下面是兩種技術路線的特性對比：

回到文章開頭的問題。作為一名程式設計師，如果你希望使用低程式碼開發工具構建並長期維護一個軟體專案，請趁早拋棄「匯出原始碼」的想法，因為低程式碼最大的價值並不是像可設定的程式碼模板一樣，初次建立一個頁面或業務邏輯，而是降低長期的開發和維護成本。選擇一個產品化程度高（重點關注頁面和邏輯設計的靈活度、檔案、教學和開發者社群），採用後設資料驅動技術路線的低程式碼開發平臺吧，比如葡萄城的活字格低程式碼開發平臺，如果有必要按照廠商提供的類似於「外掛」或「子系統整合」的方式進行擴充套件開發。

如果你做的是「一錘子買賣」的專案，後續將維護工作完全移交給甲方，那就別用低程式碼。讀別人寫的程式碼很痛苦，讀機器生成的沒有註釋的程式碼簡直是噩夢。大家都是程式設計師，同行何苦為難同行？