【讀書筆記-重構與模式】 代碼壞味~

<重構與模式>中指出：

   重構，也就是對既有代碼設計的改善，要求你首Crowdsourced Security Testing道什麼樣的代碼需要改善。

   書中給出了12種代碼壞味的表現：

 

 1  重複代碼 2. 方法過長 3. 條件邏輯太複雜 4. 基本類型迷戀 5. 不恰當的暴露 6. 解決方案蔓延 7. 異曲同工的類 8. 冗贅類 9. 類過大 10 分支語句 11 組合爆炸 12 怪異解決方案。

另一份代碼壞味列表：

類型	說明
Duplicated Code （重複代碼）	如果你在一個以上的地點看到相同的程式結構，那麼可以肯定：設法將它們合而為一，程式會變得更好。
Long Method （過長函數）	“間接層”所能帶來的全部利益——解釋能力、共用能力、選擇能力，都是由小型函數支援的。 我們遵循這樣一條原則：每當感覺需要以注釋來說明點什麼的時候，我們就把需要說明的東西寫進一個獨立函數中，並以其用途（而非實現手法）命名。
Large Class （過大的類）	不要嘗試利用單個類去做太多事情。這也是物件導向“單一職責”原則。
Long Parameter List （過長參數列）	函數需要的東西多半可以在函數的宿主類中找到。物件導向程式中的函數，其參數列通常比在傳統程式中短得多。
Divergent Change （發散式變化）	如果某個類經常因為不同的原因在不同的方向上發生變化，Divergent Change就出現了。
Shotgun Surgery （霰彈式修改）	如果每遇到某種變化，你都必須在許多不同的類內做出許多小修改，你所面臨的壞味道就是Shotgun Surgery。
Feature Envy （依戀情結）	函數對某個類的興趣高過對自己所處類的興趣。這種孺慕之情最通常的焦點便是資料。 我們的原則是：判斷哪個類擁有最多被此函數使用的資料，然後就把這個函數和那些資料擺在一起。 最根本的原則是：將總是一起變化的東西放在一塊兒。努力保持變化只在一地發生。
Data Clumps （資料泥團）	一個好的評判辦法是：刪掉眾多資料中的一項。這麼做，其他資料有沒有因而失去意義？如果它們不再有意義，這就是個明確訊號：你應該為它們產生一個新對象。 所有的類將會組成一個小小的社會，每個類都會在其中發揮價值。
Primitive Obsession （基本類型偏執）	對象的一個極大的價值在於：它們模糊（甚至打破）了橫亙於基本資料和體積較大的類之間的界限。
Switch Statements （switch驚悚現身）	少用switch（或case）語句。物件導向中的多態概念可為此帶來優雅的解決辦法。
Parallel Inheritance Hierarchies （平行繼承體系）	每當你為某個類增加一個子類，必須也為另一個類相應增加一個子類。這時PIH就出現了。 消除這種重複性的一般策略是：讓一個繼承體系的執行個體引用另一個繼承體系的執行個體。
Lazy Class （冗贅類）	如果一個類的所得不值其身價，它就應該消失。
Speculative Generality （夸夸其談未來性）	如果函數或類的唯一使用者是測試案例，請把它們連同其測試案例一併刪掉。但如果它們的用途是協助測試案例檢測正當功能，當然必須刀下留人。
Temporary Field （令人迷惑的暫時欄位）	有時你會看到這樣的對象：其內某個執行個體變數僅為某種特定情況而設。這樣的代碼讓人不易理解，因為你通常認為對象在所有時候都需要它的所有變數。在變數未被使用的情況下猜測當初其設定目的，會讓你發瘋的。
Message Chains （過度耦合的訊息鏈）	如果你看到使用者向一個對象請求另一個對象，然後再向後者請求另一個對象，然後……，這就是訊息鏈。 通常更好的選擇是：先觀察訊息鏈最終得到的對象是用來幹什麼的。
Middle Man （中間人）	對象的基本特徵之一就是封裝——對外部世界隱藏其內部細節。封裝往往伴隨委託。但是不要過度運用委託。
Inappropriate Intimacy （狎昵關係）	有時候你會看到兩個類過於親密，花費太多時間去探究彼此的private成分。類之間過分狎昵的關係必須拆散。 繼承往往造成過度親密。如果你覺得該讓這個孩子獨自生活了，請讓他離開繼承體系。
Alternative Classes with Different Interfaces （異曲同工的類）	兩個函數做同一件事，卻有著不同的簽名，勢必只能保留一個。
Incomplete Library Class （不完美的類庫）	庫類構築者沒有未蔔Crowdsourced Security Testing的能力，我們不能因此責怪他們。麻煩的是我們不可能修改其中的類使它完成我們希望完成的工作，要想其它辦法解決問題。
Data Class （純稚的資料類）	Data Class就像小孩子，作為一個起點很好，但若要讓它們像成熟的對象那樣參與整個系統的工作，它們就必須承擔一定責任。
Refused Bequest （被拒絕的遺贈）	如果子類複用了超類的行為（實現），卻又不願意支援超類的介面，Refused Bequest的壞味道就會變得濃烈。拒絕繼承超類的實現，這一點我們不介意。但是如果拒絕繼承超類的介面，我們不以為然。
Comments （過多的注釋）	注釋是好的編程習慣，但是利用注釋掩蓋糟糕的代碼就不對了。