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

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

然後再更進一步瞭解，開發的系統範圍很廣，從典型的門診掛號系統、看診系統、藥劑管理系統，到甚至是人事系統，都需要自行開發。喔，這就是典型的醫療 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)