首页 > 其他 > 详细

代码重构之谈

时间:2014-05-26 20:06:22      阅读:378      评论:0      收藏:0      [点我收藏+]

何谓重构

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

 

代码重构之谈,布布扣,bubuko.com

代码重构之谈

原文:http://www.cnblogs.com/lizhenghn/p/3751857.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!