`
fangang
  • 浏览: 877185 次
  • 性别: Icon_minigender_1
  • 来自: 北京
博客专栏
311c4c32-b171-3767-b974-d26acf661fb2
谈谈用例模型的那些事儿
浏览量:38661
767c50c5-189c-3525-a93f-5884d146ee78
一次迭代式开发的研究
浏览量:68822
03a3e133-6080-3bc8-a960-9d915ed9eabc
我们应当怎样做需求分析
浏览量:409987
753f3c56-c831-3add-ba41-b3b70d6d913f
重构,是这样干的
浏览量:91644
社区版块
存档分类
最新评论

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

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

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

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

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

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

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

大话重构连载首页:http://fangang.iteye.com/blog/2081995
特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢!
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics