重构·改善既有代码的设计.02
前言
之前在《重构·改善既有代码的设计.01》中初步了解了重构的基本前提，基础原则等入门知识。今天我们继续第二更......
识别代码的坏味道
Duplicated Code
重复代码。最单纯的Duplicated Code就是“同一个类中含有相同的表达式”或“两个互为兄弟的子类内含有相同表达式”。
如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将他们合二为一，程序会变得更好。
Long Method
过长函数。当感觉需要用注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。
如何提炼一段代码，一个很好的技巧是：寻找注释。
Large Class
过大的类。通常如果类内的数个变量有着相同的前缀或字尾，这就意味有机会把它们提炼到某个组件内。
Long Parameter List
过长参数列表。对于OO（面向对象）语言来说，只需传给它足够的、让函数能从中获得自己需要的东西就行了。函数需要的东西多半可以在函数的宿主类中找到。
Divergent Change
发散式变化。某个类经常因为不同的原因在不同的方向上发生变化。指一个类受多种变化影响。
Shotgun Surgery
散弹式修改。如果每遇到某种变化，你都必须在许多不同的类内做出许多修改。顾名思义，霰弹枪发散，修改一个东西，发现修改的代码散布在四处。可以考虑把所有需要修改的代码放进同一个类中。指一个变化引发多个类相应修改。
Feature Envy
依恋情结。其实就是代码职责。函数对某个类的兴趣程序高于对自己所处类的兴趣。如果某个函数为了计算某个值，需要从另一个对象中调用几乎一般的取值函数，那么就该迁移到它该去的地方。
Data Clumps
数据泥团。评判方法是：删除众多数据项中的一项，其他数据项会不会因此失去意义？如果是，那么就是个明显的信号。你需要为他们产生一个新对象。
Primitive Obsession
基本类型偏执。
Switch Statements
switch惊悚现身。switch语句的问题在于重复。一般switch语句可以考虑用多态替换。
Parallel Inheritance Hierarchies
平行继承体系。单你为某个类增加一个子类，必须也为另一个类相应增加一个子类。如果你发现某个继承体系的类名称前缀和另一个继承体系的类名称前缀完全相同，那么便是这种坏味道。
Lazy Class
冗赘类。一个类的所得不值其身价，就让他消失。
Speculative Generality
夸夸其谈未来性。“我想我们总有一天需要做这事”，并因而企图以各式各样的钩子和特殊情况来处理一些非必要的事情。
Temporary Field
令人迷惑的暂时字段。比如某对象某个实例变量仅为某种特定情况而设。我们通常认为对象在所有时候都需要他的所有变量，在变量未被使用的情况下猜测当初其设置的目的，会很抓狂。
Message Chains
过度耦合的消息链。如一个对象请求另一个对象，然后再向后请求另一个对象，然后再向后请求另一个对象......
Refused Bequest
被拒绝的遗赠。继承体系中，子类应该继承超类的函数和数据。但如果子类复用了超累的行为（实现），却又不愿意支持超类的接口。就像他们得到所有礼物，却只从中挑选几样来玩。按传统的说法，这就意味着继承体系设计错误。
Comments
过多的注释。当你感觉需要攥写注释时，请先尝试重构，试着让所有注释都变得多余。试想一种情况：当你看到一段代码，有着很长的注释，然后你发现，这些注释之所以存在是因为代码写的很糟糕。视图用注释来说明函数的用意以及实现。这时候应该使用重构手法把这类坏味道去除，重构之后你会发现注释变得多余，因为代码已经说明了一切。
构筑测试体系
自测代码的价值：修复错误通常比较快，但找出错误却是噩梦一场。
“花合理实践抓出大多数bug”好过“穷尽一生抓出所有bug”
重构的第一步：构建可靠的测试环境
类应该包含他们自己的测试代码
确保所有测试都完全自动化，让它们检查自己的测试结果
一套测试就是一个强大的bug侦测器，能够大大缩减查找bug所需要的时间
攥写测试diamagnetic的最有用时机，是在开始编程之前
在重构之前先确保代码能够进行自我测试
频繁的进行测试。每次编译请把测试页考虑进去，每天至少执行每个测试一次
编写测试代码时， 一开始先让它们失败，测试一下测试代码的机制可以运行
每当收到一个bug报告，请先写一个单元测试来暴露这个bug
观察类该做的所有事情，然后针对任何功能的任何一种可能失败情况，进行测试
测试的要诀：测试你最担心出错的部分
编写未臻完善的测试并实际运行，好过对完美测试的无尽等待
作者提到，当测试数量达到一定程度之后，继续增加测试带来的效益会呈现递减态势，而非持续递增；如果试图编写太多测试，你也可能因为工作量太大而气馁，最后什么都写不成。你应该把测试集中在可能出错的地方。观察代码，看哪儿变得复杂；观察函数，思考哪些地方可能出错。
不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug。
小结
到此，刚看完整本书的5个章节。代码的坏味道和构筑测试体系加深了对于重构的认知。重构和设计模式等诸多思想一样，是需要反复学习，反复实践的。重构的技术就是以微小的步伐修改程序。希望真正吸收这些之后，能够看到一个不一样的代码世界。借此，共勉~
持续学习更新中......