看《重构-设计模式》第三章 代码的坏味道

没有特别精确的衡量标准，只能有类似的迹象

重复代码：

同一个类的两个函数含有相同的表达式。

两个互为兄弟的子类内含有相同的表达式。

过长函数：找到能提取为子函数的方法之一是找到注释

过大的类：分割为子类，可以先根据调用该类的接口进行分割

过长参数列：通过对象来传递一些参数

发散式变化：某个类因为不同的原因在不同的方向上发生变化，这时候可能需要分割该类了

散弹式变化：遇到变化要在不同类中修改时，把需要修改的代码放在一个类中

依恋情结：将一些经常使用数据的函数放在和数据一个类中，判断原则是将总是一起变化的东西放在一块

数据泥团：将相同的对象团提炼到一个对象上

基本类型偏执：建立小的对象来包含基本类型

switch惊悚现身：大多数可以考虑多态来替换switch

平行继承体系：问题：当你为一个类增加一个子类的时候，也要为另一个类增加子类，一般策略为让一个继承体系的实例引用另一个继承体系的实例。

冗赘类：当一个类值得维护它的代价，它就应该消失。

夸夸其谈未来性：如果函数或类的唯一用户就是测试用例，这就可以把这些类或者函数删掉了。

令人迷糊的暂时字段：类中的字段只有部分情况才使用，建议将这些字段和使用的函数重新放在一个类中

过度耦合的消息链：当一个用户向一个对象请求另一个对象，再通过这个对象请求另一个对象。。。这就是消息链。

可以将消息链中任一个对象重构，但这样会把一系列对象都变成middle man。另一更好的方法：根据消息链最后得到的对象是干什么，把使用该对象的代码提炼为函数，将该函数推送到消息链中

中间人：过度运用委托时可以将该类放进调用端

狎昵关系：两个类过度去探究彼此的private部分，可以采用提取函数，增加独立类来达到类的独立

异曲同工的类：当两个函数做着相同的事却有不同的签名，可以重新命名，并将一些行为移到类中。

不完美的库类：修改库来完成我们需要的功能

数据类：类似数据库表对应的对象类，只有读取写入其他字段的函数。

被拒绝的遗赠：当子类只使用了超类的一部分数据和函数时，传统的做法：为子类新建一个兄弟类，将使用不到的函数下推到哪个兄弟，这是基于“所有超类都是抽象的”。建议考虑使用继承来复用一些行为

过多的注释：试着重构让注释都显得多余