入題：使用 SSH 個人感覺 最大的隱患就是 升級維護。包括SSH之外的其他組建比方說Log4j,Dom4j等，到不是說這些組建不支持擴展維護困難。回到議題中，新的需求到來時SSH組建已經升級，新版本的組建中提供了大量實用的工具和技術策略讓快速的解決新需求帶來的開發(fā)時間。但是由于維護的項目使用的是老的技術設計，所以不能冒昧的替換原有的SSH框架。因為無法確定新組建在原有框架上運行的穩(wěn)定性和兼容性。為此需要做大量的測試來確定。這是在最初系統(tǒng)設計時沒有考慮的。其實已經有很多的這類問題以及解決方法我舉幾個：1)使用老技術維護更新。2)對需求進行變更來適應老系統(tǒng)環(huán)境。3)重新開發(fā)一個新項目，將新項目部署在一起。4)重構項目，對項目進行一次大的改版。5)開發(fā)并維護自己的核心技術。6)使用組建兼容的系統(tǒng)架構。上面列出的6種方法除了最后一種沒有遇到之外，其都遇到過，甚至采用過。最后一種方法可以使解決組建依賴帶來的危機。但是也有弊病，那就是要維護大量的組建。不過還好維護組建總比上面4個解決方法要好。第5種方案，在大一點的公司中普遍使用，因為項目經常面臨這些問題，一個軟件的生命周期往往很久，這段時間內技術更新不知道已經幾個來回了。所以只會選擇一些變化不大的，技術很固定的組建，比方說郵件組建，XML組建。這些組建基本一成不變，然后在搭配一個強大的開發(fā)語言開發(fā)自己的核心技術。任憑技術更新，這些公司只需要維護自己的核心技術就好了。回到例子中，如果這個web項目在先前沒有采用這么多框架技術，在新需求來臨時僅僅維護一下自己的核心技術就適應了新需求，同時核心技術又得到了提升。構建核心技術不是一件簡單的事情。但是至少需要有這方面的努力，就像每個程序員都曾有收集代碼的時候。