何谓重构
1. 重构(名词)
对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本
2. 重构(动词)
使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构。
为何重构
1. 改进软件设计
越难看出代码所代表的设计意图,就越难保护其中设计,于是该设计就腐败的越快。
经常性的重构可以帮助代码维持自己该有的形态。
重复代码越多,可能的修改就越困难,所有事物和行为在代码中只表述一次,这是优秀设计的根本。
2. 重构使软件更容易理解
一开始我所做的重构都像这样停留在细枝末节上。随着代码渐趋简洁,我发现自己可以看到一些以前看不到的设计层面的东西。
3. 重构帮助找到bug
对代码的理解,可以帮助我找到bug。
4. 重构提高编程速度
如果没有良好设计,或许某一段时间内你的进展迅速,但恶劣的设计很快就让你的速度慢下来。
你会把时间花在调试上面,无法添加新功能。修改时间越来越长,因为你必须花越来越多的时间去理解系统、寻找重复代码。
良好设计是维持软件开发速度的根本。重构可以帮助你更快速地开发软件,因为它阻止系统腐败变质,它甚至还可以提高设计质量。
何时重构
1.三次法则——第三次做重复的事
2.添加功能时——新特性的添加困难时。重构使得,在更好的理解代码的同时,改变结构,使得,新特性的添加更快速、更流畅。这也是良好设计的要求。
3. 修补错误时——对代码的理解,可以帮助我找到bug。
4. 复审代码时——复审本身就可以改善开发状况,这和重构有部分相同的目的
是什么让程序如此难以修改?
眼下我能想起下述四个原因,它们是:
难以阅读的程序,难以修改;
逻辑重复的程序,难以修改;
添加新行为时需要修改已有代码的程序,难以修改;
带复杂条件逻辑的程序,难以修改。
因此,我们希望程序:
(1)容易阅读;
(2)所有逻辑都只在唯一地点指定;
(3)新的改动不会危及现有行为;
(4)尽可能简单表达条件逻辑。
重构的难题
1. 数据库
绝大多数商用程序都与它们背后的数据库结构紧密耦合在一起
2. 修改接口
过度强调代码所有权的团队常常会犯这种错误。发布接口很有用,但也有代价。这个代价就是修改的代价,太多的代码已经依赖你的接口。
不要过早发布接口。请修改你的代码所有权政策,使重构更顺畅。
3. 难以通过重构手法完成的设计改动
我们很难(但还是有可能)将不考虑安全性需求时构造起来的系统重构为具备良好安全性系统。
4. 何时不该重构
现有代码根本不能正常运作。你可能只是试着做点测试,然后就发现代码中满是错误,根本无法稳定运作。
如果项目已近最后期限,你也应该避免重构。
重构与设计
如同前面总结的,它和设计彼此互补。
重构与性能
先重构,优化阶段再进行性能调优
重构起源
。。。。。。
完。