何谓重构
- 重构是：
- 为了是代码更易于维护和修改，在一系列小的、语义不变的代码转换（即是代码保持正常工作）中重组、重排代码。
- 重构不只是任意的调整
- 代码必须仍能正常工作
- 小步骤仅使语义被保留（即不是一个重大改写）
- 单元测试来证明代码仍然有效
- 代码是
- 更松散的耦合性
- 功能更聚集的模块
- 更容易理解的
- 有很多人所共知的重构技术
- 你至少应该在Do yourself之前，多多少少熟悉一些
- 设计重构“条款”
何时重构
- 你应该重构：
- 当你看到一个更好的方式来来做同一件事的任何时候
- “更好”意味着使代码在将来更易于理解和修改
- 只要不破坏现有代码你都可以这样做
- 注意此时的单元测试很重要
- 当你看到一个更好的方式来来做同一件事的任何时候
- 你不应该重构：
- 并不需要修改的稳定代码，
- 别人的代码
- 除非对方同意，或它属于你
- 在敏捷开发中这不是问题，因为代码都是公共的
重构环境
- 传统的软件工程之后仿照传统
- 工程实践（= 先设计，然后写代码）
- 假设：
- 预期的最终产品可提前确定
- 给定类型（水管工，电工等）的工人是可以互换的
- 敏捷软件开发是基于不同的假设：
- 随着用户对软件的认知，需求（也有设计）不断变化
- 程序员是具有不同技能和知识的专业人士
- 程序员位于作出设计决策的最佳位置
- 重构是敏捷开发的基石
- 当发现设计有缺陷时，传统工程也是需要重构的
重构起源何处
- Ward Cunningham和Kent Beck，Smalltalk里有影响力的专家
- Kent Beck，极限编程的领导者
- Ralph Johnson，伊利诺伊大学教授，“Gang of Four”之一
- Bill Opdyke，Ralph的博士生
- Martin Fowler，http://www.refactoring.com/
- 重构：改善现有代码的设计
再谈重构
- 何时你应该重构
- 任何时候，只要你发现可以改进现有代码的设计
- 当你在代码中发现了“坏味道”（有迹象表明有些什么东西是错误的）
- 何时你可以重构
- 你应该在一个有利的环境中（敏捷开发团队，或做你自己的工作）
- 你熟悉常用的重构技巧
- 有帮助的重构工具
- 你应该有足够的单元测试集
重构过程
- 做一个小变化
- 一个单一的重构
- 运行所有的测试，以确保一切仍然工作
- 如果一切正常，就进行下一个重构
- 如果没有，修正问题，或撤消更改， 这样才能保证始终有一个能正常工作的系统
代码的味道
- 如果太臭，改变它
- 代码可以使设计更加难以改变
- 比如：
- 重复的代码
- 长方法
- 巨类
- 巨大的switch语句
- 长的级联调用（例如：a.b().c().d()）
- 大量的检查null对象
- 数据簇（例如，一个联系人Contact类有地址、电话、Email属性等）—类似于关系设计中非规范化的表
- 数据类（主要有字段/属性，很少甚至没有方法）
- 未封装的数据字段（public的成员变量）
本文翻译自： http://www.math.uaa.alaska.edu/~afkjm/csce401/handouts/refactoring.pdf