系统重构

系统重构
什么是重构
重构，用最简单的一句话说：就是要在不改变系统功能的情况下，对系统的内部结构进行重新调整。

重构的最直接目的在于改进软件系统的内部架构。

一个好的结构可以更加适应于需求的变化，更好的满足客户的需求，最大限度的延长软件系统的生命周期。

为什么要重构
在不改变系统功能的情况下，改变系统的实现方式。

为什么要这么做？投入精力不用来满足客户关心的需求，而是仅仅改变了软件的实现方式，这是否是在浪费客户的投资呢？
重构的重要性要从软件的生命周期说起。

软件不同与普通的产品，他是一种智力产品，没有具体的物理形态。

一个软件不可能发生物理损耗，界面上的按钮永远不会因为按动次数太多而发生接触不良。

那么为什么一个软件制造出来以后，却不能永远使用下去呢？
对软件的生命造成威胁的因素只有一个：需求的变更。

一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。

有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。

在这种情况下，软件必须相应的改变。

考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。

但是总的说来，软件要适应需求的变化，以保持自己的生命力。

这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。

但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。

为了实现变更，不可避免的要违反最初的设计构架。

经过一段时间以后，软件的架构就千疮百孔了。

bug越来越多，越来越难维护，新的需求越来越难实现，软件的构架对新的需求渐渐的失去支持能力，而是成为一种制约。

最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。

重构就能够最大限度的避免这样一种现象。

系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。

通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。

拒绝变化VS 拥抱变化
按照传统的软件设计方式，软件的生产分为需求调查、概要设计、详细设计、编码、单体测试、联合测试、现场部署几个阶段。

虽说这几个阶段是可以互相渗透，但是总的来说是有一定次序的，前一个阶段的工作是后一个阶段工作的基础。

这就向下面这样一种
V形的模式：
往下的方向将系统进行分解，往上的方向将系统进行整合。

这样的开发形式将软件开发分为设计前和设计后两个阶段，开发过程中存在一个重要的“里程碑”——设计说明书的。

在设计说明书完成前，工程处于“设计”阶段，而在设计说明书完成之后，工程则进入“实施”阶段。

一旦到了实施阶段，任何需求或者设计上的变更都是非常困难的，需要花费大量的成本。

通常为了保证工程的顺利实施，开发人员常有这样一种冲动：按住客户的手，在需求说明书上签字。

并且告诉客户：“从今天开始，任何需求变更都要停止，直到我们把现在这个东西做完。

”这是一种拒绝变化的开发方式。

软件系统要保持与企业的目标一致。

时代在发展，人们的要求在不断的提高，客户的业务在不断的发展。

在这种情况下，传统的先设计、再施工的V形式已经不能适应日益复杂的业务需要。

软件工程逐渐演化成下面这样的过程：
说明一下：
1、软件开发的目标要与企业目标保持一致，一个开发周期不宜时间过长，一般控制在半年到一年。

系统部署后，并不意味着开发工作结束了，而是进入了下一个周期。

2、工程以循环迭代的方式前进，这并不意味轻视了设计，不是要搞边调研、边设计、边施工的“三边”工程，相反，是更加重视设计的地位。

软件开发的全过程都需要设计，软件开发是“持续设计”的过程。

同时，设计工作也不只是简单过程分解、任务分配，而是概念设计、逻辑设计、物理设计等各个方面互相交织、齐头并进。

传统的软件开发方式使用一种非常理想化的流程——先与客户讨论项目的范围，确定哪些需要做，哪些不需要做，然后规划一个完美的设计，不仅可以满足现在的需求，还能很好的适应未来的需求，设计完成后开始编码，然后测试组装，送到现场安装调试运行。

这一系列过程就类似与发射一颗炮弹，首先要找到目标，然后根据地形、风力、目标的位置、移动速度等各种因素，计算提前量、炮弹发射的角度，计算出一个抛物线轨道，最后在合适的时间把炮弹发射出去。

这一切都符合最正确的物理定律，一切都听起来很理想。

如果没有意外条件，当然是可以击中目标的。

但是炮弹一旦发射出去，一切就失去了控制，任何环境的变化都会造成偏离目标。

尤其是对于一个运动的目标来说，计算过程十分复杂，很多情况下只能靠人估计。

对于不规则的运动目标只能碰碰运气。

这样的方式，命中率是很低的。

新的软件开发过程不追求完美的、长期的、理想的计划，更加重视实际情况，重视需求的变化，提倡采用短期的计划。

这是一种拥抱变化的过程。

就象是在炮弹上安装了一个反馈装置，锁定目标后，确保大方向的正确，然后就将炮弹发射出去。

炮弹在运行过程中不断的将目标位置偏移量输入反馈电路，根据反馈输出调整自己的运行路线，无限的逼近目标。

这样，炮弹就拥有了制导能力，命中率大大增加。

重构就可以增加工程的调整能力，他可以把产品回复到一个稳定的状态，可以基于这个状态达到下一个目标。

如此反复前进，更好的满足客户的需求。

保持兼容性
重构的目的在于改变系统的实现方式，而不改变原有的功能。

这个过程中，判断兼容性就十分的重要。

一个子系统、模块、类、函数是否与升级前保持兼容，如何判断这个兼容性，如何保持这个兼容性，这关系到重构的成本和重构的可能性。

程序员学习写程序代码时，会发现随着程序代码愈来愈多，许多的程序代码不断重复出现和被使用，因此很自然的开始使用例程、子程序或是过程、函数等机制帮助我们进行程序代码整理的工作。

于是很自然的，字体的分析方式演化成这个样子：将客户的需求过程进行分解，一步一步的分解，直到可以直接的实现他。

这就是面向过程的分析方式。

面向过程的分析方式对变化的能力是很弱的。

为什么呢？因为面向过程的分析方式很容易造成一种倾向——不区分行动的主体。

一个过程是没有主体的，他不是在为自己工作，而是在为“别人”工作。

当我们修改了一个过程之后，我们很难判断这个过程是否保持向后兼容，其他过程会不会受到影响。

因为这个过程对外界有意义的不仅是他的输入和输出，还包括每一步过程，每一步过程都可能含有一个非常隐讳的业务意义，对外界产生影响。

因此，修改一个过程是非常困难的，通常升级一个面向过程的系统，可以采用两种方式：
1、写新的过程；
2、在原有的过程上加开关参数。

除此以外的升级办法都很难保证原过程和新过程的兼容性，容易造成错误。

为了更好的保证升级后模块的兼容性，应该采用面向对象的分析方式。

按照这样的分析方式，一个对象为“自己”工作，他有完整的、独立的业务含义。

对象之间通过接口发生联系，一个对象对外界有影响的部分只有接口，至于他做什么、如何做、做的对不对，则不是外界需要关心的事情。

判断一个接口升级后是否保持兼容性就是一件比较容易的事情了。

我们可以判断接口的输入输出是否符合下面两条规则：
1、升级后的输入是升级前的输入的超级；
2、升级后的输出是升级前的输出的子集。

只要符合这两点，他就仍然可以在系统中运行，不会对其他对象造成危害。

在实际的工程中，判断这个兼容性有一个更好的办法：自动化的单元测试。

在重构的过程中，自动化的单元测试是非常好的保障。

采用自动化的单元测试，不断运行测试，可以保证系统的结构改变的过程中，业务行为不发生改变。