一、代碼竟會有“氣味”

食物在腐爛之際，會散發(fā)出異味，提醒人食物已經(jīng)壞掉了，需要處理。同樣，如果代碼中某處出現(xiàn)了問題，也會有一些癥狀。這些癥狀，被稱之為“代碼異味”（Code smell，也譯作“代碼味道”）。與食物腐敗發(fā)出的味道不同的是，代碼異味并非真正的氣味，而是一種“暗示”，暗示我們代碼可能有問題，提示程序員需要對項目設(shè)計進行更進一步的查看。

代碼異味一詞最初是由Kent Beck在幫助Martin Fowler在編寫《重構(gòu)：改善既有代碼的設(shè)計》一書時創(chuàng)造的。Martin Fowler對代碼異味的定義是：代碼異味是一種表象，它通常對應(yīng)于系統(tǒng)中更深層次的問題。

代碼異味的產(chǎn)生原因跟廚師的“清洗過程中故意保留”不一樣，它更多地并非刻意為之，創(chuàng)造者也未必“品嘗”過自己所寫的代碼，它更多地是由于設(shè)計缺陷或不良編碼習(xí)慣而導(dǎo)致的不良代碼癥狀。

這種異味也并非來自一種有據(jù)可查的標(biāo)準(zhǔn)，更多的是來自程序員的直覺。尤其是經(jīng)驗豐富和知識淵博的程序員，他們無需思考，只要通過查看代碼或一段設(shè)計就可以立馬對這個代碼質(zhì)量產(chǎn)生這種“感覺”，能對代碼設(shè)計的優(yōu)劣有一個大致的判斷。這有點類似我們英語學(xué)到一定程度后，即便不能完全看懂文章，但憑借語感也能選出正確答案。

二、 代碼異味的影響

對于代碼異味的出現(xiàn)我們其實無需過度緊張，因為在整個程序中代碼異味是無處不在的。

一般情況下，有“異味”的代碼也依舊能運行得很好。只是倘若重視不夠，沒有適當(dāng)?shù)鼐S護或改進代碼，代碼質(zhì)量就會下降，系統(tǒng)也會開始變得難以維護和擴展，同時也會增加技術(shù)債務(wù)。這就像做出有異味的九轉(zhuǎn)大腸的的小胖廚師，在前期準(zhǔn)備中對評委的建議置若罔聞，一意孤行，做出來的菜連自己都難以下咽。

所以團隊?wèi)?yīng)盡可能地做有質(zhì)量的代碼，減少甚至避免這些問題，產(chǎn)生高效益的成果。

三、 如何辨別代碼異味

代碼是否存在代碼異味，通常是靠程序員的主觀判斷，但由于語言、開發(fā)者、開發(fā)理論的不同，對代碼異味的判斷也會存在差異。

所以要想更精準(zhǔn)地識別代碼異味，獲得更高的代碼質(zhì)量，程序員需要大量的實踐和經(jīng)驗。不過，前輩們總結(jié)的經(jīng)驗也可以讓我們少走一些彎路。Martin Fowler在《重構(gòu)：改善既有代碼的設(shè)計》一書中，列舉了最常見的24種代碼異味，可以幫助我們輕松識別，便于處理和改善它們：

一個類包含許多字段、方法或者代碼行，并逐漸變得臃腫。

2) 數(shù)據(jù)泥團（Data Clumps）

代碼的不同部分包含了相同的變量組，且這些數(shù)據(jù)總是綁在一起出現(xiàn)。

3) 過長參數(shù)列表（Long Parameter List）

指一個方法的參數(shù)超過了三個或四個。出現(xiàn)這種情況一般是將幾種類型的算法合并到一個方法之后。

4) 基本類型偏執(zhí)（Primitive Obsession）
創(chuàng)建一個原始字段比創(chuàng)建一個全新的類要容易得多，所以對于具有意義的業(yè)務(wù)概念如錢、坐標(biāo)、范圍等，很多程序員不愿意進行建模，而是使用基本數(shù)據(jù)類型進行表示，進而導(dǎo)致代碼內(nèi)聚性差、可讀性差。

5) 神秘命名（Mysterious Name）
在編程中，命名是一件非常惱人的事情。一些可能只有自己看懂的命名，無疑加大了代碼可讀性的難度，有時甚至自己也會忘記這些命名的含義。

6) 重復(fù)代碼（Duplicated Code）
這幾乎是最常見的異味。當(dāng)多個程序員同時處理同一程序的不同部分時，通常會發(fā)生這種情況。

7) 過長的函數(shù)（Long Function）
根據(jù)Martin Fowler的經(jīng)驗，通?；畹米铋L、最好的程序，其中的函數(shù)都比較短。函數(shù)越長，就越難理解。

8) 全局數(shù)據(jù)（Global Data）
這是一個非?？膳虑掖瘫堑漠愇洞a。因為從代碼庫的任何一個角落都可以修改它，而且沒有任何機制可以探測出到底是哪段代碼做出了修改。全局數(shù)據(jù)造成一次又一次的詭異Bug，讓我們很難找出出錯的代碼。

9) 可變數(shù)據(jù)（Mutable Data）
如果可變數(shù)據(jù)的變量的作用域越大, 越容易出現(xiàn)問題。變量是可以更改的，但我們可能不知道是哪里改變了它。

10) 發(fā)散式變化（Divergent Change）
是指一個類受到多種變化的影響。

11) 霰彈式修改（Shotgun Surgery）
是指一種變化引發(fā)多個類相應(yīng)修改。

12) 依戀情結(jié)（Feature Envy）
一個類使用另一個類的內(nèi)部字段和方法的數(shù)據(jù)多于它自己的數(shù)據(jù)。

13) 重復(fù)的switch（Repeated Switch）
在不同的地方反復(fù)使用switch邏輯。這帶來的問題就是當(dāng)我們想要增加一個選擇分支時，就必須找到所有的switch，并逐一更新。

14) 循環(huán)語句（Loops）
在編程語言中，循環(huán)一直是程序設(shè)計的核心要素。在《重構(gòu)》中，Martin Fowler認為它是一種代碼異味，因為他們覺得如今的循環(huán)已經(jīng)有點過時了。他們提出“以管道取代循環(huán)”，這樣可以幫助我們更快看清被處理的元素以及處理它們的動作。

15) 冗贅的元素（Lazy Element）
這是幾乎無用的組件。我們在設(shè)計代碼時有時為了未來的功能設(shè)計出“預(yù)備”代碼，但實際上從未實現(xiàn)；又或者這個類本來有用但隨著重構(gòu)，越來越小，最后只剩下一個函數(shù)。無論哪種，它們都是冗贅無用的。

16) 推測的通用性（Speculative Generality）
是指為了“以防萬一”，支持預(yù)期的未來功能，但這些功能并未被實現(xiàn)，這些類、方法、字段或參數(shù)也從未被使用，結(jié)果導(dǎo)致代碼變得難以理解和支持。

17) 臨時字段（Temporary Field）
創(chuàng)建臨時字段以用于需要大量輸入的算法。但這些字段僅在算法中使用，其余時間不使用。

18) 過長的消息鏈（Message Chains）
當(dāng)客戶端請求另一個對象，該對象又請求另一個對象，依此類推時，就會出現(xiàn)過長的消息鏈。這些鏈意味著客戶端依賴于類結(jié)構(gòu)的導(dǎo)航。一旦發(fā)生更改，客戶端也要跟著修改。

19) 中間人（Middle Man）
指一個類只執(zhí)行一個動作，但將工作委托給另一個類，這種委托屬于過度委托。該類也可能只是一個空殼，只負責(zé)委托且只有一件事。

20) 內(nèi)幕交易（Insider Trading）
指模塊之間大量地交換數(shù)據(jù)，增加模塊之間的耦合。

21) 異曲同工的類（Alternative Classes with Different Interface）
是指兩個類執(zhí)行了相同的功能但具有不同的方法名稱。

22) 純數(shù)據(jù)類（Data Class）
指包含字段和訪問它們的粗略方法（getter 和 setter）的類。這些只是其他類使用的數(shù)據(jù)容器。這些類不包含任何附加功能，并且不能獨立操作它們擁有的數(shù)據(jù)。

23) 被拒絕的遺贈（Refused Bequest）
指如果子類復(fù)用了超類的行為，但又不愿意支持超類的接口的情況。

24) 注釋（Comments）
程序員將其作為一種“除臭劑”使用情況下的行為。比如：一段代碼有著長長的注釋，但這段長注釋的存在是因為代碼很糟糕。
?

四、 如何對代碼“除臭”

1）重構(gòu)
上述代碼異味沒有優(yōu)先級一說，所以對于程序員而言，只能依靠直覺和經(jīng)驗去決定是否需要重構(gòu)。

重構(gòu)，一言以蔽之，就是在不改變外部行為的前提下，有條不紊地改善代碼。是實現(xiàn)敏捷性的最重要的技術(shù)因素之一。是程序員根據(jù)已識別出的氣味然后將代碼分成更小的部分的過程，再決定要么刪除它們，要么用更好的代碼替換它們，如此循環(huán)重復(fù)這個過程，直到異味消失，這樣可能會提高代碼質(zhì)量并讓代碼變得更具簡單性、靈活性和可理解性。

2）使用代碼檢測工具

識別和消除代碼異味是一個令人厭煩且不確定的過程，而且也不可能手動查找到和刪除掉所有異味，尤其是面對一個有著上千行異味的代碼的時候。所以使用一些代碼檢測工具可以輔助我們進行快速大量地審查，幫助我們節(jié)約時間來做更為重要的工作，比如能專注于代碼高層面的設(shè)計原則問題。

好了，關(guān)于代碼異味的知識，算是講了個清楚，那么讓我們相約下一次代碼評審吧！