软件代码重构的时机46.pptVIP

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