＊＊ 本文同步發表於 軟體設計鮮思維FB社群 ＊＊
上星期我在教授 TDD.NET 測試驅動開發課程。其中有位學員分享他們公司會計系統的部分程式碼 (沒有機密性議題)，想知道這該如何撰寫單元測試 (Unit Test Code)。
我先用 EA (Enterprise Architect) UML 工具掃描程式碼反轉為 類別 (Class) 圖，老天！數百個 Windows Form (每一個 Form 他們稱為 Report) 全連接到一顆共用的 DB Manager，封裝了基本的 CRUD 行為，再存取資料庫。剛掃進來時還真嚇了一跳跳，那個 Form 的連線，有如積體電路般密密麻麻的共同連接到如同就是 CPU 地位的 DB Manager！
這肯定就是典型技術人員的傑作，用許多稀奇古怪的實作方式，讓所有的表單 UI 程式，傳進來 SQL 敘述，然後再去存取資料庫。看似方便簡單，但這顆萬用的 DB Manager 已經被約束了特定的實作技術與特定的資料庫，所以當然無法抽換，原來他們使用 ADO.NET 的連線，現在是不可能換成 Entity Framework；不僅如此，內部程式碼的擁腫肥大，當時的技術人員一離開，幾乎達到無法維護的地步。
還有，他們許多相關於會計的企業邏輯，都零散分佈在表單程式，或用 "艱澀難懂的 SQL 字串" 包起來，可說是毫無組織可言。想要改成 Web 版？想要擴展或修改功能？那當然只有重寫一途！
有趣的是，前桌另一位算是較為資深的同學無奈說道，他們公司的程式碼基本結構也是如此。 !^^
所以，這樣到底如何撰寫所謂以 "類 (Class)" 為單位的單元測試程式呢？
答案是：沒有辦法！也沒有意義！！ (雖然勉強來說技術還是可行的)
要我的話，我寧願重寫！嗯，這字眼不好聽，就叫 "重整" 好了。 注意！重整與重構 (Refactoring) 可是完全不同喔，重構的前提是建基在有單元測試程式碼的前提下。
怎麼辦！？這位年輕的學員才剛從某機構的就業養成班結業沒多久，對軟體業這行可還是充滿了憧憬。但如今接到這種超級燙手 (前述的資深技術人員已離職) 的系統維護，這可如何是好？
我建議他比較有機會的緩衝方案：
1. 既有的系統維護，逐步理出共用價值最高的企業邏輯，將之抽離出來放在自行設計的共用 Service 物件上，並且馬上就要為其撰寫單元測試程式。
2. 新開發的功能，務必至少以小功能模組 (Small Functional Module)為開發/維護範圍，一開始就抽離出屬於該模組相關邏輯的 Service 物件，然後還是用原來習慣的方式設計 DBManager 物件，但被收斂侷限在該模組內，如此讓其的共用耦合性盡量降低。
現在這位學員的軟體設計能力尚不足，若待逐漸對結構面的設計觀念提升 (當然要實作面配合)，這也才比較有機會施以後續的結構重整-也就是重構的實踐了。
先以小功能模組為單位的開發 (會計 Domain 不了解，如果以人事來說，例如 考核、出缺勤、請假等功能模組，甚至還可以再更細部的模組分解)，讓其有著基本的 3-Tier (Presentation、Business Logic、Data Source) 分層結構，如此未來的延展性才有機會。
當然更講究來說，可以參考個人所規劃的 Enterprise MVC (版內檔案區有 Model 檔可下載參考，或以其當關鍵字可參閱原來有撰寫的文章) 分層結構框架。如此系統的彈性、延展性更好，更有機會創造系統的再利用價值。