一、國內軟體業的「低水平重複」困境
從 DOS 年代的 FoxBase 財務系統、VB/PB 重寫、B/S 架構再重寫、到如今 RIA 再重寫。每次技術浪潮，廠商與客戶都在「重寫」中耗盡資源，程式設計師在追趕框架中迷失業務本質。這是**耦合度過高、規範性不足**導致的必然結果：應用系統無法適應環境變化，只能推倒重來。
二、組件化演進脈絡：COM → CORBA → EJB → Spring
- COM/CORBA： 早期嘗試解決二進位重用與跨語言互通，但生態碎片化、複雜度高。
- EJB 1.x/2.x： 強制分層、解耦、聲明式服務 (交易/安全)，解決許多問題，但門檻極高，導致大量失敗專案。
- .NET： 借鏡 J2EE 並降低門檻，但 RAD 風格誘導開發者再次寫出高耦合代碼。
- Spring (Rod Johnson)： 基於 EJB 實戰經驗，**簡化而非顛覆**，以 IoC/DI 實現無侵入式組件裝配，保留組件化核心價值。
Spring 不是為了「簡化」而簡化，而是為了**更純粹地落實組件化解耦思想**。初學者若只記住「簡化」而忽略「組件化根源」，終將重蹈覆轍。
三、走向軟體工業化：分工、標準、互信
汽車工業靠高度分工（橡膠、鋼鐵、設計、焊接、行銷各專其長）達成規模經濟。軟體業同理：
- 基礎設施已就緒： OS、DB、語言、中介軟體皆由國際巨頭建構。
- 企業級領域仍缺乏標準化組件： 國人習慣「全棧自幹」、不尊重專業分工、不信任第三方庫、熱衷 NIH (Not Invented Here) 症候群。
- 解決之道： 以 Spring 為核心，將成熟代碼封裝為可重用 Jar/模組，建立企業內部/跨企業組件庫生態，嚴格要求：高耦合系統不收、無組件庫不收、無測試不收、無文檔不收。
四、行動呼籲
