6 個重構方法可幫你提升 80% 的程式碼質量

　　Kumar是位涉獵廣泛的軟體工程師，對很多技術領域都有非常高的熱情，如Java/JEE、PHP、.NET、C/C++等程式設計語言、移動程式語言、應用安全、雲端計算、API、移動應用、Google Glass、大資料等等，其Twitter帳號是@eajitesh。近日，Kumar撰寫了一篇文章，談到了常見的程式碼壞味道以及改善程式碼質量的6種重構模式，並對每種重構模式的使用場景進行了詳盡的論述與討論。

　　在過去做了不少程式碼走讀，發現了一些程式碼質量上比較普遍的問題，以下是其中的前五名：

1. 臃腫的類: 類之所以會臃腫，是因為開發者缺乏對最基本的編碼原則，即“單一職責原則”（SRP）的理解。這些類往往會變得很臃腫，是由於不同的且在功能上缺少關聯的方法都放在了相同的類裡面。

2. 長方法: 方法之所以會變得很長主要是有以下幾個原因：

   1. 許多沒有關聯性的、功能複雜的模組的程式碼都放在相同的方法內。這主要是開發者缺乏SRP的概念。

   2. 多種條件都放在同一個方法內，這在長方法內經常會發生的。這是由於缺乏McCabe程式碼複雜度和SRP的概念的比較。

3. 大量的傳參: 我經常遇到這幾種情況，一些方法跟另一些方法進行互動，或者呼叫另一些方法的時候傳入大量的引數。這就會出現如果更改了其中一個引數，就得在多個方法內進行更改。

4. 常量值無處不在: 經常會發現開發者（尤其是新手）會使用一些具有明確含義的常量值（主要是魔鬼數字），但沒有給它們賦予合適的常量變數。這會降低程式碼的可讀性和可理解性。

5. 模糊的方法名: 許多時候，以下取的方法名會影響程式碼的可讀性和可理解性：

   1. 模糊的不具有任何意義的方法名

   2. 技術性的，卻沒有提及相關領域的名稱

　　6個處理上面程式碼異味的重構方法（手法）

　　以下是6個可以用來幫助你解決80%（80-20原則）的程式碼質量問題的重構方法，並能幫助你成為一個更優秀的開發者。

1. 提取類/抽離方法：正如上面提到的，像“臃腫的類”（一個類提供了本該有幾個類提供的功能）這種程式碼異味應該將原有類中的方法和屬性移動到適當數目的新類中去。舊類中對應新類的方法和屬性應該被移除。另外，有時候一些類過於臃腫是因為它包含了被其他類使用本應該是其他類的成員方法的成員方法。這些方法也應該被遷移到合適的類中。

2. 提取方法：像上面提到的“過長的方法”這種程式碼異味可以通過從舊方法中提取程式碼到一個或多個新方法中消除。

3. 分離條件：許多時候，一個方法很長是因為包含好幾個分支語句（if-else）。這些分支條件可以被提取和移動到幾個單獨的方法中。這確實能大大改善程式碼可讀性和可理解性。

4. 引入引數物件/保留全域性物件：在我做程式碼審查時發現另外一個很常見的情況 - 好幾個引數被傳入方法。問題主要與需要從已有方法中增加或者移除一個方法引數有關。在這種場景，建議將相關方法引數組成一個物件（引入引數物件），讓方法傳遞這些物件而不是每個單獨的引數。

5. 用符號常量替換魔法數字：對於有意義的並且到處被使用的字面常量，應該為它們分配一個命名常量。這能大大增強程式碼可讀性和可理解性。

6. 重新命名方法：正如上面提到的，模糊不清的方法名會影響程式碼的可使用性。這些模糊不清的名稱應該重新命名為有意義的可能與業務術語有關的名稱，來幫助開發者通過業務上下文更好地理解程式碼。這很需要技巧並且要求開發者與業務專家一起協作來理清程式碼需要滿足的業務需求。有趣的是，這種重構方法看起來似乎非常容易理解，但是常常被許多開發者忽視，雖然在Eclipse這種IDE的refactor選單項中經常出現這一項。

　　原文地址：http://vitalflux.com/top-6-refactoring-patterns-to-help-you-score-80-in-code-quality/