qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

对话马丁·福勒(Martin Fowler)——第三部分:进化型设计

第一部分:重构
  第二部分:设计原则与代码所有权
  第三部分:进化型设计
  第四部分:灵活性与复杂性
  第五部分:测试驱动开发
  第六部分:性能与过程调优

  第三部分:进化型设计

  在连载的第三部分,福勒讨论了计划型设计和进化型设计的区别,揭示了着眼于解决表象问题可以使开发者发现本质问题,并主张好的设计工作不会降低工作效率。

  计划型设计和进化型设计

  比尔:在你的论文《设计是否已死》(Is Design Dead)一文中,谈到了计划型设计。那么什么是计划型设计?

  马丁:我将设计区分为计划型设计和进化型设计。当开发者着手实施一个软件时,他首先需要做设计,然后再按照这个设计进行编 码实现软件,这就是我所说的计划型设计。计划型设计可能借助 UML;或者把整个系统分为若干子系统,定义这些子系统间的接口。在计划型设计中,在设计和代码实现这二者之间存在明确的切换。而这二者又往往由不同的人 来完成。架构师构思设计,开发者编码实现。做好的设计并不是说一点都不能改变,但基本上是固定的。你可能会说,设计做得越好,在编码的时候,就会越少对设 计做出改动。

  而在进化型设计中,开发者在编程实践的过程中逐渐完善设计。刚开始的时候并没有设计,而是先实现一些小的功能。随着实现的功能越来越多,设计才逐渐成型。

  我在《设计是否已死》一文中想要强调的是,很多人在尝试进化型设计时,往往是在一种无约束无原则的环境里,最终的设计必然很蹩脚。这是人们之所以倾向于计划型设计的原因之一。

  但是,在我看来,极限编程实践中,通过持续不断的集成、测试和重构,进化型设计能够做到比计划型设计更有效。计划型设计的弱点就是,要想做出一个好的设计非常难。

  比尔:为什么?

  马丁:我解释不清楚。这就跟解释不清楚为什么谱一曲交响乐会如此困难一样。世界上能把这些工作做好的人可以说是凤毛麟角。我想,我认为预先设计(upfront design)就属于这类工作。要做好这类工作实在是太难了。

  有趣的是,很多进化型设计的倡导者,比如肯特·贝克和沃德·坎宁安,都是非常出色的设计师。但正是他们,最后认识到自己所做的预先设计往 往不够好。他们容易把一些事情过于工程化,在不需要灵活性的地方设计灵活性,而在需要灵活性的地方又未予以考虑。因此,他们最终采用了进化型设计,并通过 运用一套规则,保证了设计效果。其结果是,不但最终的设计更加出色,并且速度也加快了。拿我自己来说,80%左右的时间里,进化型设计会得到不错的结果。 而不客气地说一句,我认为我的设计水平要比一般人高。因此,我认为进化型设计应该可以适用于更广泛的人群。

  重构与预先设计

  比尔:重构如何改变了预先设计的地位?

  马丁:人们之所以采用计划型设计,是因为他们认为改动代码是件很麻烦的事情。因为当你改变代码时,有可能破坏了一些东西并造成许多漏洞。可是,如果你既有单元测试,又有在测试基础上建立起来的有条理的重构技术,那么你就能十分快速有效地改动代码,并且不太会引起什么问题。

  比尔:预先设计在重构和其他可行的实践中有什么作用?你现在还会做一些预先设计吗?

  马丁:我认为一些地方还是可以用到预先设计的,不过不会很多。一些人——像肯特·贝克和罗恩·杰弗里斯——认为预先设计已 经消亡了。从某种意义上来说,他们是对的,因为你可以借助进化型设计搭建更复杂的系统。但在某些情况下,预先设计可能让你的进度加快一些。比如说,我不赞 同在架设数据库之前就讨论数据库的进化问题。我可能会对数据库的存在有一个初步的判断,然后以此作为起点。当然,我仍会用进化的方式完成大部分设计。

  比尔:构造良好的(well-factored)程序和设计良好的(well-designed)程序之间有区别吗?

  马丁:它们在本质上并没有什么区别,但侧重点有所不同。设计强调的是构造——将程序划分为若干分割清晰的部分。对我来说,“构造良好的”一词表达了更多对于设计的感觉,也即当你审视或使用这个设计时的感觉。代码中的“坏味道”

  比尔:在你的《重构》一书中,关于何时应用重构,你是这样阐述的:“与其去追求一些很模棱两可的编程美学原则(坦率地说,这是我们咨询师们最喜欢做的事情),还不如来点儿更实际的。”

  我很好奇,你是怎么看待美学的?我的经历中有很多次都是跟已有的代码打交道。这些代码的设计很烂,因此处理起来非常痛苦。如果这些设计能做得好些,让我不那么痛苦的话,我会非常感激。所以,对我来说,美学至少还是有些意义的,它可以使我的工作轻松些。

  马丁:嗯,在讨论何时应用重构时,我的确是这样谈论美学的。从某种意义上说,我在重构准则中所给的那些条条框框也是一种模 棱两可的美学原则。不过,我试着给出更多的说明,而不是仅仅说“当你的代码看上去很丑陋的时候就需要做重构。”比如说,重复的代码是一种“坏味道”,再比如 说,很长的方法是一种“坏味道”,或者很臃肿的类也是一种“坏味道”。

  很多“坏味道”是很容易嗅出来的。令人惊奇的是,当你审视你的程序时,往往一些很明显的现象,像是某个方法长达100行,就能引导你改进你的设计。

  在重构这个长达100行的方法时,你可能会发现一些诸如责任分配(responsibility allocation)不合理这样的设计问题。像这样的问题,你是不可能光凭扫一眼代码就发现的;但是,一个长达100行的方法,却是一眼就能看出来的。 所以说,很表象的问题能够把你带向更深层的问题。

  比尔:我参与过的一个项目竟然有一个长达11页的 while 循环。

  马丁:这太不可思议了。

  比尔:我们苦干了六个月试图让这个软件稳定运行,可是我们不敢动这个11页的循环。

  马丁:这恰恰从另一个侧面说明了这个长达11页的循环是个糟糕的设计。如果你对改动某处代码心存顾虑的话,那它显然是一个蹩脚的设计。

  良好的设计与效率

  比尔:我想,人们不注重设计的一个原因是由于工作的流动性。那个最初编写11页 while 循环的程序员在我们接手项目的时候已经离开了公司。我认为,程序员因为自己的糟糕设计而自食其果的情况很少发生,因此他们没有足够的动因去注重设计。此 外,即便他们注重,但设计毕竟是一项费力不讨好的工作,好的设计需要时间,而开发中的时间压力往往很大。

  马丁:我不同意“好的设计需要更长的时间”这样的说法。

  比尔:为什么?

  马丁:这是很有意思的一件事。在软件业,我们似乎普遍认为,慢工出细活。但当我回顾我自己的经历时,却发现保持代码的良好构造以及编写测试反而使我的工作加快了。

  我想,人们把改进设计所花的时间看作是“失去”的时间,但却没有看到将来对代码的改动会容易得多,往往只需要几分钟的时间,否则可能要花上两三个小时。

  人们往往还低估了在调试上所花的时间,低估了他们用来追踪一个“潜伏”很久的漏洞所花的时间。我在写代码的时候可以立即察觉产生的漏洞,这使得我能在它潜伏下来之前就解决它。没有几件事比调试更花时间和更令人沮丧的了。假如我们一开始就能避免产生漏洞,那效率岂不是要提高很多?

posted on 2012-05-25 09:46 顺其自然EVO 阅读(114) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2012年5月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜