### 重構與設計 「重構」肩負一項特別任務：它和設計彼此互補。初學編程的時候，我埋頭就寫程序，渾渾噩噩地進行開發。然而很快我便發現，「事先設計」（upfront design）可 以助我節省回頭工的高昂成本。于是我很快加強這種「預先設計」風格。許多人都把設計看做軟件開發的關鍵環節，而把編程（programming）看做只是機械式的低級勞動。他們認為設計就像畫工程圖而編碼就像施工。但是你要知道，軟件和真實器械有著很大的差異。軟件的可塑性更強，而且完全是思想產品。正如Alistair Cockburn所說：『有了設計，我可以思考更快，但是其中充滿小漏洞。』 有一種觀點認為：重構可以成為「預先設計」的替代品。這意思是你根本不必做任何設計，只管按照最初想法開始編碼，讓代碼有效運作，然后再將它重構成型。事實上這種辦法真的可行。我的確看過有人這么做，最后獲得設計良好的軟件。極限編程〔Extreme Programming [Beck, XP] 的支持者極力提倡這種辦法。 盡管如上所言，只運用重構也能收到效果，但這并不是最有效的途徑。是的，即使極限編程（Extreme Programming）愛好者也會進行預先設計。他們會使用CRC卡或類似的東西來檢驗各種不同想法，然后才得到第一個可被接受的解決方案，然后才能開始編碼，然后才能重構。關鍵在于：重構改變了「預先設計」的角色。如果沒有重構，你就必須保證「預先設計」正確無誤，這個壓力太大了。這意味如果將來需耍對原始設計做任何修改，代價都將非常高昂。因此你需要把更多時間和精力放在預先設計上，以避免日后修改。 如果你選擇重構，問題的重點就轉變了。你仍然做預先設計，但是不必一定找出正確的解決方案。此刻的你只需要得到一個足夠合理的解決方案就夠了。你很肯定地知道，在實現這個初始解決方案的時候，你對問題的理解也會逐漸加深，你可能會察覺最佳解決方案和你當初設想的有些不同。只要有重構這項武器在手，就不成問題，因為重構讓日后的修改成本不再高昂。 這種轉變導致一個重要結果：軟件設計朝向簡化前進了一大步。過去未曾運用重構時，我總是力求得到靈活的解決方案。任何一個需求都讓我提心吊膽地猜疑：在系統壽命期間，這個需求會導致怎樣的變化？由于變更設計的代價非常高昂，所以我希望建造一個足夠靈活、足夠強固的解決方案，希望它能承受我所能預見的所有需求變化。問題在于：要建造一個靈活的解決方案，所需的成本難以估算。靈活的解決方案比簡單的解決方案復雜許多，所以最終得到的軟件通常也會更難維護——雖然它在我預先設想的方向上的確是更加靈活。就算幸運走在預先設想的方向上，你也必須理解如何修改設計。如果變化只出現在一兩個地方，那不算大問題。然而變化其實可能出現在系統各處。如果在所有可能的變化出現地點都建立起靈活性，整個系統的復雜度和維護難度都會大大提高。當然，如果最后發現所有這些靈活性都毫無必要，這才是最大的失敗。你知道，這其中肯定有些靈活性的確派不上用場，但你卻無法預測到底是哪些派不上用場。為了獲得自己想要的靈活性，你不得不加入比實際需要更多的靈活性。 有了重構，你就可以通過一條不同的途徑來應付變化帶來的風險。你仍舊需要思考潛在的變化，仍舊需要考慮靈活的解決方案。但是你不必再逐一實現這些解決方案，而是應該問問自己：『把一個簡單的解決方案重構成這個靈活的方案有多大難度？』如果答案是「相當容易」（大多數時候都如此〉，那么你就只需實現目前的簡單方案就行了。 重構可以帶來更簡單的設計，同時又不損失靈活性，這也降低了設計過程的難度，減輕了設計壓力。一且對重構帶來的簡單性有更多感受，你甚至可以不必再預先思考前述所謂的靈活方案——一 旦需要它，你總有足夠的信心去重構。是的，當下只管建造可運行的最簡化系統，至于靈活而復雜的設計，唔，多數時候你都不會需要它。 **勞而無獲** —— Ron Jeffries Chrysler Comprehensive Compensation（克萊斯勒綜合薪資系統）的支付過程太慢了。雖然我們的開發還沒結束，這個問題卻已經幵始困擾我們，因為它已經拖累了測試速度。 Kent Beck, Martin Fowler和我決定解決這個問題。等待大伙兒會合的時間里，憑著我對這個系統的全盤了解，我開始推測：到底是什么讓系統變慢了？我想到數種可能，然后和伙伴們談了幾種可能的修改方案。最后，關于「如何讓這個系統運行更快」，我們提出了一些真正的好點子。 然后.我們拿Kent的量測工具度量了系統性能。我一開始所想的可能性競然全都不是問題原因。我們發現：系統把一半時間用來創建「日期」實體（instance）。更有趣的是， 所有這些實體都有相同的值。 于是我們觀察日期的創建邏輯，發現有機會將它優化。日期原本是由字符串轉換而生，即使無外部輸入也是如此。之所以使用字符串轉換方式，完全是為了方便鍵盤輸入。好， 也許我們可以將它優化。 于是我們觀察日期怎樣被這個程序運用。我們發現，很多日期對象都被用來產生「日期區間」實體（instance）。「曰期區間」是個對象，由一個起始日期和一個結束日期組成。仔細追蹤下去，我們發現絕大多數日期區間是空的！ 處理日期區間時我們遵循這樣一個規則：如果結束日期在起始日期之前，這個日期區間就該是空的。這是一條很好的規則，完全符合這個class的需要。釆用此一規則后不久，我們意識到，創建一個「起始日期在結束日期之后」的日期區間，仍然不算是清晰的代碼，于是我們把這個行為提煉到一個factory method(譯注：一個著名的設計模式， 見《Design patterns》，由它專門創建「空的曰期區間I 。 我們做了上述修改，使代碼更加清晰，卻意外得到了一個驚喜。我們創建一個固定不變的「空日期區間」對象，并讓上述調整后的fatory method每次都返回該對象，而不再每次都創建新對象。這一修改把系統速度提升了幾乎一倍，足以讓測試速度達到可接受程度。這只花了我們大約五分鐘。 我和團隊成員〔Kent和Martin謝絕參加）認真推測過：我們了若指掌的這個程序中可能有什么錯誤？我們甚至憑空做了些改進設計，卻沒有先對系統的真實情況進行量測。 我們完全錯了。除了一場很有趣的交談，我們什么好事都沒做。 教訓：哪怕你完全了解系統，也請實際量測它的性能，不要臆測。臆測會讓你學到一些東西，但十有八九你是錯的。