构筑测试体系
重构+测试 密不可分
自测试代码的价值
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,那将这个函数放进一个单独对象中,如此一来,局部变量就成了对象内的字段,然后你可以再同一个对象中将这个大型函数分解为多个小型函数。
目的:强调小函数的优美、可读性