BT

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

软件设计真的有回报吗?

| 作者 Niclas Nilsson 关注 0 他的粉丝 ,译者 郭晓刚 关注 0 他的粉丝 发布于 2007年8月1日. 估计阅读时间: 3 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!
许多开发者都曾遇过被要求减少设计的环节并“尽快把东西做出来”。Martin Fowler对这种做法表示质疑,并认为对于大多数项目来说,以设计质量为代价换取开发速度是不现实的。Martin说道:

设计活动的确要花费时间和精力,但这是有回报的,因为设计使得将来程序的发展更为畅顺。忽略设计能使你在短期内节省时间,但这笔技术负债越积越多,最终会逐渐降低你的生产效率。为软件设计投注精力可以让你的项目更具生命力,让你的项目可以走得更快更长久。

这里所说的设计活动包括各种风格,从经典的预先设计(Up-Front Design)到自然出现设计(Emergent Design),都是在敏捷项目中常见的。

人们对好的设计的影响程度意见不一,而Martin更多次听到一种相当极端看法:

确实有数次让我印象深刻的看法是,即使降低开发速度,也要使设计上的成果让程序员们保持心情愉快。

牺牲设计上的投入来或换取开发速度在大多数项目中都行不通,这是因为系统很快就变得难以下手,在设计上节省的时间很快就由于生产效率的降低而得不偿失。

在削减任何设计投入之前,如果我们能找到正在开发的系统的设计投入和回报的边际曲线,当然结果会最好,但我们只能依靠经验和直觉来做到这一点,因为我们没办法测量软件开发的生产效率。

然而,在特定条件下,估算设计回报的边际需要经验,正如Antti Tarvainen所指出的,缺乏经验不光让软件开发的新手难以作出直觉判断——也使经理难以评估设计投入的经济价值

我们的软件开发新手无法直觉判断设计的价值,因为他的概念模型还不够丰富……问题是,他不知道与没有设计直接去编写软件功能相比,设计到底有多大的价值。对设计的低估导致糟糕的代码质量,并陷入编码——修补错误的循环。高估设计的价值导致项目瘫痪在分析阶段(对于大型的预先设计)或者降低迭代速率(对于敏捷方法)。

Dennis E. Hamilton(又名Orchid)将设计成熟前就武断结束设计环节归因于几个常见错误

这解释了新手常犯的疏失:好高骛远。我已经揪住了猪尾巴,下一步该怎么做红烧肉?如果一开始能预见到结局,我就不会搞砸了,但谁说我一定会搞砸呢,对不对?让我在没有设计的野地里撒撒野,反正在这里我也没有起到什么作用。除了Fowler说的安全降落区域,肯定会有什么看不见的东西接住我,摔不死的。

这也解释了常见的管理疏失:没有深思熟虑就将泰山压顶的技术负债丢到一边,也从不想法去补救。管理层也许应该比软件工人们更加理解软件生命周期和风险管理,虽然他们没有技能(当然也不会蠢到)自己去完成这些工作。

Fowler的文章以他对设计回报的边际所在的看法作结:

我认为它比大多数人想象的要低:通常是数周而非数月。但这仍然只是我的直觉判断。

如果这个观点是正确的,那么几乎所有软件系统都会为设计上的妥协付出代价。

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的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通知我

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

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

讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT