开车的朋友一定深有体会,驾驶汽车其实就是在不断矫正汽车行驶方向的一个过程。在整个驾驶过程中,你必须全神贯注地紧盯前方,通过方向盘不断矫正方向,否则即使行驶在直线路段也可能偏离车道。那些疲劳驾驶的司机,因为进入睡眠状态,无法再矫正方向,车辆就会越来越偏离航向。这种情况下,即使数秒钟的小盹,也能造成车毁人亡的严重后果。
重构与驾车虽然属于完全不同的领域,但其道理是相同的。我们在运用重构方法修改代码的过程中也是经常会犯错的(是人就会犯错)。犯错就如同偏离了航向一样,因此我们需要不断去矫正。既然是矫正,就必须有一个正确的标准,以及判断是否正确的方法。驾车过程中正确的标准是车辆是否正确行驶在自己的车道上,判断是否正确的方法则是司机朋友的目测。同样地,重构过程中正确的标准是我们的软件是否保持重构前的外部行为,判断的方法则是测试,不论是手工测试还是自动化测试。
说起来这个道理很简单,但问题是你不可能随时都在测试,随时都在矫正,这是不可能的。因此,我们必须要有一个周期,即间隔多长时间测试并矫正一次。周期越长,出大问题的几率就越大,就如同那个睡着了的司机;周期越短,我们所需要付出的成本就越高,因为每进行一次测试都是需要我们付出成本的。周期的长短是需要我们去不断权衡的。
然而,与驾车不同,重构的测试周期还要取决于完成一次重构并提交代码的周期。因为软件重构总是这样一个过程,首先修改一部分代码,使程序处于一个错误而无法编译运行的状态,然后完全其它所有相关代码的修改,使程序恢复编译可运行的状态。在这个中间状态中,我们是无法测试的,或者说测试是无意义的。只有当相关代码都修改完成,程序恢复到可运行状态时,测试才变得有意义。每完成这样一个过程,我们称之为“完成一次重构”。而完成一次重构所花费的时间,是决定我们测试周期的关键因素。
既然如此,我们完成一次重构到底要花费多少时间呢?这听起来像是在进行数学推导,但其中的道理就是这样。决定一次重构花费的时间,是由我们的设计决定的。小设计,我们对代码的修改量少,我们完成重构的时间就短;大设计,我们对代码的修改量大,我们完成重构的时间必然长。完成重构时间长,测试的周期就长,我们发现错误的时间就晚,可能给我们造成的损失必然就大。
大布局为什么我们伤不起?漫长的业务整理,漫长的设计与开发,持续数月之久。在这数月中我们一直都无法评估自己是否正确。当我们辛苦数月之后才被告知我们犯错了,一切都为时已晚,项目不得不滑入了失败的深渊。这就是前面那个故事系统改造失败的根本原因。
我们说,大布局不可以,但大设计同样不可能。我开始要重构了,我们思考了很多问题,运用了很多重构手法,来完成一次重构。这样的重构,代码修改量必然多,重构周期必然长,出错的风险就大。因此,我们的重构应当是一个一个的小设计。运用一个重构手法,解决一个问题,完成一次重构,测试通过,再运用一个重构手法,解决另一个问题,完成另一次重构……如此往复,这就是我在前面所说的“小步快跑”的开发模式。
但是一个我必须要澄清的概念就是,判断是否是大设计的衡量标准并不是代码行数。举一个简单例子,我们将一段上千行的代码从一个函数,原封不动地挪到另一个函数中,而这段代码本身改动很小,这属不属于大设计呢?显然不属于,因为我们真正修改的代码量不多。后面我们将看到,重构过程会经常进行这种代码的搬移。
小步快跑让我们每次重构的时候只关注一个问题,运用一个重构手法去解决这一个问题。这样就使我们每次在修改问题时不会想得太多太远。但是,小步快跑并不是要我们完全没有远期规划,不是这样的。你可以有远期规划,但这种规划不要做得太早,过早做出这些规划往往容易顾此失彼。先工作一段时间,做一些基础的工作,让我们对系统的整体有了一个比较全面地认识,然后再规划,这样将得到更好的效果。
同时,它要求我们对远期的规划不要过细。越近期的计划越细,越远期的规划越粗。一些人之所以急急匆匆地去做细致的远期规划,是因为担心今天做出来的东西,到了今后发现不对,得改,所以今天多想想,多规划一些。但问题是,今天规划的就正确吗?如果是当然很好,而现实常常是否。不正确的规划却常常适得其反,让我们陷入一种困境,一种既不能解决当前问题,又不得不为错误设计埋单的困境之中。因此重构的思想却完全打破了这种思维习惯。重构不惧怕修改,因为它让明天的代码修改是安全的,而不再是走钢丝。它认为,今天的任务就是改今天的,即使到了明天会被认为是错误的,也是明天再改去。
大话重构连载首页:
http://fangang.iteye.com/blog/2081995
特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢!
- 大小: 39.2 KB
分享到:
相关推荐
Android之大话设计模式——:抽象工厂模式借鉴.pdf
Android之大话设计模式——:抽象工厂模式参考.pdf
大话Oracle RAC:集群、高可用性、备份与恢复(带目录清晰中文完整版)
大话Oracle RAC:集群、高可用性、备份与恢复。 此书被认为不可多得的好资料之一:大话Oracle RAC(PDF经典),看完之后深有感触,发出来共享一下。
初中语文文摘历史“大话王”郭台铭:被夏普狠狠摔了个大跟
目前国内阐述网络存储的书籍少之又少,大部分是国外作品,对存储系统底层细节的描述不够深入,加之术语太多,初学者很难真正理解网络存储的精髓。《大话存储2:存储系统架构与底层原理极限剖析》以特立独行的行文风格...
《大话Oracle RAC:集群 高可用性 备份与恢复》以Oracle 10g为基础,对Oracle RAC进行了全面的介绍和分析。全书分为两个部分,共14章,第1部分是集群理论篇,这部分从集群基础知识入手,通过分析集群环境和单机环境...
大话产品:小公司产品别自卑,大公司产品别自负.docx
大话Oracle.RAC:集群、高可用性、备份与恢复(第2版)
《大话设计模式》对各种设计模式,做简要归纳(原创)
Android之大话设计模式:抽象工厂模式终稿.pdf
一个无比严谨的技术痴迷者创作的一本饱含诚意与想象力的经典存储著作。
大话存储:存储系统底层架构原理极限剖析(终极版)第3部分 大话存储:存储系统底层架构原理极限剖析(终极版)第3部分大话存储:存储系统底层架构原理极限剖析(终极版)第3部分
大话Java:从零基础到数据库、Web开发以漫画的形式,由浅入深、循序渐进地介绍Java编程的常用技术和方法,内容涵盖了Java基本语法结构、面向对象特征、集合框架体系、异常处理、GUI编程、MySQL数据库、JDBC数据库...
树懒自己整理的大话设计模式的修行笔记,对程序设计有很大的帮助,主要是以自己学习的习惯整理的!
android之大话设计模式.pdf
特别提醒:本文件为《大话数据分析:Tableau数据可视化实战》的数据集,并不是PDF书籍。
设计模式参考《大话设计模式》 工厂简单模式 创造型模式 工厂方法模式 抽象工厂模式 原型模式 建造者模式 单例模式 结构型模式 队列模式 桥接模式 组合模式 装饰模式 外观模式 享元模式 代理模式 行为模式(类行为...
大话存储2:存储系统架构与底层原理极限剖析.docx