摘要: 《大话重构》这本书是我写的第一本书,从今天起我将通过连载的形式逐渐跟大家分享。阅读全文
posted @ 2014-06-18 09:59 充满诗意的联盟 阅读(1211) 评论(3) 编辑
摘要: 很好,我们终于迈出了重构的第一步,而这第一步我们瞄准了代码问题的重灾区——超级大函数。超级大函数之所以是代码问题的重灾区,就是因为它们往往难于阅读、难于维护。面对大函数我们采取的办法是拆分,以功能为核心将其拆分成一个一个独立的函数。拆分后的程序变得易于阅读了,因为要读懂程序你不再需要读完所有代码,选择性的读取那些顶级函数,只需了了数行代码,你就可以明白整个程序。 但是,当我们将数千行的大函数分解成数十个小函数时,另一个问题出现了。想象一下,数十个函数被杂乱无章地堆放在一个对象中,看看就让人头疼。实际上,我们是不会这样做的。当我们开始了对大函数的分解时,随之而来的就是对大对象的分解。大对象,就是指的那些包含数十个甚至上百个方法或者函数,功能无所不包的超级对象。在很多遗留系统中,总有那么几个超级对象,系统几乎所有的功能都在它的里面有对应方法。这样的对象,密密麻麻的方法让人困惑,更关键的是,各种各样的功能被耦合在一起,稍有修改就会影响到许多功能,甚至让那些毫不相干的功能产生BUG。因此,我们应当合理地拆分我们的大对象。阅读全文
posted @ 2014-11-17 10:04 充满诗意的联盟 阅读(548) 评论(0) 编辑
摘要: 使用抽取方法,虽然道理十分简单,但实际操作起来却并不是那么容易的。完成抽取方法最大的困难,就是如何处理抽取函数与原函数的数据交换。如同将一颗大树从土壤里拔出来,盘根错节的根茎,那是剪不断理还乱。当代码还没有被抽取出来之前,它们与其它程序都是在一个函数的内部,因此各个代码段可以毫无顾忌地相互交互数据。但当我们将代码从原函数中抽取出来时,抽取出来的代码与原函数中的代码就形成了一道墙,要交换的数据只能通过参数与返回值进行交互,这将给我们带来诸多麻烦。阅读全文
posted @ 2014-11-02 19:42 充满诗意的联盟 阅读(443) 评论(0) 编辑
摘要: 说了那么多理论,我们来看看怎样使用抽取方法来重构遗留系统。如前所述,重构的过程首先是阅读程序代码,边阅读边整理程序。将功能相对独立的代码段放在一起,在前面加上注释。调整一些程序的顺序,将相关的代码尽量放在一起,但要保证程序执行的结果不会发生改变。比较典型的,将变量的定义与使用变量的代码放在一起。这个步骤比较实用,因为许多的遗留系统,其代码都有一个坏毛病,就是在程序开始时定义一大堆变量,但要弄清这些变量都用来做什么,却十分困难。边读边调整,将变量的定义逐渐迁移到使用它的代码段中,将大大提高代码可读性,你甚至会发现并简化一些变量。阅读全文
posted @ 2014-10-29 09:40 充满诗意的联盟 阅读(671) 评论(0) 编辑
摘要: 事情总是这样的:当我们对一个遗留系统一忍再忍,再忍,忍,还要忍……终于积攒到某一天,实在忍无可忍了,拍案而起,不能再忍了,重构!!!事情就这样发生了。然而,在这时你突然发现,重构的工作千头万绪,真不知从何开始。堆积如山的问题此起彼伏,期望修改的设计思绪万千。这里有个想法,那里有个思路,什么都想做,却什么都做不了,真是脑子里一团乱麻。这时候,没有一个合理的步骤,清晰的计划,瞎干蛮干是十分危险的,它会为你的重构带来不可预期的未来。无数次的经验告诉我,不论是什么系统,采用什么架构,从分解大函数开始,肯定没有错。阅读全文
posted @ 2014-10-18 22:05 充满诗意的联盟 阅读(572) 评论(2) 编辑
摘要: 第五次重构我们引入了数据库的设计,用户信息要从数据库中读取,问候语库存储在数据库中,并支持添加与更新。数据库的引入使自动化测试变得困难了,因为数据状态总是变化着的,而这种变化使得测试过程不能复现,这是我们不愿看到的。因此,我们在设计时将业务与数据库访问分离,形成了UserDao与GreetingRuleDao。此时,我们的设计应当遵从“依赖反转”原则,即将UserDao与GreetingRuleDao设计成接口,并编写它们的实现UserDaoImpl与GreetingRuleDaoImpl。这样设计就为我们Mock掉UserDao与GreetingRuleDao的实现类创造了条件。 这是我们的设计:阅读全文
posted @ 2014-09-21 13:10 充满诗意的联盟 阅读(612) 评论(0) 编辑
摘要: 说了那么多,让我们用示例看看,系统重构是应该怎样做自动化测试的。还是回到前面那个HelloWorld的例子(详见 3.3 小步快跑是这样玩的),该类中有一个sayHello()方法,只要我们输入当前的时间与用户名,就返回对该用户的问候语。如果当前时间是上午,则返回“Hi, XXX. Good morning!”;如果是下午,则返回“Hi, XXX. Good afternoon!”;如果是晚上,则返回“Hi, XXX. Good Night!”,这是HelloWorld这个程序实现的功能。 然后我们开始为这段程序编写测试代码阅读全文
posted @ 2014-09-18 01:21 充满诗意的联盟 阅读(1125) 评论(6) 编辑
摘要: 正如许多事情都有其两面性一样,测试方法也是这样。要保证测试方法正确,最简单、最直观地想法就是多写些测试用例,从更多地角度去测试,但这必然增加我们的测试成本。小步快跑要求我们频繁进行测试,假如我们重构的周期是20分钟,但测试却要花掉10分钟,那么这样的成本就实在太大了。假如这种测试还是开发人员手工测试,每天都有对同样的测试反复执行数十遍,那么开发人员估计就要疯掉了。 你可能立即就想到自动化测试了。是的,在许多重构的书籍中,大师们都建议我们在重构开始前,首先建立自动化测试机制。但遗憾的是,我经过多年的实践总结出来的经验是,这几乎不可能实现。阅读全文
posted @ 2014-09-09 11:07 充满诗意的联盟 阅读(755) 评论(2) 编辑
摘要: 通过前面的描述你已经对重构中“小步快跑”的开发模式有了一个清楚的认识。学会和习惯小步快跑的开发模式,对于重构工作极其重要,因为它让这种大范围、大幅度修改代码的重构工作变得不再像以往那样让人胆战心惊。究其原因,虽然从结果上是在大范围、大幅度调整,但每一步却是小范围、小福度调整,并且能保证每一步都是正确的。 然而,这里有一个非常重要的假设条件,那就是“保证每一步都是正确的”,这是怎么保证的呢?就这个问题,我们需要展开来认真讨论讨论。阅读全文
posted @ 2014-09-08 07:15 充满诗意的联盟 阅读(534) 评论(0) 编辑
摘要: 说了那么多,相信你对小步快跑的概念有了一个初步的印象,但理解还不是很深。让我们来看一看一个实际工作中的例子,来亲身感受一下什么是大布局,什么是大设计,什么是小设计。 还是回到前面那个Hello World的例子,起初的需求总是简单而清晰的。当用户登录一个网站时,网站往往需要给用户打一个招呼:“hi, XXX! ”。同时,如果此时是上午则显示“Good morning! ”,如果是下午则显示“Good afternoon! ”,除此显示“Good night! ”。对于这样一个需求我们在一个HelloWorld类中写了十来行代码:阅读全文
posted @ 2014-08-26 11:00 充满诗意的联盟 阅读(635) 评论(5) 编辑
摘要: 开车的朋友一定深有体会,驾驶汽车其实就是在不断矫正汽车行驶方向的一个过程。在整个驾驶过程中,你必须全神贯注地紧盯前方,通过方向盘不断矫正方向,否则即使行驶在直线路段也可能偏离车道。那些疲劳驾驶的司机,因为进入睡眠状态,无法再矫正方向,车辆就会越来越偏离航向。这种情况下,即使数秒钟的小盹,也能造成车毁人亡的严重后果。 重构与驾车虽然属于完全不同的领域,但其道理是相同的。阅读全文
posted @ 2014-08-10 14:58 充满诗意的联盟 阅读(502) 评论(2) 编辑