軟件開發中的思維僵化：從 SSH 框架看程序員成長陷阱與突圍之道

框架是雙刃劍：SSH/SSI 帶來的思維固化危機

在 J2EE 黃金時代，Struts、Spring、Hibernate (SSH) 以及 Spring、SpringMVC、iBATIS (SSI) 無疑是企業級開發的基石。它們融合了大師級的設計模式，極大降低了入門門檻，規範了開發流程，提升了生產效率。然而，任何工具的過度依賴都會成為思維的牢籠。

一、框架的「壞處」在哪裡？

1. 降低門檻 ≠ 降低要求

「XX 天精通 XX」類書籍讓零基礎者快速上崗，短期解決了就業問題，長期卻培養了「用時再學、知其然不知其所以然」的投機心態。大量開發者停留在 API 調用層面，對算法、數據結構、JVM 原理、網絡協議等底層知識一無所知。

2. 規範演變為僵化

企業為了管控風險，將「最佳實踐」固化為「強制規範」：
반드시寫 Action、Service 接口、ServiceImpl、DAO 接口、DAOImpl…
無論業務多麼簡單，五層架構一行不少。久而久之，開發者以為「Web 開發就該這樣寫」，失去了架構選型的判斷力。

3. 設計模式濫用

見到釘子就用錘子，簡單的 CRUD 硬套工廠、代理、模板方法，導致代碼層層包裹、調用鏈極長，維護成本劇增。

二、為什麼會陷入這種困境？

以經典的 MVC 分層為例：

• V (View)：視圖層，數據展示
• C (Controller)：調度層，請求分發、服務編排
• M (Model)：服務層 + 數據層 (Service + DAO)，業務邏輯與數據訪問

錯誤現象：
❌ Controller 寫業務邏輯
❌ Service 直接操作數據庫
❌ DAO 包含業務判斷
❌ 新增功能 = 照抄舊代碼改字段，完全不考慮復用

三、正確的突圍之道

1. 單一職責，專注核心

2. 模塊化思維：積木而非整體

需求像異形建築，兩種建造方式：
🅰 整體澆築：一次性寫死，下次重寫 → 技術債務指數級增長
🅱 積木拼裝：拆解為通用模塊（方法、類、組件），新需求 = 現有積木 + 少量膠水代碼

Service 應該是領域服務的組合，而非單一巨大的事務腳本。Controller 編排多個細粒度 Service，Service 組合多個 DAO/Repository 操作。

3. 大而化之：打破層數迷信

分層本質是依賴倒置與關注點分離，而非死板的層數。
業務簡單時：Controller → Service → Repository (三層足矣)
業務複雜時：引入 Domain Service、Application Service、Facade、DTO 轉換層…
架構服務於業務，而非業務服務於架構。

四、給開發者的建議

1. 追求極致的「處女座」精神：重構時多問幾個「為什麼」，忍受初期的緩慢與痛苦
2. 夯實計算機基礎：數據結構、演算法、作業系統、網絡、數據庫原理
3. 懂框架更要懂原理：閱讀源碼，理解 IOC/AOP 實現、連接池原理、事務傳播機制
4. 適度的「懶惰」是美德：但前提是擁有自動化構建、測試、部署能力的「苦功夫」積累

工具越先進，越考驗使用者的基本功。
C 程序員轉 Java 容易，Java 轉 C 難，因為前者習慣了現成的輪子，後者習慣了親手造輪子。
中庸 ≠ 平庸，過猶不及，在框架便利與技術深度間找到平衡，才是資深工程師的必修課。