改善代码质量的几种重构模式

1. 过大的类：由于开发者没能很好地理解“单一职责原则”这一编码规则而导致类的规模过于庞大。由于在同一个类中存在着完成各种不相关功能的各种方法，因此这样的类随着时间的流逝会变得越来越大。

2. 过长的方法：由于如下几个原因，我们发现有些方法显得太长了：

• 在同一个方法中，几个代码块实现了不相关/多个功能。这主要是由于开发者不理解单一职责原则所导致的。
• 同一个方法中存在多个条件。我们发现在过长的方法中，这种情况是非常普遍的。这可以归结为由于开发者缺乏对McCabe代码复杂度和单一职责原则概念的理解所造成的。

3. 方法参数：有时方法会彼此传递几个参数进行相互的调用。这时，如果修改了参数列表中的一个参数，那就需要修改几个方法签名。

4. 遍布在各处的字面常量：有一些程序员新手会使用字面常量值（大多数是数字），在使用的时候心里对这些常量值有着确切的定义，但却没有将其赋给具名的常量。这会严重降低代码的可读性和可理解性。

5. 含糊不清的方法名：很多时候，下面这样的方法名会严重影响到代码的可读性与可理解性：

• 没有任何意义、含糊不清的名字
• 只是一个技术上的名字，与问题域没有任何关联关系。

根据上面所讨论的代码坏味道，下面给出可以有效解决这些问题的6种重构模式，合理使用这些模式能够帮你解决大多数的代码质量问题并成为一名更优秀的开发者。

1.抽取类与移动方法：如上所述，诸如过大的类等代码坏味道可以通过将类划分为恰当数量的小类来解决。在这些新类中，我们需要将原来的类中的一些属性和方法移动过来。除此之外，有时类中还会包含大量的方法，这些方法会被其他类所用，这种方法也可以移动到恰当的新类当中。

2.抽取方法：就像上面所介绍的，诸如过长的方法这种代码坏味道可以通过将原来方法中的代码抽取到新方法中来解决。

3.分解条件：很多时候，过长的方法实际上包含了过多的条件语句（if-else）。我们应该将这些条件抽取出来放到单独的方法当中，这会让代码的可读性与可理解性上一个新台阶。

4.引入参数对象/保留整个对象：在代码审查过程中，我发现将多个参数传递到方法中是一个很普遍的现象。如果要增加或是删除方法中的参数，那这么做就会引发问题。在这种情况下，我们建议将相关的参数组织为一个对象（引入参数对象），将对象而不是单独的参数传递到方法中去。

5.使用符号常量代替魔数：对于那些有确切含义并在很多地方使用的字面常量值来说，你应该将其赋给具名的常量。这会增强代码的可读性与可理解性。

6.重命名方法：含糊不清的方法名会影响到代码的可读性。我们应该使用有意义的方法名，与业务领域的术语相关，并且能够帮助开发者理解业务上下文中的代码。这是需要技巧的，需要开发者与业务分析师紧密配合来清楚地理解代码所要满足的业务需求。有趣的是，这种重构模式看起来似乎很简单，但实际上却经常被很多开发者所忽视。值得一提的是，很多IDE都提供了重命名这个重构选项，值得你尝试一下。