代码重构之谈

何谓重构

• 重构是：
  • 为了是代码更易于维护和修改，在一系列小的、语义不变的代码转换（即是代码保持正常工作）中重组、重排代码。
• 重构不只是任意的调整
  • 代码必须仍能正常工作
  • 小步骤仅使语义被保留（即不是一个重大改写）
  • 单元测试来证明代码仍然有效
  • 代码是
    • 更松散的耦合性
    • 功能更聚集的模块
    • 更容易理解的
• 有很多人所共知的重构技术
  • 你至少应该在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