首页    技术博客    PHP教程    数据库技术    前端开发   HTML5    Nginx    php论坛
新用户注册 | 会员登录
加入会员，解锁专属内容
取消
热门标签 | HotTags
当前位置:  开发笔记 > 程序员 > 正文

对重构的理解

作者：beng83790si | 来源：互联网 | 2023-07-15 20:35
什么是重构重构，用最简单的一句话说：就是要在不改变系统功能的情况下，对系统的内部结构进行重新调整。重构的最直接目的在于改进软件系统的内部架
什么是重构



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



为什么要重构



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




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




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




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




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




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



拒绝变化 VS 拥抱变化



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









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




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









说明一下&＃xff1a;


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




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




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




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




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




保持兼容性



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




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




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




因此&＃xff0c;修改一个过程是非常困难的&＃xff0c;通常升级一个面向过程的系统&＃xff0c;可以采用两种方式&＃xff1a;


1、写新的过程&＃xff1b;


2、在原有的过程上加开关参数。




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




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




判断一个接口升级后是否保持兼容性就是一件比较容易的事情了。我们可以判断接口的输入输出是否符合下面两条规则&＃xff1a;


1、升级后的输入是升级前的输入的超级&＃xff1b;


2、升级后的输出是升级前的输出的子集。




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




在重构的过程中&＃xff0c;自动化的单元测试是非常好的保障。采用自动化的单元测试&＃xff0c;不断运行测试&＃xff0c;可以保证系统的结构改变的过程中&＃xff0c;业务行为不发生改变。

推荐阅读
author-avatar
beng83790si
这个家伙很懒，什么也没留下！
Tags | 热门标签
RankList | 热门文章
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有