代码重构之谈

何谓重构

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