近未來 IT 程式開發

今年初(2009)看到 InfoQ 上匯集 2008 年度文章, 其中一篇 JRuby 開發者之一 Ola Bini 先生的相關文章 "Programming languages in future systems" , 將應用系統用到的語言類型分為三層, 印象很深刻 ... 因為幾乎花整個 2008 年的時間打造這樣的系統 ... 在讀到文章之前, 做起來不盡相同。在案子完成之際, 借用相似標題記錄一下這個過程。

大多數 IT 相關系統, 都是處理資料 ... 絕大部分的人都會同意這是領域(domain)主導, 不是技術主導。在一些廠商強力運作下, 開發人員近乎被催眠在執行一些固定工作 ... 選用主流技術(沒人喜歡意外), 然後踏上規劃, 分析, 設計, 實作, 測試, ... 的履帶。

在專案執行之前, 有 IT 主要廠商已下海幾年宣告失敗 ... 就不得不審視一些基本問題:

1. 這是一個財務資訊系統 (AIS, Accouting Information System) 主要得完成 "成本系統" ... 屬資料市集 (Data Mart) 規模, 資料變異不大但資料量大。


2. 使用者都全天候使用, 需求經常性改變 ... 使用角色的人數約開發者的 5 倍。


3. 之前系統是 dbase 系, 因為原廠不支持, 決定換 Java。要接手的 IT 部門沒人有經驗 ...

審視第一點 ... 之前也習慣用 ORM, 但時薪較我日薪還高的廠商都搞不定的資料量 ... 立馬決定透過 SQL 把資料處理的問題都丟給資料庫, 捨棄物件導向方式。

關於第二點 ... 全天候使用, 帶給系統更大的壓力。而需求改變, 更是許多系統不穩定的致命一擊。但揉合這兩個問題, 使用腳本(Scripting)語言達成快速變更, 測試就交給使用者(與開發人員關係良好) ... 原則上是這樣, 還有一些方式, 下段再述。

而最末一點 ... 要從頭學習 Java, 並好好發揮不是每個人都辦得到。但主要是匯入/匯出、維護/查找資料、檢核、計算、報表、傳票 ... 這幾件事，大致就是 SQL 加上個別功能就收工。後來都是 SQL 測試完成後, 再用樣板(template)套入功能 ... 大約可完成八、九成工作。

以技術拆解來看是: SQL + 腳本語言 + 功能模組樣板 ... 有人認為 Java 可達成, 的確也是。但 Java 的問題在於, 直接放 SQL 勢必會分段(SQL 都是長得誇張), 再加上變數會更亂; 而做成獨立檔案(iBatis 做法), 或 Stored Procedure 或 View, 造成非功能性分割, 竊認為是修改應用程式不易的禍首。

使用腳本語言就一個功能一個檔, 很直覺, 清清處處 ... 開發過程曾有 SQL 部份算式要改, 還是使用者(只會 SQL 查資料)直接指出哪邊要改。

專案開始(2007年中), 就決定使用Groovy, 即便用過 jython, 當時也較成熟; 而 jruby 如日中天 ... 但偏好 Groovy 補 Java 不足的角度, 特別是支援類似 python 三引號(triple-quotes)的樣板字串(template string), 可直接寫 SQL 再加上需要的變數、函式都很容易 ... 除了 Groovy 本身支援的 SQL, 後來也嵌入EBNF 的語法描述, 再來做 DSL 處理也很方便。

回頭看打造的系統與 Ola Bini 先生宣告三層類型的對應:

1. 穩定層(Stable layer): 沒與應用太多相關, 以靜態語言打造 ... Groovy 程式的載入、執行都是用 Java 寫的。


2. 動態層(Dynamic layer): 與應用相關, 以動態語言打造 ... 功能模組樣板(匯入/匯出, 檢核, 計算, ...), 都是用 Groovy 寫的 ... 像報表小計方式百百種, 都一一解決。


3. 領域層(Domain layer): 與應用相關, 以領域語言打造 ... 使用 SQL + Groovy 方式, 大抵 SQL 能動就了結。

其文中提到的 Drools 也有用到, 因為決策表格(Decision Table)對使用者更容易使用 ... 也在此做證言 :-)