異味代碼到底有多糟糕？ —— 衡量代碼異味的影響
用科學實驗來衡量哪些代碼異味最難維護。
如何處理有異味的代碼？
前輩曾經教導我們，作為開發人員，我們最主要的職責就是不要寫爛代碼。除非你是單兵作戰并且只是寫幾行很快就會棄用的 Perl 腳本而已，否則最重要的一點，就是你寫的代碼必須易于閱讀和理解。在軟件產品的整個生命周期中，可維護的代碼通常會免除你和你的同事們呆坐在電腦前痛苦絕 望的很多時間。
然而，導致代碼可讀性差的原因卻不總是那么清晰，這就是為什么像代碼編寫標準、準則、代碼模式和編程語言箴言之類的東西存在的原因之一。一條眾 所周知的準則是 Martin Fowler【1】寫的《重構》這本書，書里描述了一系列的代碼異味以及去掉這些異味的重構策略。盡管擁有這個無可估價的資源，我們依然面臨挑戰——除了 要學習很多重構策略，還需要決定哪些的優先級比較高。顯然，它們不可能同樣重要！我們如何得知現在做的代碼重構工作會有長期正面效益呢？
問題在于 Martin Fowler 的重構書沒有提及哪些代碼異味是關鍵的，哪些不是。Fowler 他自己也提到，沒有哪個標準或指標能夠比得上人的直覺。我們作為開發人員來說只能依靠直覺和經驗去決定是否需要重構。這可能是一場噩夢。面對一個有數千個 代碼異味的系統，你要從何處入手？除此之外，任何對代碼的改動都可能帶來意向不到的副作用。就算有高質量的自動化測試，修改代碼常常蘊含高風險而且代價昂 貴。如果知道哪些代碼異味是最具破壞性，先把它們處理掉就好了。另外，我們希望向管理層展示，我們并不是浪費時間在為了寫漂亮代碼而寫漂亮代碼上，而是我 們當前的努力能夠在未來為項目帶來長期效益。
【補充】：在軟件開發領域，代碼中的任何可能導致深層次問題的癥狀都可以叫做代碼異味。
通常，在對代碼做簡短的反饋迭代時，代碼異味會暴露出一些深層次的問題，這里的反饋迭代，是指以一種小范圍的、可控的方式重構代碼。基于這些暴露的問題，人們會進一步的檢查設計和代碼中是否還存在別的代碼異味，然后再做進一步的重構。從負責重構的開發者的角度來看，代碼異味可以啟發何時重構，如何重構。因此，可以說代碼異味推動著重構的進行。（摘自維基百科）
收集關于代碼異味的事實
2009 年，挪威 Simula 研究所需要把一個內部系統改造成一個新的內容管理系統。這個項目被外包給 6 個 Java 開發人員。這個項目被認為是深入研究代碼異味對可維護性造成影響的機會。
在這個項目持續的三個月中，他們使用了一些工具來衡量代碼異味，每天跟那些開發人員面談，并且每個開發人員的 Eclipse IDE 上都安裝了一個日志記錄工具。這個日志記錄工具不但記錄修改每個文件花了多長時間，而且記錄了花在搜索，瀏覽以及翻閱代碼所花費的時間。 在這個項目過程中，他們使用一個問題追蹤工具登記下那些開發人員所面臨的問題，然后反向追蹤到那些引起問題的源代碼文件。除此之外，所有的開發人員都要接 受面談。這個過程中收集到的數據遠遠多于常規的僅僅分析代碼倉庫的方法。以下是所得到的觀察結果：
觀察結果1：萬能類其實很糟糕！
來源：https://simula.no/publications/Simula.simula.1460
“人人都知道”萬能類是不好的，可是到底不好到什么程度？如下圖所示：
Y 軸代表在項目維護期間花費在閱讀修改一個文件上的時間；X軸代表文件的大小。
請注意，閱讀和修改最大的文件（1844 行代碼）要花的時間是大部分文件（少于 600 行代碼）的 10 倍以上。這個文件就是一個萬能類。另外請注意，20000 秒差不多是 5 個小時的工作（對于一個文件來說太長了！）。我們還可以看到編輯另一個大文件（大約 1400 行代碼）沒有花掉很多時間。這個大文件包含了很多的訪問器和修改器，沒有包含任何邏輯（相對于全能類）。這解釋了為什么開發人員沒有在上面花太多時間。包 含復雜邏輯的大文件（即全能類）會顯著影響可維護性。
建議：你應該把包含復雜邏輯的大文件分割成小文件。一個推薦的閾值是將文件大小保持在 1000 行代碼內。
觀察結果2： 數據團塊沒有你想得那么糟糕……
來源：https://simula.no/publications/Simula.simula.1456
“數據團塊（Data Clump）”是指一些語義上沒有相關性的方法和變量集合。一般情況下，包含數據團塊的文件包含了不同類型的變量，后面跟著一系列的訪問器和修改器。比 如，下圖中 Person 這個類包含了不直接跟一個人相關的信息，因此可以被分割成兩個類。Simula 的研究人員創建了一個統計模型來解釋代碼異味的出現是否增加了開發人員在維護過程中遭遇問題的可能性（他們會記錄維護過程中面臨的所有問題以及那些引起問 題的文件）。他們發現，事實上那些包含數據團塊的文件引起維護問題的可能性更低！
建議：不要去管那些數據團塊，除非它們包含了其他代碼異味。
觀察結果3： 堅持接口分離原則
Robert C. Martin（Bob 大叔）介紹了接口分離原則（ISP）作為 SOLID 原則【2】的一部分。
接口分離原則指出，任何軟件庫的調用者都不應該被強迫依賴于它沒有調用的方法。接口分離原則把非常龐大的接口分割成更小更加明確的接口，從而使得調用者只需要知道他們所關心的方法。
軟件工程的研究者們【3】提出了如何使用代碼量化標準去鑒別一些代碼異味。有些商業工具實現了這些量化標準，但是你也可以提出自己的探測策略并 且在工具中實現它們，比如 Java 中的 SonarQube 或者 .Net 中的 NDepend。下圖展示了 Simula 使用的探測策略，這個策略是基于研究員 Radu Marinescu【4】的工作提出的。
這個類的類“接口寬度”（即公開的方法和屬性個數）為 10，類的“調用者”數目為8，“平均接口用度”（即調用者所使用的方法或屬性個數除以調用者數目）為 0.375。根據這個探測策略，這個類可能違反了接口分離原則.
關于數據團塊的分析同樣涵蓋了違反接口分離原則的文件，結果發現當一個文件違反了接口分離原則時，它存在問題的概率的概率會增加。
如下圖所示，違反接口分離原則的文件比沒有違反該原則的文件出問題的概率要高（大約 30%），這也印證了上述觀點。
建議：分割那些過于寬泛，用途繁多的接口可以減少維護時出現問題的風險。
觀察結果4：代碼異味往往成群結隊出現
來源：https://simula.no/publications/Simula.simula.1508
在同一個實驗中，某些代碼異味表現出在同一個文件中一起出現的趨勢。如下圖所示，識別出來的代碼異味往往出現在同一個文件里。“異味囤積者”本 質上就是那些想要囤積所有系統功能的文件。“混亂因素”是那些在文件中引起困惑的代碼異味。另外兩組，“寬泛接口”和“數據容器”的含義則是不言自明的。
建議：如果你在一個文件中發現了某個類型的代碼異味，你大概想要檢查它是否包含其他的“異味小伙伴”。同個文件中的代碼異味組合會增加風險，減少可維護性！
長文略讀
就像 Fowler 所說，我們要追隨自己的直覺，經驗和判斷來決定哪些需要重構，但是下列根據科學研究得出的準則可以幫助你來區分優先級：
- 1. 分割那些包含過多邏輯的大文件（多于 1000 行代碼）
- 2. 關鍵不在于重構數據團塊
- 3. 把那些寬泛而用途繁多的接口按照用途來分割成不同接口
- 4. 包含某些代碼異味的文件往往同時會有更多的“不受歡迎的小伙伴”，注意識別它們！ </ul>
- 重復代碼: 相同或者相似的代碼存在于一個以上的地方。
- 長方法: 一個非常長的方法、函數或者過程。
- 巨類: 一個非常龐大的類。
- 太多的參數: 函數或者過程的冗長的參數列表使得代碼可讀性和質量非常差。
- 特性依戀: 一個類過度的使用另一個類的方法。
- 親密關系: 一個類依賴另一個類的實現細節。
- 拒絕繼承: 子類以一種‘拒絕’的態度，覆蓋基類中的方法，換句話說，子類不想繼承父類中的方法，參考 Liskov substitution principle。
- 冗余類 / 寄生蟲: 一個功能太少的類。
- 人為的復雜: 在簡單設計已經滿足需求的時候，強迫使用極度復雜的設計模式。
- 超長標識符: 尤其，在軟件工程中，應該毫無保留的使用命名規則來消除歧義。
- 超短標識符: 除非很明顯，一個變量名應該反映它的功用。
- 過度使用字面值: 為提高可讀性和避免編碼錯誤，應該使用命名常量。此外，字面值可以且應該在可能的情況下，獨立存放于資源文件或者腳本中，在軟件部署到不同區域時，可以很方便的本地化。（摘自維基百科） </ul> 來自: blog.jobbole.com
快樂地重構吧！
引用：
【1】《重構:改善既有代碼的設計》
【2】《敏捷軟件開發(原則模式與實踐) 》
【3】http://sewiki.iai.uni-bonn.de/research/cultivate/tutorial_exploring_smells_and_metrics
【4】http://loose.upt.ro./download/thesis/thesis.zip
補充：常見的代碼異味