以往我们在重新设计一个系统时,总是喜欢大布局。全面地整理系统需求,全面地分析系统功能,再全面地设计系统、开发、测试。这样一个过程往往会持续数月,花费大量的工作量。但是,不到最后设计出来,谁都不知道会不会存在问题。这就是“大布局”的弊病。
正因为如此,软件大师在讲述系统重构时总是强调,系统重构应当避免大设计,而应当尽量采用一个一个连续不断的小设计。这就是我们所说的“小步快跑”的设计模式。
小步快跑体现出了敏捷软件开发的特点——简单与快速反馈。不要想得太多了,活在今天的格子里,因为你永远不可能预知今后会发生什么。所以,做今天的设计,解决今天的问题,完成今天的重构,让明天见鬼去吧。要知道,简单对于我们是多么的重要。当我们的大脑开始思考各种复杂的问题时,就开始充血,然后就是梦游,最后的结果就是顾此失彼。既然如此,我们为何不选择一种更加简单的生活方式呢?
非常遗憾的是,很多时候我们不能选择这种简单的生活方式,因为我们害怕明天,害怕明天会出现那些我们处理不了的业务场景,因此我们开始过度设计。我不是批判我们不应当有预见,预见性设计与过度设计往往就是一线之隔。有限的预见是可以的,但不要想得过于遥远。当明天真的需求变更了,我们现在的设计不能满足了,怎么办呢?没什么大不了的,因为我们有重构。通过安全而平稳的重构方法先重构我们的系统,使之可以应付那个需求,然后再添加代码,实现新需求。这个过程被称为“两顶帽子”:一顶是只重构而不新增功能,一顶是增加新的功能实现新需求。正因为如此,我们在设计时思考当下就可以了。
另外一个问题就是及时反馈,落实到此地就是及时测试。只有测试通过了,此次重构才算成功,我们才能继续往下重构,否则我们必须还原。从这里我们不难看出,重构的周期是多么的重要。在我以往的重构工作中,一次重构的周期也就在10分钟到1小时。重构的周期越长,说明你考虑的问题越复杂,最终出错的概率也就越大。所以,我们一定要习惯“小步快跑”的工作方式,让自己只活在当下。
说了那么多重构,相信一定有一个疑问开始在你脑中萦绕。既然系统重构对于客户来说是透明的,客户完全感觉不到它的存在,毫无疑问,它对于客户来说就是毫无价值的。这下疑问就来了:既然重构对于客户来说就是毫无价值的,我们做它还有什么意义呢?要说明白这个问题,我们需要首先谈一谈软件修改的四种动机。
正因为如此,软件大师在讲述系统重构时总是强调,系统重构应当避免大设计,而应当尽量采用一个一个连续不断的小设计。这就是我们所说的“小步快跑”的设计模式。
小步快跑体现出了敏捷软件开发的特点——简单与快速反馈。不要想得太多了,活在今天的格子里,因为你永远不可能预知今后会发生什么。所以,做今天的设计,解决今天的问题,完成今天的重构,让明天见鬼去吧。要知道,简单对于我们是多么的重要。当我们的大脑开始思考各种复杂的问题时,就开始充血,然后就是梦游,最后的结果就是顾此失彼。既然如此,我们为何不选择一种更加简单的生活方式呢?
非常遗憾的是,很多时候我们不能选择这种简单的生活方式,因为我们害怕明天,害怕明天会出现那些我们处理不了的业务场景,因此我们开始过度设计。我不是批判我们不应当有预见,预见性设计与过度设计往往就是一线之隔。有限的预见是可以的,但不要想得过于遥远。当明天真的需求变更了,我们现在的设计不能满足了,怎么办呢?没什么大不了的,因为我们有重构。通过安全而平稳的重构方法先重构我们的系统,使之可以应付那个需求,然后再添加代码,实现新需求。这个过程被称为“两顶帽子”:一顶是只重构而不新增功能,一顶是增加新的功能实现新需求。正因为如此,我们在设计时思考当下就可以了。
另外一个问题就是及时反馈,落实到此地就是及时测试。只有测试通过了,此次重构才算成功,我们才能继续往下重构,否则我们必须还原。从这里我们不难看出,重构的周期是多么的重要。在我以往的重构工作中,一次重构的周期也就在10分钟到1小时。重构的周期越长,说明你考虑的问题越复杂,最终出错的概率也就越大。所以,我们一定要习惯“小步快跑”的工作方式,让自己只活在当下。
说了那么多重构,相信一定有一个疑问开始在你脑中萦绕。既然系统重构对于客户来说是透明的,客户完全感觉不到它的存在,毫无疑问,它对于客户来说就是毫无价值的。这下疑问就来了:既然重构对于客户来说就是毫无价值的,我们做它还有什么意义呢?要说明白这个问题,我们需要首先谈一谈软件修改的四种动机。