關于重構，代碼的壞味道，應該重構的代碼

應該重構的代碼

1.重復的代碼：

重復代碼在同一個類中的不同方法中，則直接提煉為一個方法

如果重復代碼在兩個互為兄弟的子類中，則將重復的代碼提到父類中

如果代碼類似，則將相同部分構成單獨函數，或者用 Template Method 設計模式

重復代碼出現在不相干的類中，則將代碼提煉成函數或者放在獨立的類中 

2.過長的函數：

降低了可讀性，應該將獨立的功能提煉成新函數

3. 過大類

使得責任不清晰，容易造成重復代碼，混亂，應該將過大類的功能拆分成多個功能單一的小類

4.過長的參數列

過長的參數列難以理解，而且容易傳錯參數。應該將參數列表用參數對象替換

5.發散式變化：

一個類由于不同的原因而被修改。應該將類拆分成多個，每個類只因為一種變化而修改。

6.霰彈式修改：

 與發散式變化相反，遇到變化時需要修改許多不同的類。應該將類似的功能放到一個類中

7.依戀情結：

函數對某個類的興趣高過對自己所處的類，通常是為了取其他類中的數據。應該將函數部分功能移到它感興趣的類中

8.數據泥團：

在多個地方看到相同的數據項。例如：

      多個類中相同的變量，多個函數中相同的參數列表，并且這些數據總是一起出現。應該將這些數據項放到獨立的類中

9.基本類別偏執：

對象技術的新手通常不原因在小任務上運用小對象，比如結合數值和幣別的money class，等，應該Replace Data Value with Object。

10.分支語句：

大量的分支、條件語句導致過長的函數，并且可讀性差。應將它變成子類或者使用 State和 Strategy模式

11.平行繼承體系

是霰彈式修改的特殊情況。一般是當你為某個類增加了一個子類，必須也為另一個類相應的增加一個子類。如果你發現某個繼承體系的 class名稱前綴和另一個繼承體系的class名稱前綴完全相同。變素有問題了。 應該讓一個繼承體系的實體（instance）指涉（參考，引用，refer to）另一個繼承體系的實體。

12 冗贅類（lazy class）

幾乎沒有用的組建 應該進行inline class

13.夸夸其談未來性

現在用不到，覺得未來可以用到的代碼，要警惕。應該將用不上的代碼去掉

14.過度耦合的消息鏈

 一個對象請求另一個對象，后者又請求另外的對象，然后繼續。。。。，形成耦合的消息鏈。應該公布委托對象供調用

15 純粹的數據類

  將數據類中數據以Public方式公布，沒對數據訪問進行保護。應該 將數據封裝起來，提供Get/Set方法。

16 過多的注釋

 代碼有著長長的注釋，但注釋之所以多是因為代碼很糟糕。先重構代碼，再寫上必要的注釋

17 令人迷惑的暫時值域

如某個instance變量僅為某特定情況而設，在變量未被使用的情況下猜測當初設置目的非常困難。應該建立一個新的class，把所有和這個變量相關的代碼都放到里面。

來自：http://my.oschina.net/u/572987/blog/94140