重构改善既有的代码设计(重构原则 )
重构:对软件内部结构的一种调整,目的是再不改变软件的可观察行为的前提下,提高其可理解性,降低其修改成本。
两顶帽子
添加新功能 添加新功能时不应该修改既有代码,只管添加新功能,通过测试
重构 重构时你就不能再添加功能,只管改进程序结构,此时你不应该添加任何测试,只在绝对必要(用以处理接口变化)时才修改测试
为何重构
何时重构
- 三次法则:
- 第一次做某件事时只管去做;第二次做类似的事会产生反感第三次再做类似的事,你就应该重构。(事不过三,三则重构)
- 添加功能时重构
- 修补错误时重构
重构的难题
- 数据库重构
- 修改接口
- 让旧接口调用新接口,当你要修改某个函数的名称时请留下旧函数,让它调用新函数 。千万不要复制函数实现,那会让你陷入重复代码的泥淖中难以自拔。你还应该使用java中depreciation注解,将旧接口标记为
@deprecated
。
- 让旧接口调用新接口,当你要修改某个函数的名称时请留下旧函数,让它调用新函数 。千万不要复制函数实现,那会让你陷入重复代码的泥淖中难以自拔。你还应该使用java中depreciation注解,将旧接口标记为
- 难以通过重构手法完成设计的改动
- 先想像重构的情况。考虑选设计方案时,我会问自己:将某个设计重构为另一个设计的难度又多大?看上去很简单,我就不必太担心选择是否得当,于是我就会选择最简单的设计,哪怕他不能覆盖所有潜在的需求也没关系,但如果预先看不到简单的重构办法,我就会在设计上投入更多的力气。
- 何时不该重构
现有代码根本不能正常运作。重构之前,代码必须起码能够在大部分情况下正常运作 如果项目已近最后的期限,你也应该避免重构,如果项目已经非常接近最后期限,你不应该再分心于重构,因为已经没有时间了。重构能够提高生产力如果最后你没有足够时间,通常就表示你其实早该进行重构。
重构与设计
- 如果选择重构,问题的重点就改变了,你仍然做预先设计,但是不必一定找出正确的解决方案,此刻的你只需要得到一个足够合理的解决方案就够了。
- 有了重构,你就可以通过一条不同的途径来应付变化带来的风险。你仍旧需要思考潜在的变化,仍旧需要考虑灵活的解决方案。但是你不必再主意实现这些解决方案而是应该问问自己:"把一个简单的解决方案重构成这个灵活的方案又多大难度?"如果答案是“相当容易”,那么就只需要实现目前的简单方案就行了。
间接层和重构(间接层的价值)
- 允许逻辑共享
- 比如说一个子函数再两个不同的地点被调用,或超类中的某个函数被所有子类共享
- 分开解释意图和实现
- 你可以选择每个类和函数的名字,这给你一个解释自己意图的机会。类或函数内部则解释实现了这个意图的做法。如果类和函数内部又以更小单元的意图来编写,你所写的代码就可以描述其结构中的大部分重要信息
- 隔离变化
- 很可能我在两个不同的地点使用同一对象,其中一个地点我想改变对象行为,但如果修改了它,我就要冒同时影响两处的风险。为此我做出一个子类,并在需要修改出引用这个子类。现在,我可以修改这个子类而不必承担午一中影响另一处的风险。
- 封装条件逻辑
- 对象有一种奇妙的消息机制:多态消息,可以灵活而清晰地表达条件逻辑。将条件逻辑转化为消息形式,往往能降低代码的重复,增加清晰度并提高弹性。