（1）重复代码。重复代码首当其冲。业内有许多工具可以检查代码重复率，例如jsinspect就是检查JavaScript代码重复率的工具之一。重复代码导致类似修改需要在代码中修改多处。
（2）过长函数。程序越长越难理解。早期编程语言中子程序调用需要额外的开销，因此不推荐拆解函数成为小函数。但现代面向对象的语言几乎完全避免了这种开销。提取长函数为小函数后，最关键的是给函数取一个好的名字。这样代码读者就可以直接通过函数名称了解函数的作用，而不是去看其中写了什么。
（3）过大的类。过大的类与过长函数类似，降低了代码可读性，破坏了程序良好的设计。使用Extract Class将相关的函数放在一起，成立一个新的类或新的子类。
（4）过长参数列。过长的参数列难以理解，太多参数会导致前后不一致。可以使用重构手法Replace Parameter with Method进行代码重构。同时也可以把一堆数据收集起来，使用对象替换它们。
（5）发散式变化。软件应该容易修改。一旦需要修改，我们希望能够跳转到系统的某一点，只在该处做修改。如果做不到这一点，便是代码坏味道。
（6）霰弹式修改。 霰弹式修改与发散式变化类似，但实际却相反。发散式修改最终的归宿是一处修改。霰弹式修改的修改目的是将修改放在一处，如果没有合适的类，则创造一个。
（7）依恋情节。 将数据与对数据的操作行为包装在一起。（此处翻译辣鸡，无法读懂，重读时参考原著）
（8）数据泥团。你常常在很多地方看到相同的三四项数据，例如两个类中相同字段、许多函数中相同的参数。这些捆绑在一起的数据应该有自己的对象。
（9）基本类型偏执。一些数据有封装好的对象时，应避免使用基本类型表示。如表示数值和币种的money类，由一个开始值和一个结束值构造的range类等。此时应该使用Range，而不是使用两个基本类型，start&end。
（10）switch惊悚现身。对于又臭又长的switch函数，应使用多态去替代它。对于js，有更好的使用方法，就是使用命令对象去替代switch。
（11）平行继承体系。每当你为某个类增加一个子类，也必须为另一个类增加一个子类，便是一种代码坏味道。策略一般是让一个继承体系的实例引用另一个继承体系的实例。
（12）冗赘类。如果一个类的所得不值其身价，它就应该消失。
（13）夸夸其谈未来性。如果一个函数或类是为了防止未来有用处，而唯一的用户是测试用例，就飘出来坏味道。
（14）令人迷惑的暂时字段。有些字段仅为某种特定的情况而设，例如iWhenXxx。
（15）过度耦合的消息链。当你看到用户向一个对象请求另一个对象，然后再请求另一个对象，然后再请求...这就是消息链。一旦对象间的关系有了任何变化，客户端就不得不做出相应的修改。
（16）中间人。 如果一个类接口中一半以上的函数都委托给其他类，就是过度运用。
（17）狎昵关系。两个类过度亲密，有许多共同点，便应该拆散他们。
（18）异曲同工的类。两个拥有相同或者极其相似的功能时，考虑合并。
（19）不完美的库类。因为一两个功能使用了程序库，但库不一定完美，此时应使用重构。
（20）纯数据的数据类。如果一个对象中只有数据，可以尝试将一些调用方法搬移到该类中来。纯数据的类作为一个起点很好，但参与整个系统的工作，它必须承担一些责任。（此处存疑，例如MVC中M就可以看作纯数据类）。
（21）被拒绝的遗赠。子类应该继承超类的数据和函数，但如果不想和不需要继承，就意味着继承体系设计错误。
（22）过多的注释。尽量用代码去解释自己，而不是使用注视来收拾烂摊子。
《重构》学习笔记（02）--代码坏味道
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
- 文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
- 文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
- 文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
推荐阅读更多精彩内容
- 何时重构、何时停止重构学会判断一个类内有多少实例变量算是太大、一个函数内有多少行代码算太长 下面是对各种坏味道的简...
