有段时间对项目做了重构，有不少感触，分享一下。

首先什么是重构，网上比较靠谱的一种说法是：重构（Refactoring）是指在不改变程序现有功能的基础上，通过调整程序的代码，改善程序的质量、性能、提高复用性、更易阅读。使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

或许有人会问，在项目开始时多花些时间把所有设计都做好不是更好吗，为什么要以后花时间来重构呢？没错，谁都想这么做，但是一个完美得可以预见未来任何变化的设计，又或者说一个灵活得可以兼容一切扩展和改变的设计几乎是不存在的。系统设计人员对即将着手的项目往往只能从大方向予以把控，而无法掌握控制每个细枝末节，其次是软件永远不变的就是变化，提出需求的用户往往会在软件成型后，才开始”品头论足”，因为设计人员毕竟不是先知先觉的神仙，所以功能的变化导致设计的调整再所难免。现在以”测试为先，持续重构”作为良好开发习惯被越来越多的人所采纳，测试和重构像黄河的护堤，成为保证软件质量的法宝。

现在我们看两个问题：在不改变功能的情况下，去改变系统的实现方式，为什么要这么做？投入的精力不都用来满足客户最关心的需求，而是仅仅改变了软件的实现方式，这又是否是在浪费客户的投资呢？

上述问题先不解答，我们带着问题思考一下。考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改，我们现在也时常遇到这种情况。为了实现变更，不可避免的要违反最初的设计构架。

经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越来越难维护，新的需求越来越难实现，软件的构架对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。

现在我们可以很好的去解释问题了，重构就可以最大限度的避免这样一种现象。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。

通过重构可以达到以下目标：持续纠错和改进软件设计。重构和设计是相辅相成的，它和设计彼此互补。当然有了重构，预先的设计仍然还是不可缺的，但不必是最优的设计，只需要一个合理的解决方案就够了，拥有大的方向，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。

最后介绍一本好书：重构 –改善既有代码的设计