[[241428]]

如果出現(xiàn)了代碼壞味道，說明你的代碼寫得不夠好，需要重構(gòu)才能讓它們變成干凈的代碼。在這篇文章中，我將通過 GitHub 上的真實項目來解釋代碼壞味道，并向你展示如何重構(gòu)這些帶有壞味道的代碼。

重復(fù)代碼和重復(fù)邏輯

開發(fā)人員通常很懶惰，在某種程度上，這不算一件壞事。然而，因為懶惰而走上了復(fù)制黏貼代碼的不歸路那就不對了。這樣可能會導(dǎo)致最常見的代碼壞味道，即邏輯重復(fù)，如下所示。

為了擺脫這種代碼壞味道，我們需要將紅色部分提取到一個單獨的方法中，這樣就可以在其他地方重用它們。

長方法和臃腫的類

我們都會犯這樣的一個錯誤：在現(xiàn)有方法中添加 if() 或 for() 語句來驗證用戶輸入或檢查用戶是否已登錄。我們其實不應(yīng)該這樣做。如果一定要做這些驗證，應(yīng)該創(chuàng)建自己的方法。方法長度應(yīng)該在 4 到 20 行之間，如果超過 20 行，可以將其中的幾行提取到另一個方法中。同樣的規(guī)則也適用于類，根據(jù)單一責(zé)任原則，方法或類越小越好。

相同或不同類中的重復(fù)方法

另一個代碼壞味道是多個方法提供了相同的功能，如下圖所示。

分散式變更（Divergent Change）

如果你了解 SOLID 原則，特別是單一職責(zé)原則，那么你就應(yīng)該知道，修改一個類的理由應(yīng)該是單一的。也就是說，User 類不應(yīng)具有與產(chǎn)品或文件轉(zhuǎn)換相關(guān)的功能。你可以通過將不相關(guān)的方法提取到 Product 類或 FileSystem 類來清除這個代碼壞味道。

散彈式變更（Shotgun Surgery）

這與發(fā)散變更完全相反。這種代碼壞味道會讓你因為一個需求而去修改多個類。例如，你想要創(chuàng)建一個新的用戶規(guī)則（如“Supper-Admin”），然后你發(fā)現(xiàn)，為了增加這個規(guī)則還需要修改 Profile、Products 和 Employees 類中的某些方法。在這種情況下，可以考慮將這些方法放在一個單獨的類中。

依戀情結(jié)（Feature Envy）

有時候，你會在類中找到一個大量使用另一個類的方法。在這種情況下，你可以考慮將這個方法移動到它使用的那個類中。如下圖所示。將 getFullAddress() 從 User 類移動到 ContactInfo 類中豈不是更好？因為它調(diào)用了 ContactInfo 類的很多方法。

數(shù)據(jù)泥團(tuán)（Data Clumps）

有時候，你會發(fā)現(xiàn)很多函數(shù)具有相同的參數(shù)列表，這樣會導(dǎo)致數(shù)泥團(tuán)代碼壞味道?？纯聪旅娴睦?，你會發(fā)現(xiàn)，幾乎所有類型的預(yù)訂都需要護(hù)照信息。

在這種情況下，將護(hù)照信息移到 PassportInfo 類中，然后將 PassportInfo 對象傳給預(yù)訂方法，這樣會更好。這是一個很好的重用代碼的例子。請記住，參數(shù)列表太長可能更容易導(dǎo)致 bug 和代碼沖突，而且難以進(jìn)行單元測試。

癡迷基本類型（Primitive Obsession）

當(dāng)你在應(yīng)用程序的所有地方都使用基本數(shù)據(jù)類型時，就會出現(xiàn)這種代碼壞味道。例如，使用整數(shù)表示電話號碼，使用字符串表示貨幣符號。如果你是這么做的，那么請先看一下下面這個類。

代碼中的地址被定義為數(shù)組，這樣會導(dǎo)致兩個問題，例如，每次我們需要使用地址時都要對其進(jìn)行硬編碼。那么，為什么不創(chuàng)建一個 Address 類呢？

現(xiàn)在，每次我們需要添加或編輯地址時，只需要修改 Address 類。此外，如果我們需要添加一個新的“聯(lián)系我們”方法，就增加一個新的 ContactUs 類。這樣，每個類都有自己的單一職責(zé)。

switch 語句

或許你很想知道為什么使用 switch 語句其實是件很糟糕的事情。雖說使用 switch 語句并不一定總是不好的，但在下面的示例中，你可以看到，switch 語句的代碼塊不僅很大而且是不可提取的。當(dāng)代碼塊變得越來越大時，你將無法將其拆分成更小的方法。

如果你的 switch 語句代碼塊不是很大，那么你可以繼續(xù)使用它們。例如，工廠模式就使用了 switch 語句。

并行繼承

有時候我會想，并行繼承是不是一種不好的做法。先讓我們來解釋一下并行繼承的概念，然后再討論它是不是代碼壞味道。

從上圖中可以看出，每當(dāng)我們創(chuàng)建一個新的部門類時，我們還需要創(chuàng)建一個權(quán)限類，這將導(dǎo)致之前提到的散彈式變更代碼壞味道。

懶惰類

懶惰類是指只做很少事情的類。還記得這些下面這些代碼嗎？

我們將地址移到一個單獨的類中，但我們沒有對熱線也這么做，因為它可能只有 3 行代碼。所以，一旦你發(fā)現(xiàn)了這些懶惰類，應(yīng)該將它們移除。

臨時字段

當(dāng)一個類實例的某些變量只是偶爾用到，就出出現(xiàn)臨時字段代碼壞味道。請看下面的例子，你會注意到 $name 和 $contactDetails 只在 notify() 方法中用到。

那么為什么不將它們作為方法參數(shù)進(jìn)行傳遞呢。

消息鏈

當(dāng)一個類使用了另一個類，而那個類又使用了另外一個類，并以此類推，那么就會出現(xiàn)消息鏈代碼壞味道。在下圖中，你可以看到 Employee->EmployeeConfig->Config。

你可以通過縮短鏈（變成 Employee->Config）讓代碼變得更整潔。

不恰當(dāng)?shù)挠H密關(guān)系

有時候，一個類的某個方法需要過多地了解另一個類的內(nèi)部狀態(tài)或數(shù)據(jù)。正如你在下圖中所看到的，notify() 方法位于 User Class 中，但它卻使用了 UserContactDetails 類的很多內(nèi)部方法。

在這種情況下，***可以將這些邏輯從 User 類移動到 UserContactDetails 類中，并新增 getWelcomeMessage($userName) 方法。

中間人

有時候，你會發(fā)現(xiàn)一個類的很多方法什么事都不做，只是將調(diào)用委托給另一個類。在這種情況下，這個類被認(rèn)為是中間人，大多數(shù)時候可以避免使用它。

注意：在 Facade 設(shè)計模式中，中間人在某些情況下可能會有所幫助。

接口不同但目的相同的類

通常，因為團(tuán)隊之間缺乏溝通，創(chuàng)建了兩個不同的類，但它們的作用卻是一樣的，這意味著出現(xiàn)了重復(fù)代碼。

不完整的庫

第三方庫并不總能為你提供應(yīng)用程序中所需的所有功能。在下面的示例中，處理文檔的庫可以通過 ID 獲取一個文檔或一次獲取所有的文檔。

如果你需要獲取特定用戶的所有文檔該怎么辦？在這種情況下，你需要擴(kuò)展 Document 類的功能，而不直接修改原始類。這個時候可以使用裝飾模式，如下圖所示。

現(xiàn)在，你可以使用 DocumentsDecorator 類而不是 Documents 類。

注釋

你可能會感到驚訝，但錯誤地使用注釋也是一種代碼壞味道。下面是我的一些建議：

• 刪除不必要的注釋。
• 如果代碼很容易理解，請不要添加額外的注釋。
• 不要留下被注釋的舊代碼。
• 刪除用于調(diào)試的注釋，如 var_dump、echo 等。

夸夸其談未來性（Speculative Generality）

這個代碼壞味道與過早進(jìn)行優(yōu)化有關(guān)，很多開發(fā)人員都沒有注意到這一點。在規(guī)劃期間需要考慮的一些注意事項：

• 不要過度計劃你的代碼。
• 不要試圖涵蓋只有 1％可能性會在未來發(fā)生的情況。
• 為了讓算法更簡單，可以犧牲一些速度，特別是當(dāng)你不需要應(yīng)用程序立即給出結(jié)果的時候。
• 當(dāng)應(yīng)用程序速度很慢，即使只有 100 個用戶，也需要進(jìn)行優(yōu)化。

英文原文：https://codeburst.io/write-clean-code-and-get-rid-of-code-smells-aea271f30318 

【責(zé)任編輯：龐桂玉 TEL：（010）68476606】