BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

敏捷开发实践真的不利于架构设计吗?

| 作者 Amr Elssamadisy 关注 0 他的粉丝 ,译者 乔梁 关注 7 他的粉丝 发布于 2007年7月19日. 估计阅读时间: 4 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

增量迭代开发(敏捷实践之一,它意味着每次迭代的产出只是本次迭代范围内的需求)真的不利于产生好的设计吗?Scrum真的提倡“忽视架构问题”吗?如果没有敏捷技术实践的话,架构设计能有效的演化吗?测试先行式的开发真会产生优雅的设计吗?在红绿条提示下的重构循环只在局部小范围内有效吗?

来自Net Objectives的Alan Shalloway就利用Scrum构建应用的经验向ScrumDevelopment yahoo group的成员提出一些问题,问题之一就是“他们是否找到代码质量是依靠什么来保证的?”

当我在课程中或在那些讨论“向已建系统中追加新特性”的会议中提出这个问题时,每个人都认为这属于集成成本。我想,这是因为大多数人不会编写那些融入了很多设计模式的具有良好的扩展性、足够灵活并且易维护的代码。这些人中,大部分也没有使用过Scrum。

Shalloway随后详细解释了他的观点:

……正如Scrum所告诉我们的,他们(指在Scrum团队中的开发者)根据客户价值一次只开发系统的一小部分,如果团队中有高级架构师的话,就会组织得更好。很多开发者有一种很好的意识,即他们会回头看一下是否应该做一些改动,使架构更合理。但更多的人并不知道,假如代码是通过拷贝、粘贴并修改(甚至改得面目全非)得来的,那么这会带来很多冗余。此时,Template Method可能是一个比较好的解决方案。

也许我悲观了一些,但我的感觉是,假如你没有注意熵的话,就意味着它们会达到你不期望的地步。在你的案例中,你正在使用Scrum来改善很多团队忽视的东西。所以,我的问题是:

  1. 大家忽视它了吗?
  2. 如果真是这样,它会引来问题吗?

到目前为止,这些反应都表明很多使用Scrum的团队有这个问题,甚至那些坚持写测试和进行重构的团队也有同样的问题。那些没有使用多少有些变化的敏捷技术实践的团队,可能会有更大的麻烦。(请记住:Scrum 与开发技术没有必然的联系,你可以使用传统方法开发软件,也可以用XP,或者其它技术实践,只要你在Scrum的框架之内使用就可以了)

接下来,让我们讨论一下现实中,Red-Green-Refactor loop是如何发挥作用的?一个团队在写测试和重构方面深有心得,就会有一个好的设计吗?Paul Jones 的blog中有一篇关于TDD如何创建了混沌代码(Ravioli Code),宣称用TDD开发出来的代码是低耦合的代码:

我想,很多TDD和测试先行的理想主义者和宣传者写出了的确经过充分测试的代码,但还是很难理解。

Jones并不想撼动TDD,因为与其测试目的相比,TDD实际上更关注于设计。但这还是会带来一个有趣的事情。在使用这些实践的敏捷社区中,好在哪里呢?随着社区的成长,这些实践带来的麻烦比其带来的好处还多吗?与传统开发技术相比,这些工具被不正确的使用是否更危险?

最后,让我们假设:我们正在恰当地使用Scrum和TDD。毕竟,象Ron Jeffries 在《We Tried Baseball and It Didn't Work》一文中所呈现的,我们不能因为自己没有正确地使用它而将不好的结果强加给它。TDD会产生好的设计吗?对于使用Red-Green-Refactor loop的做法,重构可以说是一种局部优化技术。我们优化局部的设计。本质上,这等同于steepest descent algorithm,也就意味着重构几乎总是会带来次优设计,就象使用TDD来做“数独游戏”一样。

现在是我们用批判的眼光来重新审视我们的这些实践的时候了吗?

查看英文原文:Are Agile Development Practices Detrimental to Architecture and Design?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

如何正确的使用敏捷实践的确是个难题 by 田 乐

架构是预先设计。实践证明过早的做决定容易造成过度设计。
但是将决定全部后移则会造成大量浪费性的重构(重构也有可能绕弯路,说明此时的重构使用不当),此时又凸显了架构设计的价值。
所以1方面架构师非常重要,另一方面从迭代的流程上也应该强调架构设计这个环节,要从宏观和微观两个方面保证设计。
我觉得本文这句话很重要“与传统开发技术相比,这些工具被不正确的使用是否更危险?”
我想回答是肯定的,如果使用不正确那么更危险。

Re: 如何正确的使用敏捷实践的确是个难题 by Jacky Li

我同意楼上的观点

行业经验的价值 by zhang liang

我不清楚敏捷先行者们是否认为敏捷开发方法只适用于开发新的、很少有经验可借鉴的项目。
大部分公司做的项目都是有延续性的,尤其是行业性项目的延续性更强,很难想像对这种项目不做核心业务和技术架构的预先设计。这方面我觉得RUP非常好,RUP提倡根据一个稳定的业务和技术核心架构开展迭代,而不是客户什么时候要,开发人员就什么时候考虑,这样搞下去很容易变成code and fix。

Re: 行业经验的价值 by Jacky Li

敏捷的不做预先设计,是因为可以消除预测未来所带来的浪费,但是对于延续性的项目而言,又怎么谈得上是预先设计呢?感觉楼上的话本身就是相悖的啊

Re: 行业经验的价值 by zhang liang

很明显是因为我们对“预先设计”这几个字的理解不同,呵呵

Re: 如何正确的使用敏捷实践的确是个难题 by wan zhigang

我也同意1楼的观点。
架构设计要能够细到对详细设计做指导。在具体的详细设计过程中,是否要先设计清楚了,然后再编码;还是先简单设计,编码,然后重构来改善设计,我觉得都可以吧。没有说非这样,非那样。主要取决于项目成员的水平和习惯。但是,TDD和重构技术总是有用处的。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

6 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT