随笔-57  评论-12  文章-0  trackbacks-0
From: http://www.cnblogs.com/lane_cn/archive/2006/02/05/325782.html

什么是重构

重构,用最简单的一句话说:就是要在不改变系统功能的情况下,对系统的内部结构进行重新调整。重构的最直接目的在于改进软件系统的内部架构。一个好的结构可以更加适应于需求的变化,更好的满足客户的需求,最大限度的延长软件系统的生命周期。

为什么要重构

在不改变系统功能的情况下,改变系统的实现方式。为什么要这么做?投入精力不用来满足客户关心的需求,而是仅仅改变了软件的实现方式,这是否是在浪费客户的投资呢?

重构的重要性要从软件的生命周期说起。软件不同与普通的产品,他是一种智力产品,没有具体的物理形态。一个软件不可能发生物理损耗,界面上的按钮永远不会因为按动次数太多而发生接触不良。那么为什么一个软件制造出来以后,却不能永远使用下去呢?

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

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

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

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

拒绝变化 VS 拥抱变化

按照传统的软件设计方式,软件的生产分为需求调查、概要设计、详细设计、编码、单体测试、联合测试、现场部署几个阶段。虽说这几个阶段是可以互相渗透,但是总的来说是有一定次序的,前一个阶段的工作是后一个阶段工作的基础。这就向下面这样一种V形的模式:

vdevelope.GIF

往 下的方向将系统进行分解,往上的方向将系统进行整合。这样的开发形式将软件开发分为设计前和设计后两个阶段,开发过程中存在一个重要的“里程碑”——设计 说明书的。在设计说明书完成前,工程处于“设计”阶段,而在设计说明书完成之后,工程则进入“实施”阶段。一旦到了实施阶段,任何需求或者设计上的变更都 是非常困难的,需要花费大量的成本。通常为了保证工程的顺利实施,开发人员常有这样一种冲动:按住客户的手,在需求说明书上签字。并且告诉客户:“从今天 开始,任何需求变更都要停止,直到我们把现在这个东西做完。”这是一种拒绝变化的开发方式。

软件系统要保持与企业的目标一致。时代在发展,人们的要求在不断的提高,客户的业务在不断的发展。在这种情况下,传统的先设计、再施工的V形式已经不能适应日益复杂的业务需要。软件工程逐渐演化成下面这样的过程:

sdevelope.GIF

说明一下:
1、软件开发的目标要与企业目标保持一致,一个开发周期不宜时间过长,一般控制在半年到一年。系统部署后,并不意味着开发工作结束了,而是进入了下一个周期。

2、 工程以循环迭代的方式前进,这并不意味轻视了设计,不是要搞边调研、边设计、边施工的“三边”工程,相反,是更加重视设计的地位。软件开发的全过程都需要 设计,软件开发是“持续设计”的过程。同时,设计工作也不只是简单过程分解、任务分配,而是概念设计、逻辑设计、物理设计等各个方面互相交织、齐头并进。

传 统的软件开发方式使用一种非常理想化的流程——先与客户讨论项目的范围,确定哪些需要做,哪些不需要做,然后规划一个完美的设计,不仅可以满足现在的需 求,还能很好的适应未来的需求,设计完成后开始编码,然后测试组装,送到现场安装调试运行。这一系列过程就类似与发射一颗炮弹,首先要找到目标,然后根据 地形、风力、目标的位置、移动速度等各种因素,计算提前量、炮弹发射的角度,计算出一个抛物线轨道,最后在合适的时间把炮弹发射出去。这一切都符合最正确 的物理定律,一切都听起来很理想。如果没有意外条件,当然是可以击中目标的。但是炮弹一旦发射出去,一切就失去了控制,任何环境的变化都会造成偏离目标。 尤其是对于一个运动的目标来说,计算过程十分复杂,很多情况下只能靠人估计。对于不规则的运动目标只能碰碰运气。这样的方式,命中率是很低的。

新 的软件开发过程不追求完美的、长期的、理想的计划,更加重视实际情况,重视需求的变化,提倡采用短期的计划。这是一种拥抱变化的过程。就象是在炮弹上安装 了一个反馈装置,锁定目标后,确保大方向的正确,然后就将炮弹发射出去。炮弹在运行过程中不断的将目标位置偏移量输入反馈电路,根据反馈输出调整自己的运 行路线,无限的逼近目标。这样,炮弹就拥有了制导能力,命中率大大增加。

重构就可以增加工程的调整能力,他可以把产品回复到一个稳定的状态,可以基于这个状态达到下一个目标。如此反复前进,更好的满足客户的需求。

保持兼容性

重构的目的在于改变系统的实现方式,而不改变原有的功能。这个过程中,判断兼容性就十分的重要。一个子系统、模块、类、函数是否与升级前保持兼容,如何判断这个兼容性,如何保持这个兼容性,这关系到重构的成本和重构的可能性。

程 序员学习写程序代码时,会发现随着程序代码愈来愈多,许多的程序代码不断重复出现和被使用,因此很自然的开始使用例程、子程序或是过程、函数等机制帮助我 们进行程序代码整理的工作。于是很自然的,字体的分析方式演化成这个样子:将客户的需求过程进行分解,一步一步的分解,直到可以直接的实现他。这就是面向 过程的分析方式。

面向过程的分析方式对变化的能力是很弱的。为什么呢?因为面向过程的分析方式很容易造成一种倾向——不区分行动的主体。 一个过程是没有主体的,他不是在为自己工作,而是在为“别人”工作。当我们修改了一个过程之后,我们很难判断这个过程是否保持向后兼容,其他过程会不会受 到影响。因为这个过程对外界有意义的不仅是他的输入和输出,还包括每一步过程,每一步过程都可能含有一个非常隐讳的业务意义,对外界产生影响。

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

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

为了更好的保证升级后模块的兼容性,应该采用面向对象的分析方式。按照这样的分析方式,一个对象为“自己”工作,他有完整的、独立的业务含义。对象之间通过接口发生联系,一个对象对外界有影响的部分只有接口,至于他做什么、如何做、做的对不对,则不是外界需要关心的事情。

判断一个接口升级后是否保持兼容性就是一件比较容易的事情了。我们可以判断接口的输入输出是否符合下面两条规则:
1、升级后的输入是升级前的输入的超级;
2、升级后的输出是升级前的输出的子集。

只要符合这两点,他就仍然可以在系统中运行,不会对其他对象造成危害。在实际的工程中,判断这个兼容性有一个更好的办法:自动化的单元测试

在重构的过程中,自动化的单元测试是非常好的保障。采用自动化的单元测试,不断运行测试,可以保证系统的结构改变的过程中,业务行为不发生改变。
posted on 2006-04-27 19:32 Martin 阅读(1583) 评论(0)  编辑 收藏 引用 所属分类: Design Patterns
只有注册用户登录后才能发表评论。