重构改善既有代码的设计
构筑测试体系
重构+测试 密不可分
自测试代码的价值
Q：程序员时间耗费在哪里？
调试
Q：类应该包含他们自己的测试代码吗？
在自动化无法进行覆盖的同时需要有代码测试机制
Q：继承和多态会让测试变的比较困难，是否还需要继续？
“花合理的时间抓出大多数bug”好过“穷尽一生抓出所有bug”
重构列表
重构的记录格式
E：重构手法都有五个部分：名称(重构词汇表)、简短概要、动机、做法、范例
这些重构手法有多成熟
E：重构的基本技巧——小步前进，频繁测试。
重新组织函数
对付过长的函数，手法：Extract Method、Inline Method
Extract Method
TheGreatest Difficulty：处理局部变量，而临时变量则是其中一个主要的困难源头
Ways：Replace Temp WithQuery，Split Temporary Variable
动机：
1、 每个函数的颗粒度都非常小，那么函数被复用的机会就更大
2、 这会使高层函数读起来就像一系列注释
3、 如果函数都是细粒度，那么函数的覆写也会更容易些
关键之处：在于函数和函数本体之间的语义距离，如果提炼可以强化代码的清晰度，那就去做，就算函数名称比提炼出来的代码还长也无所谓（不禁令人思考，其目的就是为了更清晰的阅读代码，不用写注释就能看懂其相关语义，那我是否可以说基类中的方法清晰可读性强，子类复用度就高？还有针对过长的算法是否更能体现其可读性呢？答案肯定是是的！）
做法：
1、 创造一个函数，根据函数的意图来命名
2、 将提炼出来的代码从源函数复制到新建的目标函数中
3、 仔细检查，判断是否引用了“作用域限于原函数”
4、 检查是否有“仅用于被提炼代码段”的临时变量
5、 检查被提炼代码段，看是否有局部变量的值被其改变
6、 将被提炼代码段中需要读取的局部变量，当做参数传给目标函数
7、 处理完所有局部变量后，进行编译
8、 调用
9、 编译测试
关键之处：如何处理好被提炼出来的函数内临时变量，这才是Extract Method如何做的关键（那么在ExtractMethod之前你必须对将要提出的函数的含义了解清楚，对其设计到的所有临时变量及成员变量的作用域及值非常清楚，否则过程的准确性谁来保证，Utest只是对过的保证，编译测试时间岂不很长）
Inline Method(内联函数)
注：在函数调用点插入函数本体，然后移除该函数
动机
1、 一大群组织不合理的函数，可内联到大型函数中，并从中提炼出组织合理的小型函数
2、 如果使用了太多间接层，那么对于函数来说就只是对另一个函数的简单委托，起不到真正意义上的清晰可读
注：我们提炼函数的标准是，找出那些有用的间接层，去掉无用的间接层
做法
1、 分析函数，确保函数不具多态性(一般不存在子类继承父类的内联函数，这种是不符合多态的标准)
2、 找出这个函数的所有被调用点
3、 将这个函数所有被调用点都替换为函数本体
4、 编译、测试
5、 删除该函数的定义
注：对于递归、多返回点、内联到对象且未提供访问函数等的情况不适用Inline Method
Inline Temp（内联临时变量）
将所有对该变量的引用动作，替换为对他赋值的那个表达式本身，目的：去掉无效的中间临时变量
Replace Temp With Query（以查询替代临时变量）
将表达式提炼到一个独立的函数中（这个函数只表述一种表达式），并将这个临时变量的所有引用点替换为对新函数的调用，此后，新函数就可被其他函数使用。
注：Replace Temp With Query 是Extract Method之前必不可少的一个步骤，当局部变量难以被提炼时，应该尽可能把他们替换为查询式。
Introduce Explaining Variable（引入解释性变量）
当表达式很复杂，或分为多个分步的表达式嵌套使用，此时将其中一部分结果放进一个临时变量，此变量名称来解释表达式用途。
注：使用场景->表达式有可能非常复杂而难以阅读，此时使用临时变量可以更容易管理并分解表达式。
Remove Assignments to Parametes（移除对参数的赋值）
避免给参数赋值，以免改变参数的值。故，一般采用引用参数，但是对于对象来说，对象引用是按值传递的，因此可以修改对象内部状态，单对参数对象赋值是没有意义的，他只是一个代码块
Replace Method with Method Object（以函数对象取代函数）
如果你有一个大型函数，其中度局部变量的使用无法采用Extract Method，那将这个函数放进一个单独对象中，如此一来，局部变量就成了对象内的字段，然后你可以再同一个对象中将这个大型函数分解为多个小型函数。
目的：强调小函数的优美、可读性