软件代码重构的时机.ppt

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