把 ERP／MES 重複頁面收斂成 Config-driven UI Pattern

情境

在華新麗華，我主要開發的是 ERP 與 MES 內部系統。

這類系統有一個很鮮明的特性：

畫面很多、流程很多、資料欄位很多，但真正拆開來看，大量頁面其實都在重複相似的操作。

例如：

• 查詢資料
• 顯示列表
• 編輯欄位
• 新增／修改／刪除
• 驗證資料
• 依狀態控制可以執行的操作

如果每新增一張 ERP 或 MES 畫面，就重新寫一次 Table、Form、Toolbar 與資料流，功能雖然做得出來，但系統會很快累積大量「長得不太一樣、其實做著同一件事」的程式碼。

我的判斷與做法

我開始嘗試把這些反覆出現的 UI 行為拆成兩部分：

哪些是所有頁面共同的運作方式，哪些才是真正屬於這個畫面的差異。

共通的資料流、CRUD 行為、欄位顯示與編輯模式逐步整理成固定 Pattern；

真正不同的部分，例如：

• 有哪些欄位
• 欄位如何顯示
• 欄位如何編輯
• 資料從哪裡取得
• 畫面允許哪些操作

則盡量用結構化設定描述，而不是每個頁面重新實作一次。

這時候我還沒有把它稱為一套完整的 Config-driven Framework，但「讓程式處理共通規則、讓設定描述差異」這個設計方向，已經開始成形。

形成的結果

ERP／MES 中反覆出現的頁面結構與資料操作，可以沿用一致的 UI Pattern 與 Data Flow。

新增功能時，開發重點逐漸從：

「再寫一張新的 CRUD 頁面」

轉成：

「描述這張頁面與既有 Pattern 有哪些不同。」

這也降低了不同模組各自形成不同 UI 與資料處理方式的機會。

留下的思考

這段經驗後來成為我 Config-driven 思維很重要的起點。

當大量畫面本質上遵循相同規則時，我開始意識到：

真正值得被寫成程式的，是共通規則；反覆變動的部分，更適合被描述成資料或設定。

這個想法後來在我的工作裡持續放大。

到了 Gorilla，我遇到真正成熟的 Config-driven No-code Framework；再往後，我甚至開始用 AST 直接從程式碼推導 Framework 所需要的 Schema。