1 Duplicated Code（重复代码）
“代码中有很多坏味道，重复是最坏的一种”。一个类中的两个方法有重复代码，那么一定可以通过抽取方法的方式将重复代码放到另一个方法中以供调用；两个互为兄弟的子类中如果有重复代码可以将其重复代码抽取到父类中；两个没有关系的类中如果有重复代码，那么可以重新抽取一个类将重复代码放到这个第三方类中。
2 Long Method（长的方法）
程序越长理解起来就越困难，这已经是常识了，使用短小的方法首先符合高内聚的要求，同时也可以给通过给方法起一个好的名字来帮助理解方法的作用。如果感觉到方法的某个地方需要注释来说明什么，那么可以把这些东西放入一个独立的方法中，并以用途（注意不是实现手法）来命名方法。
3 Large Class（巨大的类）
如果希望写一个类来做很多的事情，那么最终势必导致重复和混乱的代码。类的设计应当遵循单一职责原则（SRP）。重构一个巨大的类可以使用抽取接口的方式来搞清楚这个类应该如何分解。
4 Long Parameter List（长参数列表）
这个对于做过Windows编程或者用过MFC（Microsoft Foundation Class）的程序员来说再熟悉不过了，Windows函数和MFC中的方法那些长得变态的参数列表对程序员来说都是恶梦。重构的方式很多，比较常见的是将相关的参数组织成一个对象来替换掉这些参数。
5 Divergent Change（分散的可变性）和Shotgun Surgery（散弹式手术）
这两种坏味道前者讲的是新功能难以加入，后者说的是某种变化会引发多个细节的修改。简单的说如果程序中的可变因素散落在代码的各个角落中，那么代码的维护将是一场恶梦。重构的方法是找到特定原因造成的所有变化，然后将它们抽取到另一个类中。设计模式中的桥梁模式就是为了解决这一问题而提供的解决方案。
6 Feature Envy（依恋情节）
这个真没想到如何翻译会比较容易理解，简单的说就是一个方法从另一个类的对象那里获取许多的值，重构的方案是将该方法移到另一个类中。听起来很简单，但是在实践的时候却经常会忘了这么做。
-7 Data Clumps（数据群集）
状况类似于长参数列表。
- 8 Primitive Obsession（基本类型偏执）
一个类中如果有很多基本类型的成员，通常可以考虑将不同的基本类型分散组装成对象，就像Hibernate中的组合映射那样，将一个类的对象嵌入到另一个类中作为其成员而不是只写一个类，里面有很多基本数据类型的成员。
9 Switch Statements（重复的switch语句）
：面向对象程序的一个明显特征就是用多态替换掉switch结构，因为这种switch结构会在多个地方重复。
- Parallel Inheritance Hierarchies（平行继承结构）
：情况跟Shortgun Surgery差不多，可以使用桥梁模式进行重构。
- Lazy Class（冗余类）
：如果一个类不值得存在，那么它就应该消失。
- Speculative Generality（投机通用性）
：如果你的抽象类、委托、方法的参数没有实际的作用，那么就应当被移除掉。
- Temporary Field（临时字段）
：类中某个字段只为某些特殊情况而设置。
- Message Chains（消息链）
：我个人并没有感觉到这个有多么坏。
- Middle Man（中间人）
：如果一个类的很多功能都通过委托给其他类来完成，那么就不如去掉这些中间人直接和真正负责的对象打交道。
- Inappropriate Intimacy（过于亲密）
：使用继承复用代码会经常性的引发这种问题，因为子类对父类的了解总是超过后者的主观愿望，如果你觉得这个孩子可以独立生活了，就应该让它离开继承体系，这一点跟面向对象设计原则中的合成聚合复用原则不谋而合。
- Alternative Classes with Different Interfaces（异曲同工）
：两个方法做同一件事情却有着不同的签名。
- Incomplete Library Class（不完整类库）。
- Data Class（数据类）
：类的退化结构。我们在分层开发中经常使用的失血模型（事务脚本模式）中的业务实体不就是数据类吗，这明显与面向对象的思想是背道而驰的。
- Refused Bequest（拒绝遗产）
：如果子类复用了父类的行为，又不愿意支持父类的接口，可以考虑用合成关系聚合关系取代继承关系来消除这种坏味道。
- Comments（注释劣质代码）
：注释不是用来补救劣质代码的，事实上如果我们去除了代码中的所有坏味道，当劣质代码都被移除的时候，注释已经变得多余，因为代码已经讲清楚了一切。
Eclipse的重构菜单：
320
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
