《重构》读书笔记（二）

• 编写优良的测试程序，可以极大提高编程速度，即使不进行重构也一样如此

• 确保所有测试都完全自动化，让它们自己检查测试结果

• 当你收到bug报告，请先写一个单元测试来暴露bug

• 测试应该是一种风险驱动的行为，测试的目的是希望找出现在或未来可能出现的错误

• 测试的要诀是：测试你最担心出错的部分。这样你就能从测试中得到最大利益

• 考虑可能出错的边界条件，把测试火力集中在那儿

• 几乎所有时刻，问题都源于过长函数

• 对付过长函数，一项重要的重构手法就是提取方法

• 提取函数最大的困难就是处理局部变量，而临时变量则是其中一个主要的困难源头

• 参数带来的问题比临时变量稍微少一些，前提是你不在函数内赋值给它们

• 当我看见一个过长的函数或者一段需要注释才能让人理解用途的代码，我就会将这段代码放进一个独立函数中

• 当你能给小函数很好的命名时，它们才能真正起作用，所以你需要在函数名称上下点功夫

• 函数长度不是问题，关键在于函数名称和函数本体之间的语义距离

• 将被提炼代码段中需要读取的局部变量，当作参数传给目标函数

• 有时候你会遇到某些函数，其内部代码和函数名称同样清晰，此时你应该去掉这个函数，直接使用其中的代码

• 表达式有可能非常复杂而难以阅读，这种情况下，临时变量可以帮助你将表达式分解为比较容易管理的形式

• 临时变量有各种不同用途，循环变量和结果收集变量就是两个典型例子，除了这两种情况，还有很多临时变量用于保存一段冗长代码的计算结果，以便稍后使用，这种临时变量应该只被赋值一次，如果它们被赋值超过一次，就意味着它们在函数中承担了一个以上的责任，如果临时变量承担多个责任，它就应该被替换（分解）为多个临时变量。同一个临时变量承担两件不同的事情，会代码阅读者糊涂，将它声明为final，确保它只被赋值一次

• 对于提高段函数的清晰度，使用final来修饰参数并无太大帮助，通常在较长的函数中使用它

• 如果你发现一件事情可以有更清晰的方式，就应该以较清晰的方式取代较复杂的方式

• 替换一个庞大而复杂的算法是非常困难的，只有先将它分解为较简单的小型函数，然后你才能很有把握的进行算法替换工作