1、Duplicated Code(重复代码)
如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将它们合而为一，程序会变得更好。
2、Long Method(过长函数)
（1）“”间接层“”所能带来的全部利益－－解释能力、共享能力、选择能力－－都是由小型函数支持的。
（2）可以遵循这样一条原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。
（3）提炼哪一段代码的一个技巧：寻找注释；两个信号：条件表达式和循环。
3、Large Class(过大的类)
如果想利用单个类做太多事情，其内往往就会出现太多实例变量。一旦如此，Duplicated Code也就接踵而至了。
4、Long Parameter List(过长参数列)
因为太长的参数列难以理解，太多参数会造成前后不一致、不易使用，而且一旦你需要更多数据，就不得不修改它。如果将对象传递给函数，大多数修改都将没有必要，因为你很可能只需在传入对象内增加一两个字段，就能得到更多数据。
5、Divergent Change(发散式变化)
如果某个类经常因为不同的原因在不同的方向上发生变化，Divergent Change就出现了。
6、Shotgun Surgery(霰弹式修改)
如果每遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是Shotgun Surgery。
7、Feature Envy（依恋情结）
有一种经典的气味是：函数对某个类的兴趣高过对自已所处类的兴趣。
8、Data Clumps（数据泥团）
你常常可以在很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。这些总是绑在一起出现的数据真应该拥有属于它们自已的对象。
9、Primitive Obseession(基本类型偏执)
10、Switch Statements(switch惊悚现身)
面向对象程序的一个最明显特征就是：少用switch语句。从本质上主，switch语句的问题在于重复。你常会发现同样的switch语句散布于不同地点。
11、Parallel Inhertance Hierarchies(平行继承体系)
每当你为某个类增加一个子类，必须也为另一个类相应增加一个子类，便是这种坏味道。
12、Lazy Class(冗赘类)
如果一个类的所得不值其身价，它就应该消失。
13、Speculative Generality(夸夸其谈未来性)
用不上的装置只会挡你的路，所以，把它搬开吧。
14、Temporary Field(令人迷惑的暂时字段)
有时你会看到这样的对象：其内某个实例变量仅为某种特定情况而设。这样的代码让人不易理解，因为你通常认为对象在所有时候都需要它的所有变量。
15、Message Chains(过度耦合的消息链)
如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象.....这就是消息链。
16、Middle Man（中间人）
人们可能过度运用委托，也许你会看到某个类接口有一半的函数都委托给其他类，这就是过度委托。
17、Inappropriate Intimacy(狎昵关系)
一个类过多访问另一个类的私有成员
18、Alternative Classes with Different Interfaces（异曲同工的类）
如果两个函数做同一件事，却有不同的函数名，请运用rename method方法根据它们的用途重命名。
19、incomplete library class(不完美的库类)
库类构筑者没有未卜先知的能力，因此，库往往构造得不够好，而且往往不可能让我们修改其中的类使它完成我们希望的工作。这时有两个重构方法可采用：（1）如果你只想修改库类的一两个函数，可以运用introduce foreign method；（2）如果想要添加一大堆额外行为，就得运用introduce local extension。
20、Data Class（纯稚的数据类）
所谓Data Class是指：它们拥有一些字段，以及用于访问（读写）这么字段的函数，除此之外一无长物。Data Class就像小孩子，作为一个起点很好，但若要让它们像成熟的对象那样参与整个系统的工作，它们就必须承担一定责任。
21、Refused Bequest（被拒绝的遗赠）
Refused Bequest是指子类继承了父类的函数和数据，但子类只从中挑选几样来玩，不需要接受父类这么多的东西。按传统做法：你需要为这个子类新建一个兄弟类，再运用Push Down Method和Push Down Field把所有用不到的函数和变量下推给那个兄弟。这样一来，超类就只持有所有子类共享的东西。但是作者不建议你每次都这么做，这种坏味道十之八九很淡，不值得理睬。
22、Comments（过多的注释）
Comments可以带我们找到上面提到的各种坏味道。找到坏味道后，我们首先应该以各种重构手法把坏味道去除。完成之后我们常常会发现：注释已经变得多余了，因为代码已经清楚说明了一切。
如果你不知道该做什么，这才是注释的良好运用时机。除了用来记述将来的打算之外，注释还可以用来标记你并无十足把握的区域。你可以在注释里写下自已“为什么做某某事”。这类信息可以帮助将来的修改者，尤其是那些健忘的家伙。