改善代碼品質的6種重構模式

本文來源于我在InfoQ中文站原創的文章，原文位址是：http://www.infoq.com/cn/news/2014/02/top-6-refactoring-patterns

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

最近一段時間，我參與了幾次代碼審查，發現了5種出現次數較多的代碼壞味道，總結如下：

1. 過大的類：由于開發者沒能很好地了解“單一職責原則”這一編碼規則而導緻類的規模過于龐大。由于在同一個類中存在着完成各種不相關功能的各種方法，是以這樣的類随着時間的流逝會變得越來越大。

2. 過長的方法：由于如下幾個原因，我們發現有些方法顯得太長了：

• 在同一個方法中，幾個代碼塊實作了不相關/多個功能。這主要是由于開發者不了解單一職責原則所導緻的。
• 同一個方法中存在多個條件。我們發現在過長的方法中，這種情況是非常普遍的。這可以歸結為由于開發者缺乏對McCabe代碼複雜度和單一職責原則概念的了解所造成的。

3. 方法參數：有時方法會彼此傳遞幾個參數進行互相的調用。這時，如果修改了參數清單中的一個參數，那就需要修改幾個方法簽名。

4. 遍布在各處的字面常量：有一些程式員新手會使用字面常量值（大多數是數字），在使用的時候心裡對這些常量值有着确切的定義，但卻沒有将其賦給具名的常量。這會嚴重降低代碼的可讀性和可了解性。

5. 含糊不清的方法名：很多時候，下面這樣的方法名會嚴重影響到代碼的可讀性與可了解性：

• 沒有任何意義、含糊不清的名字
• 隻是一個技術上的名字，與問題域沒有任何關聯關系。

根據上面所讨論的代碼壞味道，下面給出可以有效解決這些問題的6種重構模式，合理使用這些模式能夠幫你解決大多數的代碼品質問題并成為一名更優秀的開發者。

1.抽取類與移動方法：如上所述，諸如過大的類等代碼壞味道可以通過将類劃分為恰當數量的小類來解決。在這些新類中，我們需要将原來的類中的一些屬性和方法移動過來。除此之外，有時類中還會包含大量的方法，這些方法會被其他類所用，這種方法也可以移動到恰當的新類當中。

2.抽取方法：就像上面所介紹的，諸如過長的方法這種代碼壞味道可以通過将原來方法中的代碼抽取到新方法中來解決。

3.分解條件：很多時候，過長的方法實際上包含了過多的條件語句（if-else）。我們應該将這些條件抽取出來放到單獨的方法當中，這會讓代碼的可讀性與可了解性上一個新台階。

4.引入參數對象/保留整個對象：在代碼審查過程中，我發現将多個參數傳遞到方法中是一個很普遍的現象。如果要增加或是删除方法中的參數，那這麼做就會引發問題。在這種情況下，我們建議将相關的參數組織為一個對象（引入參數對象），将對象而不是單獨的參數傳遞到方法中去。

5.使用符号常量代替魔數：對于那些有确切含義并在很多地方使用的字面常量值來說，你應該将其賦給具名的常量。這會增強代碼的可讀性與可了解性。

6.重命名方法：含糊不清的方法名會影響到代碼的可讀性。我們應該使用有意義的方法名，與業務領域的術語相關，并且能夠幫助開發者了解業務上下文中的代碼。這是需要技巧的，需要開發者與業務分析師緊密配合來清楚地了解代碼所要滿足的業務需求。有趣的是，這種重構模式看起來似乎很簡單，但實際上卻經常被很多開發者所忽視。值得一提的是，很多IDE都提供了重命名這個重構選項，值得你嘗試一下。