应该重构的代码
1.重复的代码：
重复代码在同一个类中的不同方法中，则直接提炼为一个方法
如果重复代码在两个互为兄弟的子类中，则将重复的代码提到父类中
如果代码类似，则将相同部分构成单独函数，或者用 Template Method 设计模式
重复代码出现在不相干的类中，则将代码提炼成函数或者放在独立的类中
2.过长的函数：
降低了可读性，应该将独立的功能提炼成新函数
3. 过大类
使得责任不清晰，容易造成重复代码，混乱，应该将过大类的功能拆分成多个功能单一的小类
4.过长的参数列
过长的参数列难以理解，而且容易传错参数。应该将参数列表用参数对象替换
5.发散式变化：
一个类由于不同的原因而被修改。应该将类拆分成多个，每个类只因为一种变化而修改。
6.霰弹式修改：
与发散式变化相反，遇到变化时需要修改许多不同的类。应该将类似的功能放到一个类中
7.依恋情结：
函数对某个类的兴趣高过对自己所处的类，通常是为了取其他类中的数据。应该将函数部分功能移到它感兴趣的类中
8.数据泥团：
在多个地方看到相同的数据项。例如：
多个类中相同的变量，多个函数中相同的参数列表，并且这些数据总是一起出现。应该将这些数据项放到独立的类中
9.基本类别偏执：
对象技术的新手通常不原因在小任务上运用小对象，比如结合数值和币别的money class，等，应该Replace Data Value with Object。
10.分支语句：
大量的分支、条件语句导致过长的函数，并且可读性差。应将它变成子类或者使用 State和 Strategy模式
11.平行继承体系
是霰弹式修改的特殊情况。一般是当你为某个类增加了一个子类，必须也为另一个类相应的增加一个子类。如果你发现某个继承体系的class名称前缀和另一个继承体系的class名称前缀完全相同。变素有问题了。 应该让一个继承体系的实体（instance）指涉（参考，引用，refer to）另一个继承体系的实体。
12 冗赘类（lazy class）
几乎没有用的组建 应该进行inline class
13.夸夸其谈未来性
现在用不到，觉得未来可以用到的代码，要警惕。应该将用不上的代码去掉
14.过度耦合的消息链
一个对象请求另一个对象，后者又请求另外的对象，然后继续。。。。，形成耦合的消息链。应该公布委托对象供调用
15 纯粹的数据类
将数据类中数据以Public方式公布，没对数据访问进行保护。应该 将数据封装起来，提供Get/Set方法。
16 过多的注释
代码有着长长的注释，但注释之所以多是因为代码很糟糕。先重构代码，再写上必要的注释
17 令人迷惑的暂时值域
如某个instance变量仅为某特定情况而设，在变量未被使用的情况下猜测当初设置目的非常困难。应该建立一个新的class，把所有和这个变量相关的代码都放到里面。