代码的坏味道

重复代码：设法合二为一
同一个类的两个函数还有相同的表达式，这时需要提炼出重复代码。
两个互为兄弟的子类内含有相同的表达式，可以提炼相同代码，并放到父类中。如果只是代码间相似，并非完全相同，那么可以将相似部分和差异部分拆开，构成单独的函数。然后你可以使用模板方法的设计模式。
如果两个毫不相关的类中出现重复代码，则可以将重复代码提炼成一个函数放到一个独立类中或者只放在某一个类中（总之要放在合适的地方），然后其他类都去调用这个函数。
过长函数
一条原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。哪怕替换后的函数调用动作比函数自身还长，只要函数名称能够解释其用途，我们也该毫不犹豫的那么做。关键不在于函数的长度，而在于函数“做什么”和“如何做”之间的语义距离。
过大的类
类内如果有太多代码，也是代码重复、混乱并最终走向死亡的源头。最简单的解决方案是把多余的东西消弭于类内部。如果有五个“百行函数”，它们之间很多代码都相同，那么或许你可以把它们编程五个“十行函数”和十个提炼出来的“双行函数”。
过长参数列：用对象做参数来减少参数个数
有了对象，就不必把函数需要的所有东西都以参数传递给它了，只需传给它足够的、让函数能从中获得自己需要的东西就行了。函数需要的东西多半可以在函数宿主类中找到。如果将对象传递给函数，大多数修改都将没有必要，因为你很可能只需（在函数内）增加一两条请求，就能得到更多的数据。
这里有一个重要的例外：有时候你明显不希望造成“被调用对象”与“较大对象”间的某种依赖关系。这时候将数据从对象中拆解出来单独作为参数，也很合情合理。
发散式变化：一个类受多种变化的影响
如果某个类经常因为不同的原因在不同的方向上发生变化，发散式变化的坏味道就出现了。针对某一外界变化的所有相应修改，都只应该发生在单一类中，而这个新类内的所有内容都应该反应次变化。
霰弹式修改：一种变化引发多个类相应修改
如果每遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是霰弹式修改。这种情况下，可以把所有需要修改的代码放进同一个类，如果没有合适的类可放，就创造一个。
依恋情节
对象技术的全部要点在于：这是一种“将数据和对数据的操作行为包装在一起”的技术。
有一种经典的气味是：函数对某个类的兴趣高过对自己所处类的兴趣。这种孺慕之情最通常的焦点便是数据。
处理这种坏味道的原则是：判断哪个类拥有最多被此函数实用的数据，然后就把这个函数和那些数据摆在一起。
最根本的原则是：将总是一起变化的东西放在一块。
数据泥团：总是绑在一起的数据应该拥有属于它们自己的对象
一个好的评判办法是：删掉众多数据中的一项，其他数据有没有因此而失去意义？如果他们不再有意义，这就是一个明确信号：你应该为它们产生一个新对象。
基本类型偏执：将数据组织成有意义的形式，不偏执于基本类型
对象技术的新手通常不愿意在小任务上运用小对象。
如果你有一组应该总是被放在一起的字段（基本类型的数据），那么可以尝试将这组数据放到一个单独类中变成结构类型的数据
switch语句
面向对象程序的一个最明显特征就是：少用switch（或case）语句。从本质上说，switch语句的问题在于重复。面向对象中的多态概念可为此带来优雅的解决办法。
平行继承体系
如果你发现某个继承体系的类名称前缀和另一个继承体系的类名称前缀完全相同，便是问到了这种坏味道。
消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。
当有人说“噢， 我想我们总有一天需要做这件事”，并因而企图以各式各样的钩子和特殊情况来处理一些非必要的事情，这种坏味道就出现了。
纯稚的数据类是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。
这种类如果get/set方法均是public的，则需要引起注意，应该进行适当的封装，而不是全部公有化。
被拒绝的遗赠
子类应该继承超类的函数和数据。但如果他们不想或不需要继承所有的函数和数据，则应该为这个子类新建一个兄弟类，把所有用不到的函数和数据放到兄弟类中，他们共享的数据和函数则放到共同的超类中。
过多的注释
当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余
如果你不知道该做什么的，这才是注释的良好运用时机。