上個星期六開始,連著週六、日與本星期六(昨天)共三日,是對高雄某家大型醫院的資訊中心教授軟體設計課程,這已經是連續三個星期到高雄授課了,而其中兩個單位都是醫院,還真是巧。

透過兩個醫院的授課,才讓我瞭解到,原來醫療系統幾乎都是內部的資訊中心自行開發的,這與我原來想像系統大部分是委外開發的,大有不同,而據他們告訴我的原因,主要在於維護性的問題,所以無法全權委外,因為變動性的問題,委外單位不足以快速反應變更。

然後再更進一步瞭解,開發的系統範圍很廣,從典型的門診掛號系統、看診系統、藥劑管理系統,到甚至是人事系統,都需要自行開發。喔,這就是典型的醫療 ERP 系統啊。我常戲稱,什麼叫做 ERP(Enterprise Resource Planning) 系統呢? 不知道開發範圍的,就是 ERP 系統啦。

此次該單位找我授課的主要原因是,他們希望透過所謂的 OO 物件導向技術,來協助他們改善系統的難以維護。因為他們導入了 OOP,但是怎麼覺得用 OO 設計出來的元件,一方面很難開發,二方面好像沒有感受到 OO 的美好,好像系統也沒那麼有彈性,所以希望我透過教學,並檢視他們的開發成果,能給予他們一些建議。

原來上星期的授課,是與之協調後決定要講授 「UML 三劍客」的課程內容,那是以使用案例的需求為優先,然後快速導出到實作,是很有效的一種務實的作法。 不過上課了一天後,該單位包括較資深的技術長等資訊人員,問了很多現實他們遇到的問題,也拿出了部分的開發成果請我協助檢視。 我發現到,他們更在乎的是系統的共用性議題,當然還有關於物件的實作議題。 這些反而不是需求性的議題了,而是在於系統內部的結構性設計議題,以及實作面如 O-R Mapping 的系統設計問題了。

我對課程內容的態度是,一切都是彈性可以調整的,不會是一成不變,是可以視各單位現實的需求,動態甚至利用他們的案例當場馬上作分析並導出到實作。所以第三天的課程呢,我就給它調到了對結構分析這部分的重點來了,並且此次也請了我們另一位講師 Steve,協助來講授從領域模型轉到 .NET Coding 實作的部分。

嗯嗯,為 OO 而 OO,一向是我最反對的。我發現到,有太多所謂 OO 的開發,對於物件在中間層的實作,幾乎都僅在於對資料的存取。 所以設計出來所謂的企業物件(business object),根本就是資料物件(data object)而已,而為了資料存取,去設計與實作出這麼多的資料物件,實在沒啥意義的。 設計企業物件的重點是在於對於企業邏輯的處理,如何分門別類、然後把責任(企業規則)分派在適當的物件上,才是所謂物件導向的精髓。 這可是相當不容易耶,領域概念轉成軟體物件,要能抓得好,又要能適切地分派責任,再加上還要能轉成到現實平台上,包括 O-R Mapping 的設計議題,以及包括對 Performance 的資源控管等,這可是要結合領域專家、IT平台專家、與軟體專家的,缺一不可。


仔細分析,若絕大部分只是資料的存取,而且一般仍對企業規則到底要分派到那個物件上,其實沒那麼重視 (若是產品的開發,這個就很重要了);不過他們很渴望能將分散在 UI表單(script-based)與資料庫(stored-procedure)內的企業邏輯,給集中控管到中間層來,這是相當合理的,也可以說是許多傳統 Client-Server 2-tier 的軟體系統,來轉移(migrate)到所謂 3-tier,降低 UI 與 資料庫的耦合(coupling)性,是最必然的設計開發議題。 將企業邏輯集中在中間層是正確的作法,只是倒不是要絕對馬上就設計所謂的企業物件,那個難度真的相當高,可是要耗費掉相當多的開發成本的。

嗯嗯,有兩個字彙,倒是軟體人員也可以思考一下。 一為 Revolution;另一為 Evolution。前者我把它翻譯叫做 “革命”,後者我是稱之為 “革新”。兩者哪裡不一樣? 革命是要抱著不成功便成仁的二分法;而革新是採漸進的作法,一次只改一點點,有了成效後再往前推進。 前者當然會比較快,但要相當有決心。只是,說真的,我幾年來看到的幾位是物件基本教義派的先烈們,似乎... 要求老闆給他們資源,來導入所謂的 OO 系統開發,但好像不幸都壯烈成仁了,專案毀了,人也跟著離開軟體業界了~

喔喔,聽了我的說法,他們好像不願意採取革命的作法,所以問我革新的作法如何作? 其實呢,並不難,為每一個需求的案例設計一個控制型(control)的物件,先讓其真的有實體三層的結構,把從 UI 與資料庫的企業邏輯給集中起來。 事實上,控制物件往往也具有 BPO(business process object)物件的性質,它可以針對某一個特定的需求功能,至資料庫撈出所需要的關連資料作處理;也可以具有 “wrapper” 物件的角色,可以呼叫原來就已經寫好放在資料庫的 stored-procedure,”ReUse” 原來就有的企業邏輯。 要光是能做到這一個階段,算是功德無量了,這起碼已經進展了一大步(從實體的 2-tier 到 3-tier),風險也不高。 下一階段待老闆真的相信(不要太期待老闆會看得遠,大部分是很現實,他們要能眼見為憑),且肯願意投入更多的資源,此時真的要去找出所謂 “共用” 超穩定的企業物件,或是要從原來寫在 stored-procedure 的企業邏輯,抽絲剝繭,這就是結構重整的範疇了,從程式碼的角度來看,好像就是最近很熱的重構(Re-Factoring)—不影響既有功能的前提下,對系統內部的結構元素作重整,使得系統更有彈性。

很多問題,其實根本不是問題,常常是因為局部雜亂無章、沒有整體性考量,才去衍生出來的問題。只有透視問題的本質,找出根本的原因,釐清對的方向後,再來就是審視現有的資源與環境,採取務實的作法,一次只解決一個問題,而不是把所有的問題來拿出想要一次解決,這比較有可能把事情做好。沒這麼困難、沒這麼困難的啦。

昨天,最後一天星期六的課程結束後,我還與那個 Steve 走到高雄火車站附近的「六合夜市」吃小吃。 其實夜市規模不大耶,甚至還比我們家中和附近的「興南夜市」還小一些、人潮還少一些呢。 我們先是吃了有家是店面的「台南擔仔麵」,客人很多,哇! 麵與小菜等真是相當好吃,在台北還沒吃過哪麼好吃的,只是麵量蠻少的,而價錢其實還有些小高。 還吃了那個什麼 蛋蛋魚,以前都沒聽說過,那個攤位還有與人手臂一樣粗的花枝,開玩笑,對於大的東西,我一向不敢吃。然後又買了烤蝦、菱角酥、新疆烤肉、酪梨牛乳等,拿到高鐵火車內享受。 只是,不好吃,那個烤蝦啊,看來是先用開水燙過,然後客人要點時烤一下作個樣子而已,很不實在。 回程從夜市坐計程車到左營高鐵站, Steve 說,怎麼每條路都比台北的忠孝東路還寬,人潮又很少。 喔,高雄真的地大人少,天氣又好,真是個居住的好地方。

※ 延伸參考:
 o 連著三天在三個單位的輔導與授課 (2008/04/15~17)