shenfq 本文轉載自微信公眾號「愛笑的架構師」，作者雷架。轉載本文請聯繫愛笑的架構師公眾號。
Martin Fowler：任何一個傻瓜都能寫出計算機可以理解的代碼。唯有寫出人類容易理解的代碼，才是優秀的程式設計師。
大家閉著眼睛想一下什麼是好代碼?也許你的腦海中漂浮著一堆詞：乾淨、整潔、命名規範、注釋合理、高內聚低耦合……
人人都想寫好代碼，因為看好代碼就如同看一位五官端正的女子，心情愉悅、舒暢，而看糟糕的代碼就如同看見腐爛的食物，聞起來也有一股壞味道。
大多數人寫的代碼都不能稱之為好代碼，一方面由於自己技能限制，另一方面也可能根本就分不清好代碼和壞代碼，下面筆者結合日常編碼實踐與大家分享一下常見的代碼壞味道。
壞味道：Long Method(過長函數)
過長函數簡而言之就是函數長度超標了，包括橫向和縱向。
為什麼過長函數是一種壞味道?
橫向過長會導致無法一眼就能看出這行代碼的作用，需要用滑鼠慢慢往後邊拖，相信用小屏幕的小夥伴經常會遇到這個問題，拖動的過程會嚴重影響讀代碼的效率。
縱向過長其實就是出現了大函數，一個函數的行太多，使得函數難以讀懂，代碼修改難度大。
那麼如何解決過長函數問題呢?
關於橫向過長的問題，一般會在 IDE 中提前配置好最大寬度，比如80字符或者120字符(具體根據公司內部規範設置)，然後格式化代碼即可解決。
比如我們在寫 Java8 stream 鏈式表達式的時候可以會很長：
其實我們可以在.之前換行，這樣看起來一目了然。
關於縱向過長的問題其實就是這個方法或者函數職責不夠單一，一個函數中堆積太多功能。
重構的手段很簡單：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：同一個類中兩個方法含有相同的表達式
重構手段：將兩個方法共同的邏輯抽象出來。重構後：
場景2：兩個具有相同父類的子類內含有相同的表達式類 A 中有一個 method1，有三段邏輯。
類 B 中有一個 method2，也有三段邏輯。
重構手段：將重複代碼抽象成一個方法放在父類中，差異部分由子類各自實現。
重構後：
場景3：兩個毫無相關的類出現重複代碼
如果兩個沒有直接關聯的類出現重複代碼，可以考慮將重複的代碼抽象到一個獨立的普通類或者工具類中，適用方可以使用組合的方式調用。
代碼樣例這裡不再贅述，與場景1和2大同小異，相信聰明的你一定能明白。
壞味道：Long Parameter List(過長參數列)
全局變量是個邪惡的東西，數據是共享的並且每個線程都可以修改，太多了容易導致程序不可控，所以大家喜歡將變量以行參的方式傳遞，久而久之參數列越來越長了。
為什麼過長參數列是一種壞味道?
方法參數的數量太多會導致代碼可讀性非常差，如果有多個重載方法它們的方法參數都非常多，在寫代碼時很難判斷該調用哪一個。
當一個方法需要新增功能，每次都可能會新增一個方法參數，這樣導致調用方每次都要重新適配，小心被打哦，耗子尾汁。
如何解決過長參數列這種壞味道?
可以將多個參數封裝到一個 DTO 對象中，方法間的對象通過對象的傳輸而不是過長的參數。
數據傳輸對象(DTO)(Data Transfer Object)，是一種設計模式之間傳輸數據的軟體應用系統。
特別需要提醒的是有些情況下長參數也是合理的，因為使用參數可以避免某些依賴關係的產生。在編碼實踐中我們可以通過觀察長參數的方法，如果這個方法經常變動那你就要考慮重構這個方法了。基本原則：事不過三，過三重構。
壞味道：Shotgun Surgery(散彈式修改)
為什麼散彈式修改是一種代碼壞味道?
如果需要修改某個小功能，你需要在眾多不同的類中做修改，首先很難找全，其次很可能會遺漏，這種問題一般稱之為散彈式修改。
假如有多個類都使用了db.mysql.url這個變量，如果後面要將 mysql 切到 Oracle，那麼可能會涉及到多處修改。如何解決散彈式修改這種代碼壞味道呢?
可以使用 Move Method (搬移函數)和 Move Field (搬移欄位)把所有需要修改的代碼放進同1個類，如果暫時沒有合適的類，就創建一個。
壞味道：Speculative Generality(誇誇其談未來性)
在工作中經常會聽到有開發小夥伴說：昨天加班我將訂單模塊做了修改，未來可以……
聽到這裡你可以會鼓掌：牛叉啊，提前對功能模板預留了擴展性。但是不要急於故障，你看技術總監的臉黑著呢，為什麼呢?這位小夥伴的代碼可能是一種壞味道：誇誇其談未來性。
為什麼誇誇其談未來性是一種代碼壞味道?
網際網路需求迭代更新速度快，」未來可以「意味著當下並不需要，有時候過度的抽象和預留擴展也會讓系統難以理解，並且可能提前背上包袱往前走。
代碼上總是談未來可能性，會讓團隊陷入泥沼。每次有業務變動，開發人員都會考慮各種未來可能性，預留足夠多的擴展接口，這無疑極大增加了代碼複雜度，讓一個可能快速上線的需求變得慢下來。
如何解決誇誇其談未來性這種代碼壞味道呢?
在代碼架構設計中有一個原則叫：Simple Design (簡單設計原則)。
當實現當下業務代碼時需要考慮四個原則：通過測試、揭示意圖、消除重複、最少元素。
當需要為未來而寫的代碼時，可以幹這些：
(1)刪除那些覺的未來有用的參數、代碼、方法調用。
(2)修正方法名，使方法名揭示當下業務場景的意圖，避免抽象的技術描述詞。
如果代碼的改動確實是未來必然會發現的，那麼還是建議保留。誇誇其談未來性更多是指開發人員無依據臆測未來，導致代碼模塊被過度設計。
壞味道：Comments(過多的注釋)
在 《Clean Code》 中列舉了一些常見注釋壞味道：
為什麼過多的注釋是一種代碼壞味道呢?
好的注釋可以輔助開發人員快速閱讀理解代碼，過多的注釋或壞注釋可能會降低代碼的可讀性。
在開發實踐中經常有同學修改了代碼但是注釋沒有同步修改，代碼的實現已經與注釋內容不一致，容易產生誤導。
如何解決過多的注釋這種壞味道呢?
(1)如果代碼塊不再使用請直接刪除不要使用注釋。
(2)方法、變量的命名儘量見名知意，避免用注釋再解釋一遍。
(3)如果較短的注釋不能覆蓋方法的含義，可能是這個方法職責不單一，可以考慮重構這個方法。
總結：
文章列舉了幾種比較常見的代碼壞味道，希望大家在工作編碼中多多練習，爭取人人都能寫出好代碼，讓天下沒有難讀的代碼。
【編輯推薦】
【責任編輯：
武曉燕TEL：（010）68476606】