轉載請保留作者信息：

作者：88250

Blog：http:/blog.csdn.net/DL88250

MSN & Gmail & QQ：DL88250@gmail.com

我認為，要成為優秀的軟件設計者，學習軟件設計的演化（尤其是設計演化）比學習軟件設計更為重要。只有從演化的過程中才能看清設計的本質。

?

以往，我們只注重設計，認為設計是優質軟件制造的必要條件。但好的設計往往是依靠設計者多年從事此行的經驗，特別是所謂的“大規模軟件”，此類軟件的設計過于依賴于經驗，過于依賴于人的個體行為。這樣的依賴過于具體。

?

記得OO原則中有一條 Dependence Inversion：抽象不應該依賴于細節，細節應該依賴于抽象。如果把軟件設計比作是細節，而設計演化比作是抽象的話，可以這樣理解：設計演化不應當依賴于涉及本身，設計本身應該依賴于設計演化。為什么這么說呢？

?

總所周知，軟件設計的產出物是一系列的設計文檔，最終產物是源代碼，即軟件設計的產出物是源代碼。關于軟件設計到底是什么的討論一直沒有最權威的定義。但我一直堅信“源代碼就是設計”的論斷（Jack W.Reeves 1992, 什么是軟件設計），設計過程中產生的文檔只能算是輔助文檔，它們根本不是設計。

?

假若你也同意以上觀點，那么一些問題出現了，其中我認為有一個問題是至關重要的：目前任何源代碼都是特定語言編寫的，代碼一旦編寫完畢，無論合理運用了多少優秀的模式，最后也是難于擴展的和維護的。

?

設計是軟件過程的一部分，從宏觀設計，即架構設計層次上看，設計必須要選定技術方案。一點點很關鍵，但技術方案是相當具體的，技術方案不只會對設計產生影響，也會對設計的演化產生巨大的影響。這樣的做法就是讓演化強烈依賴于設計了。

?

因此，我認為正確的做法應該是讓設計依賴于演化，也就是應該重視軟件設計的演化過程，而不是重視設計。這一點就是 Kent Beck 所提到的“從迭代中演化架構”，但這一觀點引起了太多的爭論。

?

前不久，作為架構設計師與主程序員，我參與了一個詞典項目。這個項目提出了一種新穎的詞典服務方式，圍繞開放式、以用戶在線工作平臺為目標而展開。在設計前期，我花了很多時間分析需求。而實際上，所有“需求”都是我假設出來的。客戶只說了要做一個這樣的創新項目。在與項目經理商量后，我們決定以XP方式進行項目。

?

開始時，我們以用戶素材（User Story）的方式歸納了需求，排序了它們，并以Java作了實現。隨著迭代的進行，代碼開始變多，集成開始稍微有些復雜了。最令人頭疼的問題是我們自己定義的需求時常被我們自己更改，甚至一些在迭代1中認為是系統特性的需求，卻在迭代2的計劃中將它整個刪除！

?

為了適應這樣的經常性“手術”，我們不斷地重構代碼，并逐漸形成了自己的可擴展、類插件式的應用框架，其核心是一系列的抽象工廠與一系列的抽象接口層次。后來，在查閱了關于Java的可擴展應用后，我突然想起

了eclipse！我們的應用就是需要這樣一個類插件系統，以方便擴展新的特性。在翻閱了eclipse的底層框架——OSGi的規范與一些參考文檔后，我決定將我們的項目遷移到OSGi上來。

?

遷移過程是無痛的，因為我們迭代產生的設計一直擁有低耦合、組件化的特征；遷移過程也是痛苦的，因為我們拋棄了幾乎所有我們自己框架的代碼。不過，這次演化是成功的，因為我們的目的達到了，系統在OSGi框架上運行地很好！

?

我的經驗與Garmma（eclipse項目負責人）是比不了的。當時eclipse2.x到eclipse3.0的時候不知道小了多少決心、做了多少時間與調研。的確，軟件演化同任何生物進化一樣，其過程是痛苦的，但結果應該是美好的！

?

舉上面的例子，我只想說明一個事實：軟件設計演化遠遠比軟件設計本身重要。敏捷方法，尤其是XP，它能讓你感覺到什么是真正的軟件設計！

?

轉載于:https://www.cnblogs.com/lanzhi/archive/2008/04/20/6470357.html

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的设计演化与设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。