对话马丁·福勒(Martin Fowler)——第三部分:进化型设计
上一篇 / 下一篇 2012-05-25 09:39:32 / 个人分类:杂谈
第二部分:设计原则与代码所有权
^ C1G3JZef0 第三部分:进化型设计51Testing软件测试网7XAGgF1i\ J
第四部分:灵活性与复杂性51Testing软件测试网-J"BBz&~
第五部分:测试驱动开发
-D2Z m@:npl?0 第六部分:性能与过程调优
3R5yWsw;dLId-WCg0 第三部分:进化型设计
P G0~|WhB"}0_%TG(l7^^ GT-s H0 在连载的第三部分,福勒讨论了计划型设计和进化型设计的区别,揭示了着眼于解决表象问题可以使开发者发现本质问题,并主张好的设计工作不会降低工作效率。51Testing软件测试网~5?)x|/IlI@ C~
pfG@M ZK"B0 计划型设计和进化型设计
ZK3HlKu051Testing软件测试网s wSq8QU比尔:在你的论文《设计是否已死》(Is Design Dead)一文中,谈到了计划型设计。那么什么是计划型设计?
%o{ikk)i|-IW051Testing软件测试网rl:m&g;gk S:l$IT&^马丁:我 将设计区分为计划型设计和进化型设计。当开发者着手实施一个软件时,他首先需要做设计,然后再按照这个设计进行编 码实现软件,这就是我所说的计划型设计。计划型设计可能借助 UML;或者把整个系统分为若干子系统,定义这些子系统间的接口。在计划型设计中,在设计和代码实现这二者之间存在明确的切换。而这二者又往往由不同的人 来完成。架构师构思设计,开发者编码实现。做好的设计并不是说一点都不能改变,但基本上是固定的。你可能会说,设计做得越好,在编码的时候,就会越少对设 计做出改动。51Testing软件测试网9M#_0K4uJ6qw
!W X4~J(N!h0 而在进化型设计中,开发者在编程实践的过程中逐渐完善设计。刚开始的时候并没有设计,而是先实现一些小的功能。随着实现的功能越来越多,设计才逐渐成型。
j&l1rH(M2T)O|*L8L0g,f9NH&EM0 我在《设计是否已死》一文中想要强调的是,很多人在尝试进化型设计时,往往是在一种无约束无原则的环境里,最终的设计必然很蹩脚。这是人们之所以倾向于计划型设计的原因之一。
{8vW%tg"j0$`7pc(C-A0 但是,在我看来,极限编程实践中,通过持续不断的集成、测试和重构,进化型设计能够做到比计划型设计更有效。计划型设计的弱点就是,要想做出一个好的设计非常难。
6|x@YEEL051Testing软件测试网`:}#pz}(HMi!O比尔:为什么?51Testing软件测试网E[:C,{5`SI/]
51Testing软件测试网y'V4j'mzYh]马丁:我解释不清楚。这就跟解释不清楚为什么谱一曲交响乐会如此困难一样。世界上能把这些工作做好的人可以说是凤毛麟角。我想,我认为预先设计(upfront design)就属于这类工作。要做好这类工作实在是太难了。
,rP@1Tk K051Testing软件测试网-\8V#f(F;f;Z}有趣的是,很多进化型设计的倡导者,比如肯特·贝克和沃德·坎宁安,都是非常出色的设计师。但正是他们,最后认识到自己所做的预先设计往 往不够好。他们容易把一些事情过于工程化,在不需要灵活性的地方设计灵活性,而在需要灵活性的地方又未予以考虑。因此,他们最终采用了进化型设计,并通过 运用一套规则,保证了设计效果。其结果是,不但最终的设计更加出色,并且速度也加快了。拿我自己来说,80%左右的时间里,进化型设计会得到不错的结果。 而不客气地说一句,我认为我的设计水平要比一般人高。因此,我认为进化型设计应该可以适用于更广泛的人群。51Testing软件测试网'Cv.\DR!x
b1E&V%TP/f}D7m0 重构与预先设计
!L&wa Q]:`tl051Testing软件测试网Sf#FiC2Gj1V*g比尔:重构如何改变了预先设计的地位?
(Yp)z5O*v%} D051Testing软件测试网 }2A$f {y马丁:人们之所以采用计划型设计,是因为他们认为改动代码是件很麻烦的事情。因为当你改变代码时,有可能破坏了一些东西并造成许多漏洞。可是,如果你既有单元测试,又有在测试基础上建立起来的有条理的重构技术,那么你就能十分快速有效地改动代码,并且不太会引起什么问题。51Testing软件测试网mP[!_:}
(|hp#E*e,FI.v0 比尔:预先设计在重构和其他可行的实践中有什么作用?你现在还会做一些预先设计吗?51Testing软件测试网Z{)QM l!BOp nV
51Testing软件测试网Yq}"ov马丁:我 认为一些地方还是可以用到预先设计的,不过不会很多。一些人——像肯特·贝克和罗恩·杰弗里斯——认为预先设计已 经消亡了。从某种意义上来说,他们是对的,因为你可以借助进化型设计搭建更复杂的系统。但在某些情况下,预先设计可能让你的进度加快一些。比如说,我不赞 同在架设数据库之前就讨论数据库的进化问题。我可能会对数据库的存在有一个初步的判断,然后以此作为起点。当然,我仍会用进化的方式完成大部分设计。51Testing软件测试网 E'g#F`9t9r
!~X.Uqd0 比尔:构造良好的(well-factored)程序和设计良好的(well-designed)程序之间有区别吗?
&g0[o O"SNtu0R&A!JWvu0 马丁:它们在本质上并没有什么区别,但侧重点有所不同。设计强调的是构造——将程序划分为若干分割清晰的部分。对我来说,“构造良好的”一词表达了更多对于设计的感觉,也即当你审视或使用这个设计时的感觉。51Testing软件测试网#J^rj;fq)W
51Testing软件测试网2O#nx3ymm7c代码中的“坏味道”51Testing软件测试网5us.Xi.xr w;f]
51Testing软件测试网@7A0zj l`%~r比尔:在你的《重构》一书中,关于何时应用重构,你是这样阐述的:“与其去追求一些很模棱两可的编程美学原则(坦率地说,这是我们咨询师们最喜欢做的事情),还不如来点儿更实际的。”51Testing软件测试网?k`M3E M#G6S V0[q0B
TDb%Cvuf*h0 我很好奇,你是怎么看待美学的?我的经历中有很多次都是跟已有的代码打交道。这些代码的设计很烂,因此处理起来非常痛苦。如果这些设计能做得好些,让我不那么痛苦的话,我会非常感激。所以,对我来说,美学至少还是有些意义的,它可以使我的工作轻松些。51Testing软件测试网3l WV)uJV
51Testing软件测试网8B-[e/V/d7V7j0~4p马丁:嗯,在讨论何时应用重构时,我的确是这样谈论美学的。从某种意义上说,我在重构准则中所给的那些条条 框框也是一种模 棱两可的美学原则。不过,我试着给出更多的说明,而不是仅仅说“当你的代码看上去很丑陋的时候就需要做重构。”比如说,重复的代码是一种“坏味道”,再比 如 说,很长的方法是一种“坏味道”,或者很臃肿的类也是一种“坏味道”。51Testing软件测试网 K?I~0O
0KM&t+y$L-b0 很多“坏味道”是很容易嗅出来的。令人惊奇的是,当你审视你的程序时,往往一些很明显的现象,像是某个方法长达100行,就能引导你改进你的设计。51Testing软件测试网,}CAo2K
L$V8hL0Sw.f0 在重构这个长达100行的方法时,你可能会发现一些诸如责任分配(responsibility allocation)不合理这样的设计问题。像这样的问题,你是不可能光凭扫一眼代码就发现的;但是,一个长达100行的方法,却是一眼就能看出来的。 所以说,很表象的问题能够把你带向更深层的问题。