大话重构连载4:大布局与小步快跑

以往我们在重新设计一个系统时,总是喜欢大布局。全面地整理系统需求,全面地分析系统功能,再全面地设计系统、开发、测试。这样一个过程往往会持续数月,花费大量的工作量。但是,不到最后设计出来,谁都不知道会不会存在问题。这就是“大布局”的弊病。

正因为如此,软件大师在讲述系统重构时总是强调,系统重构应当避免大设计,而应当尽量采用一个一个连续不断的小设计。这就是我们所说的“小步快跑”的设计模式。

小步快跑体现出了敏捷软件开发的特点——简单与快速反馈。不要想得太多了,活在今天的格子里,因为你永远不可能预知今后会发生什么。所以,做今天的设计,解决今天的问题,完成今天的重构,让明天见鬼去吧。要知道,简单对于我们是多么的重要。当我们的大脑开始思考各种复杂的问题时,就开始充血,然后就是梦游,最后的结果就是顾此失彼。既然如此,我们为何不选择一种更加简单的生活方式呢?

非常遗憾的是,很多时候我们不能选择这种简单的生活方式,因为我们害怕明天,害怕明天会出现那些我们处理不了的业务场景,因此我们开始过度设计。我不是批判我们不应当有预见,预见性设计与过度设计往往就是一线之隔。有限的预见是可以的,但不要想得过于遥远。当明天真的需求变更了,我们现在的设计不能满足了,怎么办呢?没什么大不了的,因为我们有重构。通过安全而平稳的重构方法先重构我们的系统,使之可以应付那个需求,然后再添加代码,实现新需求。这个过程被称为“两顶帽子”:一顶是只重构而不新增功能,一顶是增加新的功能实现新需求。正因为如此,我们在设计时思考当下就可以了。

另外一个问题就是及时反馈,落实到此地就是及时测试。只有测试通过了,此次重构才算成功,我们才能继续往下重构,否则我们必须还原。从这里我们不难看出,重构的周期是多么的重要。在我以往的重构工作中,一次重构的周期也就在10分钟到1小时。重构的周期越长,说明你考虑的问题越复杂,最终出错的概率也就越大。所以,我们一定要习惯“小步快跑”的工作方式,让自己只活在当下。

说了那么多重构,相信一定有一个疑问开始在你脑中萦绕。既然系统重构对于客户来说是透明的,客户完全感觉不到它的存在,毫无疑问,它对于客户来说就是毫无价值的。这下疑问就来了:既然重构对于客户来说就是毫无价值的,我们做它还有什么意义呢?要说明白这个问题,我们需要首先谈一谈软件修改的四种动机。

大话重构连载首页:http://www.cnblogs.com/mooodo/p/talkAboutRefactoringHome.html

特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢!

大话重构连载4:大布局与小步快跑,布布扣,bubuko.com

时间: 2024-10-14 01:30:53

大话重构连载4:大布局与小步快跑的相关文章

大话重构4:大布局与小步快跑

以往我们在重新设计一个系统时,总是喜欢大布局.全面地整理系统需求,全面地分析系统功能,再全面地设计系统.开发.测试.这样一个过程往往会持续数月,花费大量的工作量.但是,不到最后设计出来,谁都不知道会不会存在问题.这就是"大布局"的弊病. 正因为如此,软件大师在讲述系统重构时总是强调,系统重构应当避免大设计,而应当尽量采用一个一个连续不断的小设计.这就是我们所说的"小步快跑"的设计模式. 小步快跑体现出了敏捷软件开发的特点--简单与快速反馈.不要想得太多了,活在今天的

大话重构连载首页

<大话重构>这本书是我写的第一本书,从今天起我将通过连载的形式逐渐跟大家分享. 这本书让你: 告别游击队转变为正规军. 远离劣质代码走向精妙设计 真正明确专业级的软件开发是如何的 真正明确重构是如何一步一步进行的 高效重构七步曲.面对实践不卡壳 让遗留系统维护不再是你的梦魇 读完这本书以后: 需求变更不再纠结.重构让你润物细无声地容纳它们 超越代码级的重构,从各个层面深度领略重构之美 自己主动化測试不再是梦想.重构让自己主动化測试走你 又一次审视熟悉而陌生的技术.将碎了一地的它们又一次铆合在一

大话重构连载9:大布局你伤不起

作为优秀开发人员,重构应当成为一种习惯,自然而然地运用重构的开发模式,自然而然地在优化和调整我们的代码.它首先要求我们掌握重构的开发模式,就是"小步快跑"的开发模式,运用"两顶帽子"的设计顺序,去开发我们的程序.但作为重构初学者来说,这并不容易,即使你已经从业很多年. 所谓改变一种习惯,就好像习惯了左手吃饭的人,突然被要求改成右手,你必然会感到许多的不适.首先的不适是一种心理上的障碍,即如何能迈出重构代码的第一步,这需要一种决心.初次尝试重构的开发人员总是要经历一段

大话重构连载10:小设计而不是大布局

开车的朋友一定深有体会,驾驶汽车其实就是在不断矫正汽车行驶方向的一个过程.在整个驾驶过程中,你必须全神贯注地紧盯前方,通过方向盘不断矫正方向,否则即使行驶在直线路段也可能偏离车道.那些疲劳驾驶的司机,因为进入睡眠状态,无法再矫正方向,车辆就会越来越偏离航向.这种情况下,即使数秒钟的小盹,也能造成车毁人亡的严重后果. 重构与驾车虽然属于完全不同的领域,但其道理是相同的.我们在运用重构方法修改代码的过程中也是经常会犯错的(是人就会犯错).犯错就如同偏离了航向一样,因此我们需要不断去矫正.既然是矫正,

大话重构连载11:小步快跑是这样玩的

说了那么多.相信你对小步快跑的概念有了一个初步的印象,但理解还不是非常深.让我们来看一看一个实际工作中的样例,来亲身感受一下什么是大布局,什么是大设计.什么是小设计. 还是回到前面那个HelloWorld的样例,起初的需求总是简单而清晰的. 当用户登录一个站点时,站点往往须要给用户打一个招呼:"hi, XXX! ".同一时候,假设此时是上午则显示"Good morning! ",假设是下午则显示"Good afternoon! ",除此显示&qu

大话重构连载16:超级大函数

事情总是这样的:当我们对一个遗留系统一忍再忍,再忍,忍,还要忍--终于积攒到某一天,实在忍无可忍了,拍案而起,不能再忍了,重构!!!事情就这样发生了.然而,在这时你突然发现,重构的工作千头万绪,真不知从何开始.堆积如山的问题此起彼伏,期望修改的设计思绪万千.这里有个想法,那里有个思路,什么都想做,却什么都做不了,真是脑子里一团乱麻.这时候,没有一个合理的步骤,清晰的计划,瞎干蛮干是十分危险的,它会为你的重构带来不可预期的未来.无数次的经验告诉我,不论是什么系统,采用什么架构,从分解大函数开始,肯

大话重构连载19:大对象的演化过程

很好,我们终于迈出了重构的第一步,而这第一步我们瞄准了代码问题的重灾区——超级大函数.超级大函数之所以是代码问题的重灾区,就是因为它们往往难于阅读.难于维护.面对大函数我们采取的办法是拆分,以功能为核心将其拆分成一个一个独立的函数.拆分后的程序变得易于阅读了,因为要读懂程序你不再需要读完所有代码,选择性的读取那些顶级函数,只需了了数行代码,你就可以明白整个程序. 但是,当我们将数千行的大函数分解成数十个小函数时,另一个问题出现了.想象一下,数十个函数被杂乱无章地堆放在一个对象中,看看就让人头疼.

大话重构连载12:你不能没有保险索

通过前面的描述你已经对重构中"小步快跑"的开发模式有了一个清楚的认识.学会和习惯小步快跑的开发模式,对于重构工作极其重要,因为它让这种大范围.大幅度修改代码的重构工作变得不再像以往那样让人胆战心惊.究其原因,虽然从结果上是在大范围.大幅度调整,但每一步却是小范围.小福度调整,并且能保证每一步都是正确的. 然而,这里有一个非常重要的假设条件,那就是"保证每一步都是正确的",这是怎么保证的呢?就这个问题,我们需要展开来认真讨论讨论. 毫无疑问,系统重构就其结果来看,是在

大话重构连载2:什么是系统重构

当我们开始系统重构的时候,不是着手去修改代码,而是首先建立测试机制.不论什么程序,只要是被我们修改了,理论上就可能引入BUG,因此我们就必须要进行测试.既然是测试就必须要有一个正确与否的评判标准.以往的测试,其评判的标准就是是否满足业务需求.因此,测试人员往往总是拿着需求文档测试系统. 与以往的代码修改不同,重构没有引入任何新的需求,系统原来什么功能,重构以后还是这些功能.因此,重构的测试标准就只有一个,就是与之前的功能完全保持一致,仅此而已. 然而在许多经典的重构书籍中,大师们总是建议我们首先