狂奔 lion

學過軟件工程的都知道，軟件產品的生產周期是一個經歷若干階段的漫長過程，包括需求獲取 - 設計 - 開發 - 維護等等。

需求階段 - 總想考慮到所有的問題，或是一切按合同辦事。但在現實中根本不得能，因此很多公司開始提倡“隨需而變”的能力，希望快速的響應用戶的需求變化
維護階段 - 總希望自己開發出來的東西一勞永逸，永遠不要再產生任何麻煩，產生了麻煩也不要找到我。甚至有些項目組的人員開發出來一大堆不成熟的產品、項目后撒手不管，走人了事，毫無職業操守，亦是對自身行業聲譽（至少是國內IT服務提供商聲譽）的一個打擊。真正的項目開發不應該這樣，一定是非常易于維護的，能夠快速地找出問題的所在，或是新需求切入點的所在，然后解決

很明顯，前面提到的兩個問題都要也只能通過設計和開發來解決。問題來了，怎樣開發出的軟件才能快速地響應需求，易于維護？可以有很多不相沖突的說法，比如解耦，比如通過POJO封裝數據等等。這些東西流行開來以后，很多人有疑問，為什么我的項目中一定要用這些框架？我不用這些框架也可以快速的開發出我要的功能，而且更加簡單，等等。如果孤立地從設計和開發的角度看這些問題，這種說法并沒有錯誤，但是如果從整個軟件開發的生命周期來看，則不是這樣。當然，這里還有一個是否“過度設計”的trade-off在里面，不過那又是另一個話題了。

再說說各種各樣的平臺吧，它們和框架不同，軟件體系結構中有一種架構模型即層次模型，我們現在的TCP/IP協議棧即屬于這種模型，我們的軟件對于平臺產品的依賴是一種朝向穩定的依賴，就好像我們在調試代碼時往往不會去調試操作系統API的bug一樣，因此在開發這種平臺層次級別的產品時就沒有必要再去采用那些為了保障“企業應用”Web軟件生命周期中所采用的方法了，完全可以用最基礎，最底層的手段。只要能夠做到高效、穩定即可。因此，平臺中間件產品的開發必須和應用軟件產品分開來看，雖然它們可能都在用Java這種編程語言。