《软件代码重构的时机.ppt》由会员分享，可在线阅读，更多相关《软件代码重构的时机.ppt（16页珍藏版）》请在金锄头文库上搜索。
1、软件代码重构的时机软件代码重构的时机软件代码重构的时机软件代码重构的时机07计科计科B5班班2007842525 王瑞杰王瑞杰2007842535 张沥之张沥之1软件代码重构软件代码重构2软件代码重构的驱动力软件代码重构的驱动力3代码重构的时机代码重构的时机4代码重构的实践方法代码重构的实践方法软件代码的重构软件代码的重构5结束语结束语软件代码的重构软件代码的重构“重构重构”诞生诞生: 重构重构( (refactoringrefactoring) )这个概念来自这个概念来自SmalltalkSmalltalk圈子圈子, ,没多久就进入了其他没多久就进入了其他语言阵营之中语言阵营之中. .由于重
2、构是由于重构是frameworkframework( (框架框架) )开发中不可缺少的一部分开发中不可缺少的一部分, ,所以所以frameworkframework开开发人员讨论自己的工作时发人员讨论自己的工作时, ,这个术语就诞生了这个术语就诞生了. .1概念概念:软件代码的重构软件代码的重构 软件代码的重构是指软件完成软件代码的重构是指软件完成代码编写和调试后代码编写和调试后, ,对代码进行重新对代码进行重新优化修订优化修订, ,并进而完善原有的设计和工作并进而完善原有的设计和工作. .动态的开发过程动态的开发过程软件代码重构的驱动力软件代码重构的驱动力软件技术本身在变化软件技术本身在变化
3、表现在表现在软件需求不断变化软件需求不断变化,人们人们很难一次将软件系统设计的很完很难一次将软件系统设计的很完美美,很有弹性很有弹性,以此来应对将来可以此来应对将来可能发生的任何改变能发生的任何改变,如果这样如果这样,那那将付出极大的成本代价将付出极大的成本代价.前不久完成的良好构架设计可能前不久完成的良好构架设计可能不适应新的技术要求不适应新的技术要求.所以要随之改变所以要随之改变,而软件人员对而软件人员对代码的修改有代码的修改有两种处理方法两种处理方法.2打补丁方法打补丁方法,而过多的补丁将造成软件代码结构臃肿而过多的补丁将造成软件代码结构臃肿,就就会产生一种会产生一种”代码坏味代码坏味”
4、的现象的现象.第一次进行更改时第一次进行更改时,进一步进一步预测预测今后的更改趋势今后的更改趋势,不失时不失时机的将系统的代码进行机的将系统的代码进行优化重构优化重构.修改代码的两种处理方法修改代码的两种处理方法临时的临时的,被动的被动的主动积极的主动积极的 软件项目管理界通过对各类型企业的各软件项目管理界通过对各类型企业的各类软件项目进行跟踪统计表明类软件项目进行跟踪统计表明, ,软件项目软件项目在规定的时间和给定的预算范围内在规定的时间和给定的预算范围内, ,完全满完全满足用户需求的软件项目足用户需求的软件项目( (成功的软件项目成功的软件项目) )所所占的比例大约只有占的比例大约只有28
5、%,28%,由此说明由此说明, ,软件项目软件项目普遍胜算不大普遍胜算不大, ,大量的软件项目超出预定的时大量的软件项目超出预定的时间计划和预算间计划和预算, ,这就是所谓的这就是所谓的软件项目失控软件项目失控。 代码重构的时机代码重构的时机3 Robert L. GlassRobert L. Glass在在“软件工程的事实与谬误软件工程的事实与谬误”一书中叙述了一书中叙述了造成造成软件项目失控软件项目失控的两个最主要的两个最主要原因原因是是糟糕的估算糟糕的估算和和不稳定的需求不稳定的需求. . 不稳定的需求不稳定的需求对软件项目成功威胁极大对软件项目成功威胁极大. .需要加以控制需要加以控制
6、, ,无论是无论是从管理上从管理上, ,还是技术上的都需要正确的纳入到项目管理的各领域范还是技术上的都需要正确的纳入到项目管理的各领域范畴中加以管理畴中加以管理. .软件项目失控软件项目失控一方面一方面, ,需求的变化会为企业带来新的商机。需求的变化会为企业带来新的商机。 另一方面另一方面, ,频繁的需求变化将给开发方和频繁的需求变化将给开发方和使用方都造成新的不稳定因素使用方都造成新的不稳定因素, ,对日常的商业对日常的商业 对软件对软件项目的需求项目的需求变化变化, ,人们人们应进行应进行全面全面正确地认识正确地认识。 软件项目的需求变化软件项目的需求变化 处理造成影响处理造成影响, ,因
7、此需求变化不可避免因此需求变化不可避免, ,但但应对需求的变化限制在可控的范围内应对需求的变化限制在可控的范围内, ,并通过技术手段进行规范管理并通过技术手段进行规范管理. .瀑布模型瀑布模型软件项目开发过程的模型软件项目开发过程的模型 迭代模型迭代模型人们在完成一定的需求分析后可以进行设计人们在完成一定的需求分析后可以进行设计, ,完成一定量的设计后完成一定量的设计后, ,进行编码和测试进行编码和测试, ,提供初提供初步版本的软件步版本的软件, ,经过试用和评估经过试用和评估, ,进行下一轮的进行下一轮的分析、设计、编码实现、提交新的软件版本分析、设计、编码实现、提交新的软件版本, ,如此反
8、复如此反复, ,逐步迭代完成最后的开发工作逐步迭代完成最后的开发工作, ,迭代迭代过程中如有需求改变过程中如有需求改变, ,应根据新的需求进行新应根据新的需求进行新的分析和设计的分析和设计. . 原因原因:迭代模型为何受欢迎迭代模型为何受欢迎帕累托法则帕累托法则, ,即即80/2080/20定理定理. . 整个软件需求分析工作中整个软件需求分析工作中, ,前面前面80%80%的需求分析工作只占的需求分析工作只占20%20%的时间的时间, ,最后最后的的20%20%工作量将耗用工作量将耗用80%80%需求分析时间需求分析时间, ,类类似的现象也存在于设计及编码过程中。似的现象也存在于设计及编码过
9、程中。?如果等到需求分析完全结束后,在进入设计阶段或者等到整个设计完成后再进行编码,项目的时间进度将会超期,也很容易造成分析瘫痪和设计瘫痪。由此可以看出,软件项目就应该在不完整的需求分析或不完整的设计中过渡到下一阶段,这也是软件开发所提倡的。由此带来的问题是,需求分析不完整,设计质量就受影响,设计不完整,代码质量就有隐患。Add you title一旦设计不十分完整,就进入编码实现阶段,确实会造成质量隐患,一旦有新的变化,代码更改就必须要进行,此时应该分析和评估本次修改究竟采用何种模式,当需求第一次改变将导致原有的设计发生腐化变味时,抓住这次机会去改进设计。避免打补丁的方式。既然在实际的项目中
10、,设计就是不完整的,代码就有改进的必要。另外,在系统维护阶段,人们也经常优化和修订代码,同时也可能改进现有的设计。这就是软件代码为什么要不断重构的原因。软件代码为什么要不断的重构软件代码为什么要不断的重构代码重构的实践方法代码重构的实践方法Martin Fowler的,重构改善既有代码设计中列举了一个例子,坏味道的现象,并分析了造成这种现象的一些原因重构的一个例子重构的一个例子重构的步骤重构的步骤重构实现的工具重构实现的工具结束语结束语软件代码重构是软件项目开发周期中必不可少的一个环节,重构方法属于实践性很强的技术,需要在实际项目中不断探索,本文只是简要介绍软件代码重构的动机和时机.2007842525 王瑞杰王瑞杰2007842535 张沥之张沥之
