[[354911]]

shenfq  本文轉載自微信公眾號「愛笑的架構師」，作者雷架。轉載本文請聯(lián)系愛笑的架構師公眾號。   

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

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

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

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

壞味道：Long Method(過長函數(shù))

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

為什么過長函數(shù)是一種壞味道?

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

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

那么如何解決過長函數(shù)問題呢?

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

比如我們在寫 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()); 

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

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

壞味道：Large Class(過大的類)

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

知識小百科

設計模式的六大原則有：

Single Responsibility Principle：單一職責原則

Open Closed Principle：開閉原則

Liskov Substitution Principle：里氏替換原則

Law of Demeter：迪米特法則

Interface Segregation Principle：接口隔離原則

Dependence Inversion Principle：依賴倒置原則

六個原則的首字母聯(lián)合起來就是 SOLID，兩個 L 當成一個。

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

一般一個類同時滿足以下3個條件就是上帝類：

(1)CPFD (Capsules Providing Foreign Data) 從多個不相關類(模塊)中引用數(shù)據(jù)。

(2)WOC (Weighted Operation Count) 類的所有函數(shù)的圈復雜度之和超過65。

(3)TCC (Tight Capsule Cohesion) TCC < 1/3 類需要具有低內聚的特性(類中直接相關的方法與全部方法之比小于1/3)，也就是較少的private方法。

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

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

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

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

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

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

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

壞味道：Duplicated Code(重復代碼)

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

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

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

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

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

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

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

class A { 
    public void method1() { 
        logic1 
        logic2 
        logic3 
    } 
    public void method2() { 
        logic1 
        logic2 
        logic4 
    } 
} 

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

class A { 
    public void method1() { 
        baseMethod(); 
        logic3 
    } 
    public void method2() { 
        baseMethod(); 
        logic4 
    } 
    public void baseMethod() { 
        logic1 
        logic2 
    } 
} 

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

class A extend Base { 
    public void method1() { 
        logic1 
        logic2 
        logic3 
    } 
} 

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

class B extend Base { 
    public void method2() { 
        logic1 
        logic2 
        logic3 
    } 
} 

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

重構后：

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

場景3：兩個毫無相關的類出現(xiàn)重復代碼

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

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

壞味道：Long Parameter List(過長參數(shù)列)

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

為什么過長參數(shù)列是一種壞味道?

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

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

如何解決過長參數(shù)列這種壞味道?

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

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

特別需要提醒的是有些情況下長參數(shù)也是合理的，因為使用參數(shù)可以避免某些依賴關系的產(chǎn)生。在編碼實踐中我們可以通過觀察長參數(shù)的方法，如果這個方法經(jīng)常變動那你就要考慮重構這個方法了?；驹瓌t：事不過三，過三重構。

壞味道：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 (搬移函數(shù))和 Move Field (搬移字段)把所有需要修改的代碼放進同1個類，如果暫時沒有合適的類，就創(chuàng)建一個。

壞味道：Speculative Generality(夸夸其談未來性)

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

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

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

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

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

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

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

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

當需要為未來而寫的代碼時，可以干這些：

(1)刪除那些覺的未來有用的參數(shù)、代碼、方法調用。

(2)修正方法名，使方法名揭示當下業(yè)務場景的意圖，避免抽象的技術描述詞。

如果代碼的改動確實是未來必然會發(fā)現(xiàn)的，那么還是建議保留?？淇淦湔勎磥硇愿嗍侵搁_發(fā)人員無依據(jù)臆測未來，導致代碼模塊被過度設計。

壞味道：Comments(過多的注釋)

在 《Clean Code》 中列舉了一些常見注釋壞味道：

• 喃喃自語
• 多余的注釋
• 誤導性注釋
• 循規(guī)方注釋
• 日志式注釋
• 廢話注釋
• 用注釋來解釋變量意思
• 用來標記位置的注釋
• 類的歸屬的注釋
• 注釋掉的代碼

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

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

在開發(fā)實踐中經(jīng)常有同學修改了代碼但是注釋沒有同步修改，代碼的實現(xiàn)已經(jīng)與注釋內容不一致，容易產(chǎn)生誤導。

如何解決過多的注釋這種壞味道呢?

(1)如果代碼塊不再使用請直接刪除不要使用注釋。

(2)方法、變量的命名盡量見名知意，避免用注釋再解釋一遍。

(3)如果較短的注釋不能覆蓋方法的含義，可能是這個方法職責不單一，可以考慮重構這個方法。

總結：

文章列舉了幾種比較常見的代碼壞味道，希望大家在工作編碼中多多練習，爭取人人都能寫出好代碼，讓天下沒有難讀的代碼。