.NET 初學者架構設計指南（二）：初識 OO 設計的血淚教訓

前言：一場外包專案引發的設計災難

初次嘗試物件導向（OO）設計時，我幾乎犯了設計者能犯的所有錯誤。那是一個國外外包專案：對方負責功能設計，我方負責編碼與測試。由於缺乏經驗與溝通，專案陷入了「改需求、改架構、改代碼」的無限循環，最終在交付前三天仍在通宵趕工。這段經歷讓我深刻認識到：OO 設計不是畫類圖，而是管理複雜度、應對變化的藝術。

錯誤一：未看懂設計文檔就擅自修改架構

功能設計書存在邏輯漏洞，導致關鍵流程在 Linux 上無法跑通。我未與投資方確認，私自將模塊移植到 Windows。雖然流程跑通了，但完全偏離了客戶真實意圖——他們要的是「香蕉」，設計書寫的是「蘋果」，我卻做出了「橘子」。最終不得不在三天內把「橘子」改回「蘋果」再偷偷改成「香蕉」，代價是連續通宵、代碼質量淪喪、測試流於形式。

教訓：任何架構變更必須經過利益相關方確認；不理解業務意圖的技術決策都是盲目賭博。

錯誤二：工作量評估極度樂觀

第一階段做出一個跑通「Tom、Jerry、王小帥」數據的 Demo，便以為後續只是「砍瓜切菜」。我為每個畫面預估 3 人天，實際卻超過 10 人天。原因在於：設計不完美、理解偏差、團隊共識缺失。頻繁開會、朝令夕改、大量返工吞噬了編碼時間，測試與性能優化被擠壓至無。

教訓：Demo ≠ 產品；工作量評估應基於歷史數據與風險緩衝，而非願望思維。

錯誤三：半吊子技術選型與自造輪子

投資方指定 J2EE 棧：JBoss + Tomcat + Struts + Entity Bean。我對這些技術一竅不通，公司安排的導師又極其忙碎。擔心 Entity Bean 效率低（大量反射），我決定自寫 ORM：每張表對應一個 Value Object（僅含 getter/setter）與一個 Gateway（負責 SQL 映射）。為應對海量表，開發了代碼生成器自動遍歷數據庫結構生成這些類——這本質上是一個簡易 ORM，當時卻不知 Hibernate 為何物。

為解決跨數據庫 SQL 差異，又手寫 SqlParser 介面與多個具體 Parser 轉換 ANSI SQL。數據層終於跑通，但上層業務邏輯該如何用這堆 VO？我陷入了更大的困境。

錯誤四：錯誤的分層與「傳聲筒」模式

聽從導師「頁面不應直接調用業務代碼，耦合太強」的建議，我為每個畫面建立 Session Bean 封裝業務流程，並在頁面與 Session Bean 之間硬塞了一層 Helper——它純粹做參數透傳，零業務邏輯。後果是：任何需求變更都要連鎖修改「數據庫 → 代碼生成器 → VO/Gateway → Session Bean → Helper → 頁面」，維護成本指數級上升。更糟的是，為解決性能問題，我不得不在生成的 Gateway/VO 中手寫查詢邏輯，導致再生成代碼時需手工合併，OO 的優勢蕩然無存。

核心反思：我在用 OO 方式解決 OO 自身造成的問題——過度設計、錯誤抽象、缺乏領域模型思維。

給初學者的建議

1. 先懂業務，再動代碼：不理解領域語言的類設計全是垃圾。
2. 拒絕過早優化與自造輪子：成熟框架（Hibernate、Spring）經過無數專案驗證，先學會用好它們。
3. 分層要有意義：每一層都應承擔明確職責，單純透傳的層是反模式。
4. 擁抱變化，而非恐懼變化：好的 OO 設計應讓局部修改不波及全局，而非製造連鎖反應。
5. 溝通成本遠低於返工成本：不確定時多問一句，少改十天代碼。

這段經歷雖然慘痛，卻成為我職業生涯最寶貴的「反面教材」。願每位初學者能少走彎路，早日掌握 OO 設計的真諦。