代碼的壞味道

壞味道意指代碼中出現的可以被改進的地方。當你嗅到壞味道的時候，也就意味著重構的時機到了。

重構就是對軟體內部結構的一種調整，目的是在不改變軟體可觀察行為的前提下，提高其可理解性，降低其修改成本。

以下是《重構》中列出的“壞味道“。

1. 重覆代碼

　　重覆是代碼腐朽之源。重覆意味著當發生變化時，總是有很多的地方需要修改，也就是說需要對很多不同的地方負責。即使有著高級工具的輔助，對於跨函數、跨類之間的大量重覆的同步修改都不會是一件輕而易舉，並且能保證不會犯錯的事情。

　　每一處重覆都意味著維護時的一份責任。消除重覆就可以最大化的減少職責，也降低出錯的可能性。

　　拋開出錯的可能性不談，重覆一般意味著業務邏輯的抽象還不夠合理。

2. 過長函數

　　沒有什麼是增加一層“間接層”不能解決的。如果有，那就增加兩層。

　　程式越長越難以理解。這可能與每個人大腦的結構有一定的關係，可能有些人的大腦的“棧”比較深，適應那些長函數。但對於大部分程式員、大部分人而言，太長的函數會導致“棧溢出”。

　　將一個長函數拆分成多個小的函數，無疑會增加更多的函數間調用。在直覺上，這樣需要增加額外的開銷。但是，現代OO語言幾乎已經完全免除了進程內的函數調用的開銷。

3. 過大的類

　　過大的類的一個標識就是，類中出現大量的實例變數。

　　不是從一個類的代碼行數來判斷是否類過大。而是需要從的職責來判斷，如果它擁有不同的職責，那麼就需要將不同的職責拆分到不同的類中。

　　單一職責原則。

4. 過長的參數列表

　　過長的參數列表會導致難以理解，太多參數會造成前後不一致、不易使用。

　　傳遞太多的參數數據，會帶來另外一個問題：很難記住參數的順序。也就是說，不容易記住每一個參數位置傳入的值分別是什麼意思。如果傳入的是一個對象，則可以通過對象的實例變數來取值。屏蔽了參數順序間的問題。

　　但，有時候如果不希望造成“被調用對象”與“較大對象”間的某種依賴關係，這時將數據從對象中拆解出來單獨作為參數也是合理的。

5. 發散式變化

　　一個類受多種變化的影響。

　　針對某一外界變化的所有修改，都只應該發生在單一類中，而這個新類內的所有內容都應該反應此變化。

　　應該找出某特定原因而造成的所有變化，然後將它們提煉到一個類中。

6. 霰彈式修改

　　一種變化引發多個類相應的修改。

　　也就是，邏輯概念上相近的代碼被分散四處。這樣導致很難尋找，也會很容易忘記某個修改。

　　應該把所有需要修改的代碼放進同一個類中。

7. 依戀情結

　　函數對某個類的興趣高過對自己所處類的興趣。這裡所謂的興趣就是指，對那個類的函數、數據的調用。

　　一個函數會用到幾個類的功能，將它置於何處的原則：判斷哪個類擁有最多被此函數使用的數據，然後就將這個函數將那些數據擺在一起。

8. 數據泥團

　　總是捆綁出現在一起的數據應該擁有屬於它們自己的對象。

9. 基本類型偏執

　　不要執著於使用基本數據類型。

10. switch 語句

　　減少使用 switch 語句。從本質上說，它意味著重覆。

　　可以考慮使用多態來替換它。但是對於在單一函數中出現的使用多態，有點小題大做。

11. 平行繼承體系

　　當為某個類增加一個子類，必須也為另一個類相應的增加一個子類，便是出現了這個問題。

　　消除的策略是：讓一個繼承體系的實例引用另一個繼承體系的實例。

12. 冗餘類

　　對於無用的類，應該消除。這裡的“無用”可能是因為重構使得它原有的工作被別的類瓜分了。

13. 誇誇其談未來性

　　不要為了出於應對變化的目的，來將一個類打造的“過於”靈活。

　　變化是程式員最大的敵人。問題不在於“變化會出現”，而在於“難以預料變化出現的方式”。“變化”的粉墨登場總是會讓我們措手不及。

　　提前就想要做好應對變化的準備，大部分時候都是挖了一條“馬奇諾防線”。投入巨大，收效甚微。

　　我們需要讓代碼具有靈活性，但是過於的靈活帶來的問題就是代碼複雜度的增加。

14. 令人迷惑的暫時欄位

　　對象在所有的時候被認為需要它的所有變數。對於那些僅為某種特殊情況而設置的實例變數，會使得代碼難以理解。

15. 過度耦合的消息鏈

　　消息鏈就是“開火車”，一長串的“.”會讓你lost。

　　“不要與陌生人講話。”

16. 中間人

　　“中間人”就是把別人對它的調用“委托”給其他的對象。

17. 狎昵關係

　　對於過分親密的類，需要移動它們的函數和實例變數來幫它們劃清界限。

　　繼承往往會造成過度親密，因為子類對超類的瞭解總是超過後者的主觀願望。

18. 異曲同工的類

　　兩個函數做同一件事，卻有不同的簽名，需要根據它們的用途重新命名。

19. 不完美的庫類

　　復用別人的庫時，可能庫不夠好，而往往我們不可能修改其中的類使其完成我們希望的工作。

20. 純粹的數據類

　　它們就是數據容器。不明白為什麼這會被認為是一種“壞味道”。我們經常用到的"bean"。

21. 被拒絕的遺贈

　　子類應該繼承超類的函數和數據。但如果不想要繼承所有的數據呢？該怎麼拒絕這樣的“傳承”。

22. 過多的註釋

　　如果需要添加註釋來解釋函數，或許意味著需要拆分出一些小的函數，或給函數重命名。

　　代碼的壞味道有如廚房的油污，開始時不會覺得有多大的影響，但時間長了就會累積成“噁心”又難以“清除”的污漬。我們需要保持每天的清掃，而不是定期的“大掃除”。上面的“味道”就是一點一點的“油星”濺在“廚房”里，看到它們就順手擦掉吧！