摘要：壞的味道指的是應該被修改，被重構的代碼，不具有可讀性，復用性，判斷邏輯復雜，冗余代碼。它們通常能指出代碼用途和實現手法之間的語義距離。把所有和這個變量相關的代碼新建一個類放入。但這往往不夠，請反復運用將某些行為移入類，直到者的協議一致為止。

壞的味道：指的是應該被修改，被重構的代碼，不具有可讀性，復用性，判斷邏輯復雜，冗余代碼。應該使用各種重構的手法去改變它！

如果你在一個以上的地點看到相同的程序結構，那么可以肯定的：設法將他們合而為一，程序會變得更好。

同一個類的兩個函數含有相同的表達式

兩個互為兄弟子類內含相同表達式

如果兩個毫不相關的類出現Duplicated Code 應該考慮對其中一個將重復代碼提煉到一個獨立類種，然后在另一個類內使用這個新類。

我們應當遵循這樣一條原則：每當感覺需要以注釋來說明點什么的時候，我們就需要說明的東西寫進一個獨立的函數中，并以器用途（而非實現手法）命名。

我們可以對一組甚至短短一行代碼做這件事。哪怕替換后的函數調用動作比函數自身還長，只要函數名稱能夠解釋其用途，我們也該毫不猶豫得那么做。關鍵不在于函數得長度，而在于函數:“做什么”和“如何做”之間得語義距離。

如何確定該提煉哪一段代碼呢？一個很好得技巧是：尋找注釋。它們通常能指出代碼用途和實現手法之間的語義距離。如果代碼前方有一行注釋，就是再提醒你L可以將這段代碼替換成一個函數，而且可以在注釋得基礎上給這個函數命名。就算只有一行代碼，如果他需要以注釋來說明，那也值得將它提煉導獨立函數去。

條件表達式和循環常常也是提煉得信號。可以使用Decompose Conditional處理條件表達是。至于循環，你應該將循環和期內的代碼提煉導一個獨立的函數中

如果類中有太多的實例變量，可以將幾個變量提煉至新類內。提煉時應該選擇類內彼此相關的變量，將它們放在一起

類內如果有太多代碼，把多余的東西消弭于類內部。如果有五個“百行代碼”，它們之中很多代碼都相同，那么或許你可以把它們變成五個“十行函數”和十個提煉出的“雙行函數”。

如果已有的對象發出一條請求就可以取代一個參數，那么你應該激活重構手法Replace Paramter with Method。在這里，“已有的對象”可能時函數所屬類內一個字段，也可能是另一個參數。你也可以運用Preserve Whole Object將來自同一個對象的一堆數據收集起來，并以該對象替換它們。如果某些數據缺乏合理的對象歸屬，可以使用Introduce Parameter Object 為它們制造出一個“參數對象”。

一旦需要修改，我們希望能夠跳到系統的某一點，只在該處做修改。如果不能做到這點，你就嗅出兩種相關的刺鼻味道中的一種了。

針對某一外界變化的所有相應修改，都只應發生在單一類中，而這個新類內的所有內容都應該反應此變化，為此，你應該找出某特定原因而造成的所有變化，然后運用Extract Class將它們提煉導另一個類中。

遇到某種變化，你都必須在不同類內做出許多小修改，你所面臨的壞味道就是shotgun Surgery，如果需要修改的代碼散布四處，你不但很難找到它們，也很容易忘記某個重要的修改

這種情況下應該使用Move Method和Move Field把所有需要修改的代碼放進同一個類。如果眼下沒有合適的類可以安置這些代碼，就創造一個。通常可以運用inline class把一系列相關行為放進同一個類。

Divergent change 是指“一個類受多種變化影響”，shotgun surgery則是指“一種變化引發多個類相應修改”。者兩種情況下你都會希望整理代碼，使“外界變化”與“需要修改的類”趨于一一對應。

函數對某個類的興趣高過對自己所處類的興趣，通常焦點便是數據，某個函數為了計算某個值，從另一個對象那調用幾乎半打的額取值函數。

療法顯而易見：把這個函數移至另一個地點。

一個函數往往會用到幾個類的功能，那么它究竟該被置于何處呢？我們的原則是判斷哪個類擁有最多被此函數使用的數據，然后把這個函數和那些數據擺在一起。

兩個類中相同的字段、許多函數簽名中相同的參數。這些總是綁在一起出現的數據真應該擁有屬于它們自己的對象

一個好的評判方法是：刪掉眾多數據中的一項。這么做，其他數據有沒有因而失去意義？如果它們不在有意義，這就是個明確信號：你應該為它們產生一個新對象。

對象的一個極大的價值在于：它們模糊（甚至打破）了橫亙于基本類型數據和體積較大類之間的界限

可以運用Replace Data Vlaue with Object將原本多帶帶存在的數據值替換為對象

如果想要替換的數據值是類型碼，而它并不影響行為，則可以運用Replace type Code with class 將它替換

如果有與類型碼有關的條件表達式，可運用 Replace Type Code with Subclass 或 Replace Type Code with State/Strategy

大多數時候，一看到switch語句，你就應該考慮以多態來替換它。問題是多態應該出現在哪兒？switch語句常常根據類型碼進行選擇，你要的是“與該類型碼相關的函數或類”

是Shotgun Surgery的特殊情況，在這種情況下，每當你為某個類增加一個子類，也必須為另一個類相應的增加一個子類。如果你發現某個繼承體系的名稱前綴和另一個繼承體系名稱前綴完全相同，便是聞到了這種壞味道

消除這種重復性的一般策略是：讓一個繼承體系的實例引用另一個繼承體系的實例。再運用Move Method 和Move Field，就可以就將引用端的繼承體系消弭于無形

如果一個類的所得不值其身價，它就該消失

如果某些子類沒有做足夠的工作，試試Collapse Hierarchy。對于幾乎沒用的組件，你應該以Inline Class對付它們

不要過分對的為未來考慮
如果你的某個抽象類其實沒有太大作用，請運用Collapse Hierarchy。不必要的委托可運用Inline Class除掉。如果函數的某些參數違背用上，可對它實施Remove Parameter。如果函數名稱帶有多余的抽象意味，應該對它實施rename Method，讓它現實一點

某個實例變量僅為某種特定的情況而設。這樣的代碼讓人不易理解，因為你通常認為對象在所有時候都需要它的所有變量，在未被使用的情況下猜測當初其設置目的，會讓你發瘋的。把所有和這個變量相關的代碼新建一個類放入。

如果你看到用戶一個對象請求另一個對象，然后后者請求另一個對象，然后再請求另一個對象這就是消息鏈

先觀察消息鏈最終得到的對象用來干什么的，看看能否以Extract Method 把使用該對象的代碼提煉到一個獨立的函數中再運用Move Method 把這個函數推入消息鏈

人們可能過度運用委托，會有某個接口有一半的函數都委托給其他類，這樣就是過度運用, 使用Remove Middle Man ，直接和真正負責的對象打交道

過分狎昵的類必須拆散. 你可以采用Move Method 和 Move Field 幫它們劃分界限, 從而減少狎昵行徑. 你可以可以看看是否可以運用Change Bidirectional Association to Unidirectional (將雙向關聯改為單向關聯)讓其中一個類對另一個斬斷情絲.

如果兩個類實在是情投意合, 可以運用Extract Class 把兩者的共同點提煉到一個安全的地點,讓它們坦蕩地使用這個新類. 或者也可以嘗試運用Hide Delegate讓另一個類來為它們傳遞相思情.

繼承往往造成過度親密, 因為子類對超類的了解總是超過超類的主管愿望. 如果你覺的該讓這個孩子獨立生活了, 請運用Replace Inheritance with Delegation 讓它離開繼承體系.

如果兩個函數做同一件事，卻有著不同的簽名，請運用Rename Method根據它們的用途重新命名。但這往往不夠，請反復運用?Move Method將某些行為移入類，直到2者的協議一致為止。如果你必須反復而贅余的移入代碼才能完成這些，或許可運用Extract SuperClass

如果只想修改類庫的一兩個函數，可以運用Introduce Foreign Method 如果想要添加一大堆額外行為，就得運用Introduce Local Extension

所謂Data Class是指：它們擁有一些值域（fields），以及用于訪問（讀寫〕這些值域的函數，除此之外一無長物。

這樣的classes只是一種「不會說話的數據容器」，它們幾乎一定被其他classes過份細瑣地操控著。這些classes早期可能擁有public值域，果真如此你應該在別人注意到它們之前，立刻運用Encapsulate Field?（封裝值域）將它們封裝起來。如果這些classes內含容器類的值域（collection fields），你應該 檢査它們是不是得到了恰當的封裝；如果沒有，就運用 Encapsulate Collection（封裝群集）?把它們封裝起來。對于那些不該被其他classes修改的值域，請運用 Remove Setting Method（移除設置函數）。

然后，找出這些「取值/設值」函數（getting and setting methods）被其他classes運用的地點。嘗試以Move Method（搬移函數）?把那些調用行為搬移到Data Class來。如果無法搬移整個函數，就運用 Extract Method（提煉函數）?產生一個可被搬移的函數。不久之后你就可以運用Hide Method?（隱藏某個函數）把這些「取值/設值」函數隱藏起來了。

指的是一個子類，不需要父類中的過多方法

這樣我們可以為這個子類創建一個兄弟類，把父類中不需要的方法下移到兄弟類中去。 如果子類復用了超類的行為（實現），卻又不愿意支持超類的接口。不過即使不愿意繼承接口，也不要胡亂修改繼承體系，應該運用Replace Inheritance with Delegation 來達到目的

引用作者的一句話"當你感覺需要撰寫注釋，請先嘗試重構，試著讓所有注釋都變得多余。"

并不是說寫注釋不好，而是當你寫一段很長的注釋來說明代碼邏輯的時候，說明這段代碼真的很糟糕，你就要考慮重構了。?