模式與XP
Joshua Kerievsky著，Gigix 譯
概述
模式和極端編程（XP）都為軟件設計、開發者提供了無法用金錢衡量的幫助。但是迄今為止XP大量關注於重構（refactoring），而對模式只字不提。在這篇文章中，我問“為什麼”，並且最終描述出模式怎樣以XP的方式更好地實現、以及XP怎樣因為包含對模式的使用而變得更好。
致謝
非常感謝Kent Beck、Martin Fowler和Ward Cunningham，他們為這篇文章提出了友善的評論。
--------------------------------------------------------------------------------------------------------------------------------
仍在所知不多的時候我們就開始了自己的程序設計生涯，生產出的軟件也反映出了我們的缺乏經驗：我們創建的代碼臃腫、錯誤百出、脆弱、難以維護、難以擴展。隨著時間的流逝，我們成為了更好的軟件設計者：我們從技術作家、專家那裡學習，我們從自己的錯誤中學習。現在我們編寫具有高度靈活性的軟件，它適應廣泛而且堅固。當被請求編寫一個新的系統時，我們知道查明當前和將來的需求，這樣我們可以設計軟件來處理當前和將來的需要。
在軟件開發生涯的這個階段，極端編程告訴我們，我們經常對軟件過分設計（over-engineer）了。我們從自己的錯誤中學到了太多，我們不希望重復這些錯誤，所以我們在系統生命周期的早期做了大量的努力來創造靈活而堅固的設計。不幸的是，我們沒有認識到：如果這個系統永遠不需要這個程度的靈活性和堅固性，那麼我們所有的工作就都沒有意義了。我們過分設計了。
我也曾經過分設計過。說實話，與其他設計者坐在一間房間裡考慮如何設計軟件來適應許多當前和將來的需求，這的確是一種樂趣。我們把自己學到的所有東西——尤其是那些最好的經驗——應用在設計中。我們常常知道需求的列表會改變，但用戶或客戶總是改變需求。不過，我們認為我們可以足夠聰明地設計軟件，使軟件足夠靈活，使它能應付所有的需求變化。
典型的過分設計。
今天，極端編程將告訴你這是多麼愚蠢的做法。XP說，我們必須讓設計自己顯現出來，而不是去預測設計將是什麼樣子。XP說，“做可能起作用的最簡單的事”，因為“你將不再需要它”。另外，Kent Beck說：
你需要在一個強調溝通、簡單、反饋和勇氣的價值系統中選擇最好的工作方法，這樣你才能勇敢的脫離過分設計。[Beck1 00]
同意。但是，現在我必須提到我的朋友Norm Kerth。Norm在軟件開發領域有豐富的經驗和見識。一年以前我問他“對XP有什麼想法”。他說：
