这本书的第三章 - “代码的坏味道”很有意思，会告诉你什么是不好的代码，供人警示和检视自身。作者给出的代码的坏味道包括：
- Duplicated Code（重复代码）：“代码有很多中坏味道，重复是最坏的一种”，一个类中的两个方法有重复代码，那么一定可以通过抽取方法的方式将重复代码放到另一个方法中以供调用；两个互为兄弟的子类中如果有重复代码可以将其重复代码抽取到父类中；两个没有关系的类中如果有重复代码，那么可以重新抽取一个类将重复代码放到这个第三方类中。 不过说是这么说，但是做到这样我还有很长的一段路需要走，这是我目前的代码实力办不到的。
- Long Method（长的方法）：程序越长理解起来就越困难，这已经是常识了，使用短小的方法首先符合高内聚的要求，同时也可以给通过给方法起一个好的名字来帮助理解方法的作用。如果感觉到方法的某个地方需要注释来说明什么，那么可以把这些东西放入一个独立的方法中，并以用途来命名方法。
- Large Class（巨大的类）：如果希望写一个类来做很多的事情，那么最终势必导致重复和混乱的代码。类的设计应当遵循单一职责原则（SRP）。重构一个巨大的类可以使用抽取接口的方式来搞清楚这个类应该如何分解。 软件设计模式就很强调这一规则，单一职责原则，高内聚，一个类只有一个职责。
- Divergent Change（分散的可变性）和Shotgun Surgery（散弹式手术）：这两种坏味道前者讲的是新功能难以加入，后者说的是某种变化会引发多个细节的修改。简单的说如果程序中的可变因素散落在代码的各个角落中，那么代码的维护将是一场恶梦。重构的方法是找到特定原因造成的所有变化，然后将它们抽取到另一个类中。设计模式中的桥梁模式就是为了解决这一问题而提供的解决方案。
- 数据泥团
你经常可以在很多地方看到相同的数据：两个类中相同的字段，函数中相同的参数。这些一起出现的数据应该拥有属于他们自己的对象。这么做的好处是可以将很多参数列缩短，简化函数调用。一个好的判断方法：删掉众多数据中的一项，其他数据有没有因而失去意义，如果是，那你应该为它们产生一个新对象。一旦拥有新对象之后，你就能接着优化，比如把一些函数也移到新的类。不必太久，所有类都将在它们的小小社会中充分发挥价值。
这些都是开发中非常值得注意的点，我们在一点点的修改自身的问题，会让代码更加健康。