用實例告訴你如何重構帶有壞味道的代碼

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

重複代碼和重複邏輯

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

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

長方法和臃腫的類

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

相同或不同類中的重複方法

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

分散式變更（Divergent Change）

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

散彈式變更（Shotgun Surgery）

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

依戀情結（Feature Envy）

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

數據泥團（Data Clumps）

有時候，你會發現很多函數具有相同的參數列表，這樣會導致數泥團代碼壞味道。看看下面的例子，你會發現，幾乎所有類型的預訂都需要護照信息。

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

痴迷基本類型（Primitive Obsession）

當你在應用程式的所有地方都使用基本數據類型時，就會出現這種代碼壞味道。例如，使用整數表示電話號碼，使用字符串表示貨幣符號。如果你是這麼做的，那麼請先看一下下面這個類。

代碼中的地址被定義為數組，這樣會導致兩個問題，例如，每次我們需要使用地址時都要對其進行硬編碼。那麼，為什麼不創建一個 Address 類呢？

現在，每次我們需要添加或編輯地址時，只需要修改 Address 類。此外，如果我們需要添加一個新的「聯繫我們」方法，就增加一個新的 ContactUs 類。這樣，每個類都有自己的單一職責。

switch 語句

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

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

並行繼承

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

從上圖中可以看出，每當我們創建一個新的部門類時，我們還需要創建一個權限類，這將導致之前提到的散彈式變更代碼壞味道。

懶惰類

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

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

臨時欄位

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

那麼為什麼不將它們作為方法參數進行傳遞呢。

消息鏈

當一個類使用了另一個類，而那個類又使用了另外一個類，並以此類推，那麼就會出現消息鏈代碼壞味道。在下圖中，你可以看到 Employee->EmployeeConfig->Config。

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

不恰當的親密關係

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

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

中間人

有時候，你會發現一個類的很多方法什麼事都不做，只是將調用委託給另一個類。在這種情況下，這個類被認為是中間人，大多數時候可以避免使用它。

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

接口不同但目的相同的類

通常，因為團隊之間缺乏溝通，創建了兩個不同的類，但它們的作用卻是一樣的，這意味著出現了重複代碼。

不完整的庫

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

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

現在，你可以使用 DocumentsDecorator 類而不是 Documents 類。

注釋

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

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

誇誇其談未來性（Speculative Generality）

這個代碼壞味道與過早進行優化有關，很多開發人員都沒有注意到這一點。在規劃期間需要考慮的一些注意事項：

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

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

【責任編輯：龐桂玉 TEL：[phone]】

點讚 0