[[354911]]

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

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

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

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

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

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

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

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

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

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

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

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

比如我們在寫 Java8 stream 鏈?zhǔn)奖磉_(dá)式的時(shí)候可以會很長：

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

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

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

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

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

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

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

知識小百科

設(shè)計(jì)模式的六大原則有：

Single Responsibility Principle：單一職責(zé)原則

Open Closed Principle：開閉原則

Liskov Substitution Principle：里氏替換原則

Law of Demeter：迪米特法則

Interface Segregation Principle：接口隔離原則

Dependence Inversion Principle：依賴倒置原則

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

那如何判斷一個(gè)類是不是上帝類呢?

一般一個(gè)類同時(shí)滿足以下3個(gè)條件就是上帝類：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如何解決重復(fù)代碼的問題?

下面結(jié)合代碼實(shí)踐分幾個(gè)場景分別描述。

場景1：同一個(gè)類中兩個(gè)方法含有相同的表達(dá)式

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

重構(gòu)手段：將兩個(gè)方法共同的邏輯抽象出來。重構(gòu)后：

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

場景2：兩個(gè)具有相同父類的子類內(nèi)含有相同的表達(dá)式類 A 中有一個(gè) method1，有三段邏輯。

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

類 B 中有一個(gè) method2，也有三段邏輯。

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

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

重構(gòu)后：

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：兩個(gè)毫無相關(guān)的類出現(xiàn)重復(fù)代碼

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

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

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

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

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

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

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

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

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

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

特別需要提醒的是有些情況下長參數(shù)也是合理的，因?yàn)槭褂脜?shù)可以避免某些依賴關(guān)系的產(chǎn)生。在編碼實(shí)踐中我們可以通過觀察長參數(shù)的方法，如果這個(gè)方法經(jīng)常變動(dòng)那你就要考慮重構(gòu)這個(gè)方法了。基本原則：事不過三，過三重構(gòu)。

壞味道：Shotgun Surgery(散彈式修改)

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

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

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

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

可以使用 Move Method (搬移函數(shù))和 Move Field (搬移字段)把所有需要修改的代碼放進(jìn)同1個(gè)類，如果暫時(shí)沒有合適的類，就創(chuàng)建一個(gè)。

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

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

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

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

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

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

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

在代碼架構(gòu)設(shè)計(jì)中有一個(gè)原則叫：Simple Design (簡單設(shè)計(jì)原則)。

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

當(dāng)需要為未來而寫的代碼時(shí)，可以干這些：

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

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

如果代碼的改動(dòng)確實(shí)是未來必然會發(fā)現(xiàn)的，那么還是建議保留。夸夸其談未來性更多是指開發(fā)人員無依據(jù)臆測未來，導(dǎo)致代碼模塊被過度設(shè)計(jì)。

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

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

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

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

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

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

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

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

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

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

總結(jié)：

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