对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提交其可理解性，降低其修改成本。
准确说出我所要的
利用重构来协助我理解不熟悉的代码
随着代码渐趋简洁，发现可以看到一些以前看不到的设计层面的东西。
我不是个伟大的程序员，只是个有着一些优秀习惯的好程序员。
几乎任何情况下都反对专门拨出时间重构。重构应该随时随地。不应该为重构而重构，你之所以重构，是因为你想做别的什么事，而重构可以帮助你把那些事做好。
事不过三，三则重构
最常见的重构时机就是我想给软件添加新特性的时候。
往往是为了帮助我理解需要修改的代码。
代码结构清晰，我就可以从中理解更多的东西。
代码的设计无法帮助我轻松添加我所需要的特性。
重构是一个快速流畅的过程
调试过程中运用重构，多半是为了代码更具可读性。
重构可以帮组我复审别人的代码。
程序难以相与的原因：
希望的程序：
技术复审是减少错误，提高开发速度的一条重要途径。
“计算机科学是一门科学：它相信所有问题都可以通过增加一个间接层来解决。 Dennis DeBruler”
但是它是一把双刃剑。
间接层的某些价值：
找到不值得的间接层，并将它拿掉。（最终只一处用）
让旧接口继续工作。请尽量这么做：让旧接口调用新接口。当你要修改某个函数名称时，请留下旧函数，让它调用新函数。Java中有deprecation不建议使用。
不要过早发布接口，请修改你的代码所有权政策，使重构更畅顺。
Java还有一种特别的接口修改：在throws子句中增加一个异常。通常，我总喜欢为整个包（package）定义一个异类基（就像java.sql的SQLEception）。
先想象设计重构为另一个设计的难度有多大？如果看上去简单，那么就不必太担心选择是否得当，于是我就会选最简单的设计，哪怕它不能覆盖所有潜在的需求也没关系。但如果预先看不到简单的重构办法，我就会在设计投入更多力气。不过我发现，后一种情况很少出现。
重构它还不如重新写一个来得简单。
重构之前，代码必须起码能够在大部分情况下正常运作。
将“大块头软件”重构为封装良好的小型组件。
如果项目已近最后期限，你也应该避免重构。
比喻：重构工作是“债务”，公司可以借债，但不要过重。
多个项目经验显示：重构的确能够提高生产力。如果你最后没有足够时间，通常表示你其实早该进行重构。
如果问“把一个简单的解决方案重构成一个灵活的方法有多大难度？” 如果答案是“相当容易”（大多数时候都如此），那么你就可以只需实现目前的简单方案就行了。
哪怕你完全了解系统，也请实际度量它的性能，不要臆测。
重构，使软件的性能优化更容易。除了对性能有严格要求的实时系统，其他任何情况下“编写快速软件”的秘密就是：首先写出可调的软件，然后调整它以求获得足够速度。
三种编写快速软件的方法
最严的是时间预算法
持续关注法 事与愿违，因为性能改善一旦分散到程序各角落，每次改善都只不过是从对程序行为的一个狭隘视角出发而已。
通常，大半时间都耗费在一小半代码身上。
需要一个度量工具，找出大量消耗时间和空间的性能热点。小幅度改进，测试，度量。
良好构造的程序可以优化这一过程。
有比较充裕的时间调整性能，可以更快添加功能。
可以在性能分析时便有较细的粒度。更好的理解选择，更清楚哪种调整起关键作用。
本节，我们把重构看做整个软件开发过程的一个关键环节。
我发现重构可以帮助我写出更快的软件。短期看来，重构的确可能使软件变慢，但它使优化阶段的软件性能调整更容易，最终还是会得到好的效果。
《重构-改善既有代码的设计》Martin Fowler 摘要： 第二章 重构的原则
原文地址：http://blog.csdn.net/tanxiang21/article/details/27339861
