1、Duplicated Code（重复代码）
坏味道行列中，首当其冲的就是Duplicated Code。如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将它们合而为一，程序会变得更好。
2、Long Method（过长函数）
拥有短函数的对象会活得比较好、比较长。不熟悉面向对象技术的人，常常觉得对象程序中只有无穷无尽的委托，根本没有进行任何计算。和此类程序共同生活数年之后，你才会知道，这些小小函数有多大价值。“间接层”所能带来的全部利益：解释能力、共享能力、选择能力，都是由小型函数支持的。
3、Large Class（过大的类）
如果想利用单个类做太多事情，其内往往就会出现太多实例变量。一旦如此，Duplicated Code也就接踵而至了。
4、Long Parameter List（过长参数列）
刚开始学习编程的时候，老师教我们：把函数所需的所有东西都以参数传递进去。这可以理解，因为除此之外就只能选择全局数据，而全局数据是邪恶的东西。对象技术改变了这一情况：如果你手上没有所需的东西，总可以叫另一个对象给你。因此，有了对象，你就不必把函数需要的所有东西都以参数传递给它了，只需传给它足够的、让函数能从中获得自己需要的东西就行了。函数需要的东西多半可以在函数的宿主类中找到。面向对象程序中的函数，其参数列通常比在传统程序中短得多。
5、Divergent Change（发散式变化）
我们希望软件能够更容易被修改：毕竟软件再怎么说本来就该是“软”的。一旦需要修改，我们希望能够跳到系统的某一点，只在该处做修改。如果不能做到这点，你就嗅出两种紧密相关的刺鼻味道中的一种了。
6、Shotgun Surgery（散弹式修改）
Shotgun Surgery类似Divergent Change，但恰恰相反。如果每遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是Shotgun Surgery。如果需要修改的代码散布四处，你不但很难找到它们，也很容易忘记某个重要的修改。
7、Feature Envy（依恋情结）
对象技术的全部要点在于：这是一种“将数据和对数据的操作行为包装在一起”的技术。有一种经典气味是：函数对某个类的兴趣高过对自己所处类的兴趣。这种孺慕之情最通常的焦点便是数据。无数次经验里，我们看到某个函数为了计算某个值，从另一个对象那儿调用几乎半打的取值函数。疗法显而易见：把这个函数移至另一个地点。你应该使用Move Method把它移到它该去的地方。有时候函数中只有一部分受这种依恋之苦，这时候你应该使用Extract Method把这一部分提炼到独立函数中，再使用Move Method带它去它的梦中家园。
8、Data Clumps（数据泥团）
数据项就像小孩子，喜欢成群结队地待在一块儿。你常常可以在很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。这些总是绑在一起出现的数据真的应该拥有属于它们自己的对象。首先请找出这些数据以字段形式出现的地方，运用Extract Class将它们提炼到一个独立对象中。然后将注意力转移到函数签名上，运用Introduce Parameter Object或Preserve Whole Object为它减肥。这么做的直接好处是可以将很多参数列缩短，简化函数调用。是的，不必在意Data Clumps只用上新对象的一部分字段，只要以新对象取代两个（或更多）字段，你就值回票价了。
9、Primitive Obsession（基本数据偏执）
大多数编程环境都有两种数据：结构类型允许你将数据组织成有意义的形式；基本类型则是构成结构类型的积木块。结构总是会带来一定的额外开销。它们可能代表着数据库中的表，如果只为做一两件事而创建结构类型也可能显得太麻烦。
10、Switch Statements（switch惊悚现身）
面向对象程序的一个最明显特征就是：少用switch（或case）语句。从本质上说，switch语句的问题在于重复。你经常会发现同样的switch语句散布于不同的点。如果要为它添加一个新的case子句，就必须找到所有switch语句并修改它们。面向对象中的多态概念可为此带来优雅的解决办法。
11、Parallel Inheritance Hierarchies（平行继承体系）
Parallel Inheritance Hierarchies其实是Shotgun Surgery的特殊情况。在这种情况下，每当你发现某个继承体系的类名称前缀和另一个继承体系的类名称前缀完全相同，便是闻到了这种坏味道。
12、Lazy Class（冗赘类）
你所创建的每一个类，都得有人去理解它、维护它，这些工作都是要花钱的。如果一个类的所得不值其身价，它就应该消失。项目中经常会出现这样的情况：某个类原本对得起自己的身价，但重构使它身形缩水，不再做那么多工作；或开发者事前规划了某些变化，并添加一个类来应付这些变化，但变化实际上没有发生。不论上述哪一种原因，请让这个类庄严赴义吧。如果某些子类没有做足够的工作，试试Collapse Hierarchy。对于几乎没用的组件，你应该以Inline Class对付它们。
13、Speculative Generality（夸夸其谈未来性）
这个令我们十分敏感的坏味道，命名者是Brian Foote。当有人说“噢，我想我们总有一天需要做这事”，并因而企图以各式各样的钩子和特殊情况来处理一些非必要的事情，这种坏味道就出现了。那么做的结果往往造成系统更难理解和维护。如过所有装置都会被用到，那就值得那么做；如果用不到，就不值得。用不上的装置只会挡你的路，所以，把它搬开吧。
14、Temporary Field（令人迷惑的暂时字段）
有时你会看到这样的对象：其内某个实例变量仅为某种特定情况而设。这样的代码让人不易理解，因为你通常认为对象在所有时候都需要它的所有变量。在变量未被使用的情况下猜测当初其设置目的，会让你发疯的。
15、Message Chains（过度耦合的消息链）
如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象。。。。。。这就是消息链。实际代码中你看到的可能是一长串getThis()或者一长串临时变量。采取这种方式，意味客户代码将与查找过程中的导航结构紧密耦合。一旦对象间的关系发生任何变化，客户端就不得不做出相应修改。
16、Middle Man（中间人）
对象的基本特征之一就是封装：对外部世界隐藏其内部细节。封装往往伴随委托。比如说你问主管是否有时间参加一个会议，他就把这个消息“委托”给他的记事簿，然后才能回答你。很好，你没必要知道这位主管到底使用传统记事簿或电子记事簿亦或秘书来记录自己的约会。
17、Inappropriate Intimacy（狎昵关系）
有时你会看到两个类过于亲密，花费太多时间去探究彼此的private成份。如果这发生在两个“人”之间，我们不必做卫道士；但对于类，我们希望它们严守清规。
18、Alternative Classes with Different Interfaces（异曲同工的类）
如果两个函数做同一件事，却有着不同的签名，请运用Rename Method根据它们的用途重新命名。但这往往不够，请反复运用Move Method将某些行为移入类，直到两者的协议一致为止。如果你必须重复而赘余地移入代码才能完成这些，或许可运用Extract Superclass为自己赎点罪。
19、Incomplete Library Class（不完美的库类）
复用常被视为对象的终极目的。不过我们认为，复用的意义经常被高估：大多数对象只要够用就好，但是无可否认，许多编程技术都建立在程序库的基础上，没人敢说是不是我们都把排序算法忘得一干二净了。
20、Data Class（纯稚的数据类）
所谓Data Class是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无所长。这样的类只是一种不会说话的数据容器，它们几乎一定被其他类过份细琐地操控着。这些类早期可能拥有public字段，果真如此你应该在别人注意到它们之前，立刻运用Encapsulate Field将它们封装起来。如果这些类内含容器类的字段，你应该检查它们是不是得到了恰当的封装；如果没有，就运用Encapsulate Collection把它们封装起来。对于那些不该被其他类修改的字段，请运用Remove Setting Method。
21、Refused Bequest（被拒绝的遗赠）
子类应该继承超类的函数和数据。但如果它们不想或不需要继承，又该怎么办呢？它们得到所有礼物，却只从中挑选几样来玩！
22、Comments（过多的注释）
别担心，我们并不是说你不该写注释，从嗅觉上说，Comments不是一种坏味道，事实上它们还是一种香味呢。我们之所以要在这里提到Comments，是因为人们常把它当作除臭剂来使用。常常会有这样的情况：你看到一段代码有着长长的注释，然后发现，这些注释之所以存在乃是因为代码很糟糕。这种情况的发生次数之多，实在令人吃惊。
内容来自：《重构—改善既有代码的设计》