在走讀了一些代碼之后，發現了一些代碼質量普遍存在的問題，以下是其中的前五名：
1、臃腫的類：類之所以會臃腫，是因為開發者缺乏對最基本的編碼原則，即“單一原則（SRP）”的理解。這些類往往會變得很臃腫，是因為不同的且在功能上缺少關聯的方法都放在了相同的類里面。
2、長方法：主要由于以下原因造成的
（1）、許多沒有關聯性的，功能復雜的模塊的代碼都放在相同的方法內，這主要還是開發者缺少SRP概念
（2）、多個條件放在一個方法里，這種是由于缺乏McCabe代碼負責度和SRP的概念的比較
3、大量的傳參：我經常遇到這幾種情況，一些方法跟另外一些方法進行交互，或者調用另一些方法的時候傳入大量的參數，這就會出現如果更改了其中的一個參數，就得在多個方法內進行更改
4、常量值無處不在：經常會發現開發者會使用一些具有明確含義的常量值（主要是魔鬼數字），但是并沒有給它們賦予合適的常量變量，這會降低代碼的可讀性和可理解性
5、模糊的方法名：（1）、模糊的不具有任何意義的方法名 （2）、技術性的，卻沒有提及相關領域的方法

6個處理上面代碼異味的重構方法（手法）
以下是6個可以用來幫助你解決80%（80-20原則）的代碼質量問題的重構方法，并能幫助你成為一個更優秀的開發者。
提取類/抽離方法：正如上面提到的，像“臃腫的類”（一個類提供了本該有幾個類提供的功能）這種代碼異味應該將原有類中的方法和屬性移動到適當數目的新類中去。
舊類中對應新類的方法和屬性應該被移除。
另外，有時候一些類過于臃腫是因為它包含了被其他類使用本應該是其他類的成員方法的成員方法。
這些方法也應該被遷移到合適的類中。
提取方法：像上面提到的“過長的方法”這種代碼異味可以通過從舊方法中提取代碼到一個或多個新方法中消除。
分離條件：許多時候，一個方法很長是因為包含好幾個分支語句（if-else）。這些分支條件可以被提取和移動到幾個單獨的方法中。這確實能大大改善代碼可讀性和可理解性。
引入參數對象/保留全局對象：在我做代碼審查時發現另外一個很常見的情況 - 好幾個參數被傳入方法。問題主要與需要從已有方法中增加或者移除一個方法參數有關。在這種場景，建議將相關方法參數組成一個對象（引入參數對象），讓方法傳遞這些對象而不是每個單獨的參數。
用符號常量替換魔法數字：對于有意義的并且到處被使用的字面常量，應該為它們分配一個命名常量。這能大大增強代碼可讀性和可理解性。
重命名方法：正如上面提到的，模糊不清的方法名會影響代碼的可使用性。這些模糊不清的名稱應該重命名為有意義的可能與業務術語有關的名稱，來幫助開發者通過業務上下文更好地理解代碼。這很需要技巧并且要求開發者與業務專家一起協作來理清代碼需要滿足的業務需求。有趣的是，這種重構方法看起來似乎非常容易理解，但是常常被許多開發者忽視，雖然在Eclipse這種IDE的refactor菜單項中經常出現這一項。

總結

以上是生活随笔為你收集整理的6个重构方法提升80%的代码质量的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。