敏捷软件开发ASD-06-重构原理与动机.pptVIP

重构 Refactoring 内容 什么是重构 代码中的坏味道 1 重构的基本思想 1.1 什么是重构(Refactoring) ？ Refactoring是对已经完成的代码进行改进的过程。在不对代码的外部行为进行改动的情况下，对代码内部的结构进行优化。 Refactoring是严谨地对完成的代码进行清理的从而减少出错的一种方法。 Refactoring的实质是对完成代码的设计进行改进。 Refactoring是Test-Driven Design and Development的根本保证。 1.2 重构背后 重构定义的解析 从现有代码入手，让它变得更好 在保持原有语义的前提下，优化程序的内部结构 这个思想可以使用非常重要的手段改善代码结构，如： 减少几乎重复的代码 降低对象之间的内聚，松散对象间的耦合程度 改善可理解性、可维护性、灵活性、效率等等 1.3 为什么要重构? 改进软件的设计 提高代码质量，可维护性 Refactoring帮助尽早的发现缺陷 Refactoring可以提高提高开发速度 1.4 重构思想 重构思想和编程思想一样的历史 编程调试的时候经常会有优化代码的念头和行为 受到某种诱导、为了解释、产生变化等等 如， Extract interface, Move method, Pull up constructor body 重构通常成对出现 对于一种模式的选择通常是两难的 如，通过代理替换继承，通过继承替换代理 1.5 重构的内容 20 种坏味道(bad smells) 程序员自己去发现 坏味道不会影响系统正常运转 坏味道不是缺陷，只是容易引入维护缺陷 72 种重构方法 发现坏味道的处理方法 去除一种坏味道通常需要多种方法 1.6 Fowler的忠告 什么时候应该重构？多久进行一次？每次要花多长时间？ 没有固定周期 不是说，每半年一次，一次花两周 可以一边开发一边作 遇到一个警告(a “bad smell”) 增加一个函数 修复一个bug 代码审查 1.7 编码的三原则 (XP) 首先为完成任务而编码，仅仅如此！ 然后使用一样的思想编码，可能是因为期限，也可能是偷懒，也可能是畏缩，没有关系，继续编码。 如果用同样的想法进行了第三次编码，这个时候应该重构了！ 任何的编码结构都可以再抽象，但是实在不是一件好事情 追求完美是要付出代价的！ 只需要刚够的抽象就可以了！ 1.8 什么时候不要重构？ 代码太混乱，设计完全错误 与其重构，不如重新开始。 明天是最后期限 永远不要做“最后一分钟的改变”。推迟重构，但不可以忽略，即使形成产品的代码都正确的运行。 重构工作显著地影响软件估算 一个任务估计要３天，如果为了重构，需要更多的时间（ ２天或更多），那么推迟重构。可以把这个重构作为一个新的任务，或者安排在下一次的迭代中完成。 2 代码中的坏味道 Bad smells in code 坏味道的初步分类 3 重复 重复代码 如果你选择一段代码，复制，移动光标，粘贴，重复代码就出现了 不同接口的备选类 3.1 重复代码(Duplicated code) 一号坏味道 同一个类中的两个方法是否有类似甚至一样的表达式？ 使用了一个私有辅助例程，将类似代码归集起来 (Extract method) 在相关类中有相同代码？ 将公共的代码放到最近的共有祖先中，并用参数表示 对于子任务的变种使用 template method 设计模式 (Form template method) 重复代码(Duplicated code) 两个不相关类中有相同代码？ 它们应该相关吗？引入抽象父类 (Extract class, Pull up method) 这些代码真的仅仅出现在一个类中吗？为这些类实现一个其他的类作为客户(Extract method) 可以将公共代码分离到一个子部分、函数或者其它函数对象吗？Replace method with method object 重复代码的示例 3.2 不同接口的备选类(Alternative classes with different interfaces) 不相关的类/对象实现了相同或者相似抽象的 解决方案： 将两个类移得近一些 寻找一个公共的接口 寻找一个公共的子部分，然后删去它。 Extract [super]class, move method/field, rename method ”不同接口的备选类“的示例 package com.fubar.log; public final class Log { public int INFO=1, WARN=2, ERROR=3, FATAL=4; public static void setLog(File f) {...} pu