1.6 設計模式能夠解決哪些問題

請大家仔細想想，我們為什么要寫程序？按照一般的說法，我們寫程序是想用某種編程語言（例如，本書所用的Java語言），寫出讓人容易看懂，同時又讓計算機能夠正確執行的代碼，以解決某個特定的問題。但是接下來，我們換一個角度來考慮。

我們能不能把寫程序想象成一個目標？之所以有這樣一個目標，在大多數情況下，是因為我們想滿足某種需要或需求。于是，我們必須界定這個目標能夠達成什么樣的效果，還要界定有哪些功能不是這個目標所追求的。明確了目標之后，我們就開始采取各種能夠實現此目標的措施。我們會反復評估自己是否已經達成目標，如果還沒有達成，那就調整我們在實現目標的過程中所使用的各種手法，直至寫出一個能夠解決問題的程序。我們在這個過程中肯定會遇到各種困難，這一點在前面幾節中說過了。

為了應對這些困難，我們可能總是想編寫新的代碼，而不是去考慮怎么合理地沿用已有的代碼。有的時候，這些新的代碼看上去好像能讓項目繼續推進，但實際上，它可能只是把當前遇到的問題給掩蓋了起來，而沒有將其徹底解決。

現在許多開發團隊都遵照SCRUM框架進行開發（參見本章第4個參考資料）。于是，我們想象有這樣一個采用該框架來開發應用程序的團隊，這個團隊的開發工作逐漸偏離了正軌。每天的站會似乎都很順利，因為每次都有人指出程序中的某個關鍵錯誤（bug）。而且這樣的bug每次都能在幾天之后被修復，于是皆大歡喜。奇怪的是，匯報錯誤的頻率越來越高（或者說，bug越修越多），然而不管有多少bug，這個團隊依然一個又一個地將其修復，于是大家還是覺得蠻好。但這真的意味著項目處于正軌嗎？這樣做出來的應用程序真的能正常運作嗎？我們需要好好想一想才行。

除了這些，還有一個更嚴重的狀況：待辦事項列表（backlog）越寫越長，這里出現了各種有待實現的功能與有待解決的技術問題。當然，技術問題（或者說，技術債務）本身并不一定是壞事。如果能夠正確地面對，那么技術債務可以促使我們更為積極地推進項目，這種作用在概念驗證階段尤其明顯。但如果我們不能正確地面對，換句話說，我們沒能及時發現技術問題，或是我們雖然發現了，但是忽視它，不把它當回事，那么這些技術債務就會阻礙項目的發展。要是我們明明看到了技術問題卻不想承認，而是把它說成有待開發的新功能，那問題就尤為嚴重。

雖說產品待辦事項列表本身應該是一個實體，但它實際上由兩個不同且不兼容的部分組成，即業務和沖刺待辦事項（主要是技術債務）。當然，團隊正在處理來自計劃會議的沖刺待辦事項，但如果技術債務過多，那么會導致團隊沒有太多時間去實現業務功能。如果這種情況頻繁出現，則意味著每次給新的沖刺計劃會議做規劃時，團隊都無法將足夠的開發資源投放到實現業務功能上。大家仔細想想，自己的團隊是否也出現過因為積壓的技術問題過多而無法推進產品的局面。

SCRUM方法的理念可以歸結為勇氣、專注、決心、尊重與開放。但這些理念并不是SCRUM框架獨有的。每一個想要交付優秀產品的團隊都應該很樂于接受這套理念。

我們接著說剛才的那個團隊。項目走到了很難往前推進的地步，大家都在為怎樣清晰界定各自的技術分工而爭論。于是，整個團隊陷入一種雖然在工作，但是已偏離其目標的狀態。我們會發現，每次討論都特別艱難，因為總有各種各樣的理由讓我們沒辦法適當地描述出有待解決的問題。團隊成員可能無法再有效地溝通，而是開始相互誤解。我們發現軟件的熵（entropy，混亂程度）變大了，因為整個軟件已經失去條理。到了這種地步，我們就可以說這個項目正在變糟，這意味著我們會浪費許多開發時間去做一些沒有意義的事情。

請大家再次停下跟我一起想想看，如何才能避免這樣的狀況。其實這種狀況是有辦法觀察出來的。通常，每個團隊都有一些共性，我指的是雖然團隊中各成員的知識水平可能不太一樣，但如果投入同樣多的精力不再能夠產出跟原來一樣多的成果（也就是所謂學習曲線開始變緩），那么他們還是能夠察覺出這一點的。

我們可以根據項目的推進速度，判斷這個項目是否正在變糟。如果團隊不能像原來那樣朝著目標穩步推進項目，而是總把時間花在修復小的技術問題上，那就要當心了。因為這些小的成功并不符合SCRUM的價值，而且一直陷在這種問題中也無法推進項目。針對這些小問題所提出的解決方案，對于整個項目來說，不能算作一項進展，因為這樣的方案只是讓這個小問題本身變得比原來好一些，而沒有讓整個項目有所改觀，況且這樣的方案或許還與技術規范相違背。在打造這種解決方案的過程中，團隊并沒有獲得一些將來能用到的知識。由于團隊無法及時做出需要的功能，或者只能做出其中的一部分功能，因此有可能錯失市場機會。

除了推進速度變慢，還有一些癥狀也能幫助我們意識到項目正在變糟。比方說，如果業務功能變得很難測試，那也要當心。出現這種狀況時，項目中各個組件的功能變得很難觸發，各部分之間的依賴關系變得較為混亂，這樣的代碼難于閱讀，也難于測試，而且還與程序員所應堅持的開發紀律不符。此時我們會發現，軟件設計師的日常工作竟然變成了想辦法趕緊修復bug，以結束某個工單，而不是如何設計新的功能。

接下來的各章，我們將介紹許多種設計模式，以解決剛才說的那些常見問題，從而令項目不會變糟。設計模式與OOP的基本理念（包括A、P、I、E）是互相契合的，而且有助于我們更好地堅持SOLID原則。

另外，設計模式還能讓我們盡早發現一些錯誤的走向，提醒我們盡量復用已有的代碼，而不要重新去發明現成的代碼，這就是所謂DRY原則，即Don't Repeat Yourself（不要重復自己）。