重构(一)-重构的意义与原则

——本文是参考Martin Fowler的《重构》一书做的总结。

(一)什么是重构?

对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

(二)为什么要重构？

2.1 重构改进软件设计

如果没有重构，程序的设计会逐渐腐败变质。
经常性的重构有助于帮助代码维持其原有的设计形态。

2.2 重构使软件更容易理解

“早期重构就像是擦掉窗户上的污垢，使你看得更远！”

代码的易读性，也是重构的目的之一。随着重构的进行，代码愈发易懂，就可以慢慢看到一些设计层面的东西，将对代码的理解提高到更高层次上。

2.3 重构帮助找到bug

“优秀的程序员是拥有优秀的开发习惯的！”

重构的过程中，随着对代码了解的深入，就更容易发现代码中潜藏的bug。

2.4 重构提高编程速度

良好的设计是快速开发的基础。

劣质的代码给维护工作带来太大的时间开销，以及给日后的开发埋下定时炸弹。定期重构能提高开发效率。

(三)何时重构？

重构不应是一件特别安排时间要做的事情！不应该为了重构而重构！
重构应该随时随地进行，当遇到需要重构的情况，就应当考虑重构。

3.1 三次法则

事不过三，三则重构。

当你再而三做一些繁琐的操作的时候，可以考虑重构。

3.2 添加功能时重构

添加新功能时，常常会为了急于实现功能而选择最容易实现的方式进行开发，如果通过某种设计，能够是这部分逻辑更加容易理解，并理解更深层次的东西，那么重构是应当考虑的一件事情。

3.3 修补错误时重构

出现错误的地方很可能是因为代码不够清晰，不能让人一眼就看出的bug。所以在bug出现的地方就该考虑可否通过重构使其更加容易维护。

3.4 复审代码时重构

定期复审代码是一个良好的编程习惯。可以更加理解整个框架的逻辑，包括自己或者他人所写的逻辑。
而在审查代码的同时，有可能就会发现重构的可能。

(四)重构的难题以及何时不该选择重构？

4.1 数据库

重构经常出问题的一个领域就是数据库。绝大多数程序都与其背后的数据库紧密关联，这也是数据库结构如此难以修改的原因之一。

4.2 接口

许多重构手法会修改到接口，若该接口已发布，所有用户都必须对这个变化做出反应，可以保留旧接口，让旧接口调用新接口，并标注旧接口已过时。

4.3 何时不该选择重构？

有时候既有代码太过混乱复杂，重构它不如推翻重写来的好。(重写的信号：代码中满是错误，根本无法稳定工作。)
项目临近最后期限，也应该避免重构，先要保证完成项目目标功能。

(五)重构与设计

重构与设计彼此互补。

基本不可能通过预先设计就建造一个可以应对各种变化的灵活的解决方案。用户的需求是不确定且可能还是不断变化的，软件需求会随着迭代的进行做各种调整。因此，仅仅通过预先做好设计，是很难满足移动开发和敏捷开发需求的了。
一些极限编程的支持者认为可以不做任何设计，只管按照最初想法开始编码，让代码有效运作，然后再将它重构成型，最终获得设计良好的软件。这种做法确实可行，但并不是最有效的途径。事先做好设计可以节省高昂的返工成本。

更有效的做法是依然做预先设计，但不必一定找出正确的解决方案，只需要先设计一个足够合理的解决方案就够了，在实现这个解决方案的时候，对问题的理解也会逐渐加深，可能会察觉最佳解决方案和当初设想的有所不同，再通过重构，使得预先设计方案逐渐演变为最佳的解决方案。

(六)重构与性能

如果做的任何修改都是为了提高性能，通常都会难以维护，影响开发效率。如果最终得到的软件更快了，那么这些损失尚有所值，可惜通常事与愿违，因为性能改善分散到程序各角落，每次改善不过是从程序行为的狭隘角度出发的。
前期开发应当编写良好的程序，不对性能投以特别的关注，直至性能优化阶段，再按照某个特定程序对性能进行优化。

重构使代码容易理解和修改，从而使得性能优化变得容易

程序耗时的部分往往集中在一小部分代码上，对性能做优化，就是主要对这一部分耗时代码的优化。短期来看，重构可能使软件变慢，但它使优化阶段的软件性能调整更容易，最终得到好的效果。
在性能优化阶段，首先应该用一个度量工具来监控程序的运行，找到程序中哪些地方在大量消耗时间和空间。这样就可以找出性能热点所在的一小段代码。然后集中关注这些性能热点，并使用持续关注法中的优化手段来优化它们。简言之就是：发现热点，去除热点。