### 何謂重構 我總是不太樂意為什么東西下定義，因為每個人對任何東西都有自己的定義。但是當你寫一本書時，你總得選擇自己滿意的定義。在重構這個題目上，我的定義以Ralph Johnson團隊和其他相關研究成果為基礎。 首先要說明的是：視上下文不同，「重構」這個詞有兩種不同的定義。你可能會覺得這挺煩人的（我就是這么想），不過處理自然語言本來就是件煩人的事，這只不過是又一個實例而已。 第一個定義是名詞形式： 重構（名詞）：對軟件內部結構的一種調整，目的是在不改變「軟件之可察行為」前提下，提高其可堙鮮性，降低蘇修改成本。 你可以在后續章節中找到許多重構范例，諸如Extract Method 和 Pull Up Field等等。一般而言重構都是對軟件的小改動，但重構可以包含另一個重構。例如Extract Class通常包含Move Method 和 Move Field。 「重構」的另一個用法是動詞形式： 重構（動詞）：使用一系列重構準則（手法〕，在不改變「軟件之可察行為」前提 下，調整其結構。 所以，在軟件開發過程中，你可能會花上數小時的時間進行重構，其間可能用上數十個不同的重構準則。 曾經有人這樣問我：『重構就只是整理代碼嗎？』從某種角度來說，是的！但我認為重構不止于此，因為它提供了一種更高效且受控的代碼整理技術。自從運用重構技術后，我發現自己對代碼的整理比以前更有效率。這是因為我知道該使用哪些重構準則，我也知道以怎樣的方式使用它們才能夠將錯誤減到最少，而且在每一個可能出錯的地方我都加以測試。 我的定義還需要往兩方面擴展。首先，重構的目的是使軟件更容易被理解和修改。你可以在軟件內部做很多修改，但必須對軟件「可受觀察之外部行為」只造成很小變化，或甚至不造成變化。與之形成對比的是「性能優化」。和重構一樣，性能優化通常不會改變組件的行為（除了執行速度），只會改變其內部結構。但是兩者出發點不同：性能優化往往使代碼較難理解，但為了得到所需的性能你不得不那么做。 我要強調的第二點是：重構不會改變軟件「可受觀察之行為」——重構之后軟件功能一如以往。任何用戶，不論最終用戶或程序員，都不知道已有東西發生了變化。（譯注：「可受觀察之行為」其實也包括性能，因為性能是可以被觀察的。不過我想我們無需太挑剔這些用詞。） **兩頂帽子** 上述第二點引出了Kent Beck的「兩頂帽子」比喻。使用重構技術開發軟件時，你把自己的時間分配給兩種截然不同的行為：「添加新功能」和「重構」。添加新功能時，你不應該修改既有代碼，只管添加新功能。通過測試（并讓測試正常運行〉，你可以衡量自己的工作進度。重構時你就不能再添加功能，只管改進程序結構。此時你不應該添加任何測試（除非發現先前遺漏的任何東西），只在絕對必要（用以處理接口變化〕時才修改測試。 軟件開發過程中，你可能會發現自己經常變換帽子。首先你會嘗試添加新功能，然后你會意識到：如果把程序結構改一下，功能的添加會容易得多。于是你換一頂帽 子，做一會兒重構工作。程序結構調整好后，你又換上原先的帽子，繼續添加新功能。新功能正常工作后，你又發現自己的編碼造成程序難以理解，于是你又換上重構帽子……。整個過程或許只花十分鐘，但無論何時你都應該清楚自己戴的是哪一頂帽子。