重构（Refactoring）就是通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

重构必要

一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。

考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。

这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越来越难维护，新的需求越来越难实现，软件的架构对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。

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

重构可以降低项目的耦合度，使项目更加模块化，有利于项目的开发效率和后期的维护。让项目主框架突出鲜明，给人一种思路清晰，一目了然的感觉，其实重构是对框架的一种维护。

重构目标

改进软件设计使软件更容易被理解

帮你找到bug

提高软件的开发速度

重构时机

在添加新功能时进行重构。

在修改bug时进行重构。

在代码复审时进行重构。

到了最后的交付期限，不进行重构

间接层

间接层的存在的价值：允许逻辑共享；分开解释意图和实现；将变化加以隔离；将条件逻辑加以编码

但是过多的间接层会导致代码的层次太深，使代码难以阅读.因此要权衡加入间接层的利弊.

重构难题

关系数据库与面向对象编程的问题——在对象模型和数据库模型之间插入一个分隔层，这就可以隔离两个模型各自的变化.升级某一模型时只需同时升级上述的分隔层即可.这样的分隔层会增加系统复杂度.但是能增加灵活度.

修改接口的问题——修改已发布的接口，因为已发布的接口会供外部人员（其它公司）使用，因此，修改接口会导致引用接口的其它程序不修改程序就无法运行.修改接口的最好的办法是增加一个新的接口，让旧接口调用新接口.这样原来的程序就不用修改了.对于接口的另一个建议是尽量不要发布接口.

重构与设计

重构与设计是互补的，程序应该是先设计，而在开始编码后,设计上的不足可以用重构来弥补.设计应该是适度的设计，而不必过度的设计.如果能很容易的通过重构来适应需求的变化，那么就不必过度的设计，当需求改变时再重构代码.

提高性能

提高性能的三种方法：

时间预算法——在设计时就对程序花费的时间进行预算，通常用于性能要求极高的实时系统.普通的企业应用程序一般对性能要求不高.只要不太慢就可以了.

持续关注法——要求程序员在任何时间都要设法保持系统的高性能.这个方法有个缺陷，就是大部分的程序90%的优化工作都是白费劲，这样会浪费大量的时间.

良好的分解方式——这个方式是在开发程序阶段不对性能投以任何关注，直到进入性能优化阶段，再分析程序中性能差的程序，然后对这些程序进分解，查出性能差的程序，进行优化.

重构的原因

臃肿的类: 类之所以会臃肿，是因为开发者缺乏对最基本的编码原则，即“单一职责原则”（SRP）的理解。这些类往往会变得很臃肿，是由于不同的且在功能上缺少关联的方法都放在了相同的类里面。

长方法: 方法之所以会变得很长主要是有以下几个原因：

许多没有关联性的、功能复杂的模块的代码都放在相同的方法内。这主要是开发者缺乏SRP的概念。

多种条件都放在同一个方法内，这在长方法内经常会发生的。这是由于缺乏McCabe代码复杂度和SRP的概念的比较。

大量的传参: 我经常遇到这几种情况，一些方法跟另一些方法进行交互，或者调用另一些方法的时候传入大量的参数。这就会出现如果更改了其中一个参数，就得在多个方法内进行更改。

常量值无处不在: 经常会发现开发者（尤其是新手）会使用一些具有明确含义的常量值（主要是魔鬼数字），但没有给它们赋予合适的常量变量。这会降低代码的可读性和可理解性。

模糊的方法名