重构
重构作为敏捷实践的精髓之一
1重构的几个要点
重构不应改变原有程序的可观测的行为
把添加新功能和重构当做两件不同的事情来对待,就像两顶帽子,在开发过程中我们经常两顶帽子換着戴
小步重构,更安全的前进,让代码在绝大部分时间处于可工作的状恣
检垃圾式的重构:发现一个垃圾时,不想跑题太多,同时也不想将垃圾留在原地;如果此时很容易重构,就立即完成,否则就记录下来,等后续再来重构
绝大多数的重构是见机行事的,而非单独安排的一项工作
重构的唯一目的是让我们开发更快,用更少的工作量创造更高的价值;重构不是来自"整洁的代码""良好的工程实践"等道德要求,而是纯粹从经济角度出发的考量
自测试代码是重构的基石,也是持续集成的关键环节。
各种基础重构手法组合使用,以实现高级的重构目的
有人在得到一个好的设计之后,就完全忽略之前的代码,重新进行一遍实现。然而重新实现一遍代码真的不难,难点在于如何让之前的遗留代码还能正常工作
以子类取代类型码重构
• 用封装变量将类型码封装到一个函数内部
• 创建一个工厂函数,根据类型构造不同的子类
• 创建其中一个子类
• 在工厂函数中替換构造出来的对象
• 对每个类型重复上述操作
• 去除类型码
• 使用函数下移重构和以多志处理条件表达式重构来处理原来的函数调用处的代码
小步重构
在书中反复地乐此不疲地强调小步重构
以便可以随时回退到上一个可工作的版本再次来过。
菅地法则
我们应该至少在离开营地时,让营地比我们到来时更干净。
- 结论如果每次经过一段代码,都让其变得更干净,积少成多,垃圾总是会被处理掉
- 每个人都应当在提交代码时停下来想一下,我们这次提交是让代码更健康了, 还是更腐化了, 还是没变化?
只有我们每次提交代码都至少没有让代码更腐化,代码才能越来越健康
我们在增加功能的时候,顺便重构了原来的代码,让其可读性更高,可复用性更好等等。
重构与测试
测试是重构的保护傘,我们需要有一组可靠的测试才能放手进行重构
- 我们所有可能的组合
实践中我们需要适可而止,因为测试达到一定程度之后,其边际效用会递减
编写太多测试,我们可能因为工作量太大而气馁
我们应该把注意力集中在最容易出错和最没有信心的地方 - 测试的指标
覆盖率,能一定程度上衡量测试是否全面而有效, - 最佳的衡量方式
主观的感受
如果我们觉得对代码比较有信心,那就说明我们的测试做的不错了 - 不依赖于某个特定测试框架进行测试
喜欢使用 Spring提供的 SpringBootTest注解进行测试 - 关注的是应用自身的业务逻辑
业务逻辑才是测试的重点,而非框架的逻辑。当然有时候我们可能对框架的配置代码信心不够强(比如spring的配置还是比较复杂的),这个时候,我们可以有针对性的写少数几个测试来验证这些配置就足够了 - 而基于某个特定框架实现的测试往往维护困难。
测试都是仅仅基于 junit 实现的,那这些测试将非常容易理解,非常容易迁移
测试的问题在子其过度依赖于某个框架,测试运行过程中会执行到大量的框架代码,从而导致测试运行缓慢,出错了也不好定位问题。
