Martin Fowler：任何一個傻瓜都能寫出計算機可以理解的代碼。唯有寫出人類容易理解的代碼，才是優秀的程序員。

大家閉著眼睛想一下什么是好代碼？也許你的腦海中漂浮著一堆詞：干凈、整潔、命名規范、注釋合理、高內聚低耦合……

人人都想寫好代碼，因為看好代碼就如同看一位五官端正的女子，心情愉悅、舒暢，而看糟糕的代碼就如同看見腐爛的食物，聞起來也有一股壞味道。

大多數人寫的代碼都不能稱之為好代碼，一方面由于自己技能限制，另一方面也可能根本就分不清好代碼和壞代碼，下面筆者結合日常編碼實踐與大家分享一下常見的代碼壞味道。

?壞味道：Long Method（過長函數）

過長函數簡而言之就是函數長度超標了，包括橫向和縱向。

為什么過長函數是一種壞味道？

橫向過長會導致無法一眼就能看出這行代碼的作用，需要用鼠標慢慢往后邊拖，相信用小屏幕的小伙伴經常會遇到這個問題，拖動的過程會嚴重影響讀代碼的效率。

縱向過長其實就是出現了大函數，一個函數的行太多，使得函數難以讀懂，代碼修改難度大。

那么如何解決過長函數問題呢？

關于橫向過長的問題，一般會在 IDE 中提前配置好最大寬度，比如80字符或者120字符（具體根據公司內部規范設置），然后格式化代碼即可解決。

比如我們在寫 Java8 stream 鏈式表達式的時候可以會很長：

List<String>?nodes?=?list.stream().filter().filter().map.filter().collect(Collectors.toList());?//?可能會非常長

其實我們可以在.之前換行，這樣看起來一目了然。

List<String>?nodes?=?list.stream().filter().filter().map.filter().collect(Collectors.toList());

關于縱向過長的問題其實就是這個方法或者函數職責不夠單一，一個函數中堆積太多功能。

重構的手段很簡單：Extract Method，積極抽取函數或方法，隱藏細節保持職責單一。

?

壞味道：Large Class（過大的類）

過大的類也常常被成為上帝類（God Class），上帝類一般是指維護了太多功能（違反單一職責原則），連上帝也看不懂你的代碼。

知識小百科
設計模式的六大原則有：
Single Responsibility Principle：單一職責原則
Open Closed Principle：開閉原則
Liskov Substitution Principle：里氏替換原則
Law of Demeter：迪米特法則
Interface Segregation Principle：接口隔離原則
Dependence Inversion Principle：依賴倒置原則
六個原則的首字母聯合起來就是 SOLID，兩個 L 當成一個。

那如何判斷一個類是不是上帝類呢？

一般一個類同時滿足以下3個條件就是上帝類：
（1）CPFD (Capsules Providing Foreign Data) 從多個不相關類（模塊）中引用數據。
（2）WOC (Weighted Operation Count) 類的所有函數的圈復雜度之和超過65。
（3）TCC (Tight Capsule Cohesion) TCC < 1/3 類需要具有低內聚的特性（類中直接相關的方法與全部方法之比小于1/3），也就是較少的private方法。

為什么過大的類是一種壞味道？

過大的類承擔了過多的職責，往往有很多重復代碼，并且這些重復代碼你還不容易發現，這基本就是壞味道的開始。

過大的類被子類繼承會導致其他壞味道，比如遺留的饋贈。

如何解決過大的類這種問題呢？

通過觀察這個過大類的屬性，看有沒有一些屬性有關聯，如果有可以使用 Extract Class 將這些關聯屬性抽象到一個新類中，并將與這些屬性相關的操作都 Move 到新的類中。

通過觀察這個過大類的方法，看有沒有一些函數或方法存在兄弟關聯，如果有可以使用 Extract Subclass（提煉子類）的手段將這些方法提煉到子類中，子類可以繼承父類。將相似的行為方法聚集在一個類中拆分到多個類中，可以進一步將發放調用解耦開。

以上方法循環往復，一個大類就可以拆分為多個小的且職責單一的類。

?

壞味道：Duplicated Code（重復代碼）

Robert C.Martin：重復可能是軟件中一切邪惡的根源。

重復代碼一般是由于復制粘貼造成的。需求迭代過程中為了不影響已有功能，通常是將之前的代碼copy一份改改，然后匆匆上線。

那為什么重復的代碼是一種壞味道呢？

最直接的弊端就是如果你想修改一段代碼邏輯，可能會遺漏，甚至需要多次修改才能確保全部修改完。

如何解決重復代碼的問題？

下面結合代碼實踐分幾個場景分別描述。

場景1：同一個類中兩個方法含有相同的表達式

class?A?{public?void?method1()?{logic1logic2logic3}public?void?method2()?{logic1logic2logic4} }

重構手段：將兩個方法共同的邏輯抽象出來。重構后：

class?A?{public?void?method1()?{baseMethod();logic3}public?void?method2()?{baseMethod();logic4}public?void?baseMethod()?{logic1logic2} }

場景2：兩個具有相同父類的子類內含有相同的表達式類 A 中有一個 method1，有三段邏輯。

class?A?extend?Base?{public?void?method1()?{logic1logic2logic3} }

類 B 中有一個 method2，也有三段邏輯。

class B extend Base {public void method2() {logic1logic2logic3} }

重構手段：將重復代碼抽象成一個方法放在父類中，差異部分由子類各自實現。

重構后：

class?Base?{public?void?baseMethod()?{logic1logic2} } class?A?extend?Base?{public?void?method1()?{baseMethod();logic3} } class?B?extend?Base?{public?void?method2()?{baseMethod();logic3} }

場景3：兩個毫無相關的類出現重復代碼

如果兩個沒有直接關聯的類出現重復代碼，可以考慮將重復的代碼抽象到一個獨立的普通類或者工具類中，適用方可以使用組合的方式調用。

代碼樣例這里不再贅述，與場景1和2大同小異，相信聰明的你一定能明白。

?

壞味道：Long Parameter List（過長參數列）

全局變量是個邪惡的東西，數據是共享的并且每個線程都可以修改，太多了容易導致程序不可控，所以大家喜歡將變量以行參的方式傳遞，久而久之參數列越來越長了。

為什么過長參數列是一種壞味道？

方法參數的數量太多會導致代碼可讀性非常差，如果有多個重載方法它們的方法參數都非常多，在寫代碼時很難判斷該調用哪一個。

當一個方法需要新增功能，每次都可能會新增一個方法參數，這樣導致調用方每次都要重新適配，小心被打哦，耗子尾汁。

如何解決過長參數列這種壞味道？

可以將多個參數封裝到一個 DTO 對象中，方法間的對象通過對象的傳輸而不是過長的參數。

數據傳輸對象（DTO)(Data Transfer Object)，是一種設計模式之間傳輸數據的軟件應用系統。

特別需要提醒的是有些情況下長參數也是合理的，因為使用參數可以避免某些依賴關系的產生。在編碼實踐中我們可以通過觀察長參數的方法，如果這個方法經常變動那你就要考慮重構這個方法了。基本原則：事不過三，過三重構。

?

壞味道：Shotgun Surgery（散彈式修改）

為什么散彈式修改是一種代碼壞味道？

如果需要修改某個小功能，你需要在眾多不同的類中做修改，首先很難找全，其次很可能會遺漏，這種問題一般稱之為散彈式修改。

public?class?A?{@Value("${db.mysql.url}")private?String?mysqlDbUrl; }public?class?B?{@Value("${db.mysql.url}")private?String?mysqlDbUrl; }

假如有多個類都使用了db.mysql.url這個變量，如果后面要將 mysql 切到 Oracle，那么可能會涉及到多處修改。如何解決散彈式修改這種代碼壞味道呢？

可以使用 Move Method （搬移函數）和 Move Field （搬移字段）把所有需要修改的代碼放進同1個類，如果暫時沒有合適的類，就創建一個。

?

壞味道：Speculative Generality（夸夸其談未來性）

在工作中經常會聽到有開發小伙伴說：昨天加班我將訂單模塊做了修改，未來可以……

聽到這里你可以會鼓掌：牛叉啊，提前對功能模板預留了擴展性。但是不要急于故障，你看技術總監的臉黑著呢，為什么呢？這位小伙伴的代碼可能是一種壞味道：夸夸其談未來性。

為什么夸夸其談未來性是一種代碼壞味道？

互聯網需求迭代更新速度快，”未來可以“意味著當下并不需要，有時候過度的抽象和預留擴展也會讓系統難以理解，并且可能提前背上包袱往前走。

代碼上總是談未來可能性，會讓團隊陷入泥沼。每次有業務變動，開發人員都會考慮各種未來可能性，預留足夠多的擴展接口，這無疑極大增加了代碼復雜度，讓一個可能快速上線的需求變得慢下來。

如何解決夸夸其談未來性這種代碼壞味道呢？

在代碼架構設計中有一個原則叫：Simple Design （簡單設計原則）。

當實現當下業務代碼時需要考慮四個原則：通過測試、揭示意圖、消除重復、最少元素。

當需要為未來而寫的代碼時，可以干這些：
（1）刪除那些覺的未來有用的參數、代碼、方法調用。
（2）修正方法名，使方法名揭示當下業務場景的意圖，避免抽象的技術描述詞。

如果代碼的改動確實是未來必然會發現的，那么還是建議保留。夸夸其談未來性更多是指開發人員無依據臆測未來，導致代碼模塊被過度設計。

?

壞味道：Comments（過多的注釋）

在 《Clean Code》 中列舉了一些常見注釋壞味道：
喃喃自語
多余的注釋
誤導性注釋
循規方注釋
日志式注釋
廢話注釋
用注釋來解釋變量意思
用來標記位置的注釋
類的歸屬的注釋
注釋掉的代碼

為什么過多的注釋是一種代碼壞味道呢？

好的注釋可以輔助開發人員快速閱讀理解代碼，過多的注釋或壞注釋可能會降低代碼的可讀性。

在開發實踐中經常有同學修改了代碼但是注釋沒有同步修改，代碼的實現已經與注釋內容不一致，容易產生誤導。

如何解決過多的注釋這種壞味道呢？
（1）如果代碼塊不再使用請直接刪除不要使用注釋。
（2）方法、變量的命名盡量見名知意，避免用注釋再解釋一遍。
（3）如果較短的注釋不能覆蓋方法的含義，可能是這個方法職責不單一，可以考慮重構這個方法。

?

總結：

文章列舉了幾種比較常見的代碼壞味道，希望大家在工作編碼中多多練習，爭取人人都能寫出好代碼，讓天下沒有難讀的代碼。如果需要深入學習代碼壞味道，推薦仔細研讀兩本書：《重構:改善既有代碼的設計》，《Clean Code》。

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的讲点码德！避免这些代码坏味道，努力做一名优秀的程序员的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。