BT

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

软件开发与交通阻塞的相似之处

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

Ken Delong解释了他认为软件开发“超级困难”的原因:

每个人都知道编写软件很难,但是我想探讨一下为什么软件开发这么难。

软件开发受本身四个特性之困,而这些特性也将其推到了“复杂的自适应系统”之境地,并且更将其逼入混乱之困局(至少足够接近)。这些特性是:
  • 非线性
  • 反馈
  • 时间延迟
  • 变化

以上并不是什么新鲜的发现,而且我们很多人都已经对其习以为常。也许有些人虽然听说过,但却不能理解背后的真正含义。这也使得Ken的博客文章有了用武之地:

在高峰期时,公路上车流密集,也许大家的行驶速度都还不慢。突然,某个人想看看车外的风景,将时速降至30英里,而且只维持了几秒钟。这会带来什么后果?交通大堵塞。曾经经历过堵得一辆接一辆的路况吧,却没想到突然可以时速70英里前进?之前的状况,是因为出现了变化——有人想游车河,非线性因素掺杂在一起,造成堵车。很多类似复杂系统都是可以自我维系的,交通堵塞正是其中一例。最后还是畅通了,但是其恢复速度却远低于任何人的直觉。

一个人减速——这并非偶然事件——却造成全线大塞车!问题的关键在哪里?软件既难而又危险,最微小的事情也有可能导致全盘皆输。难道就这样束手就擒么?

要想在流量有限的高速公路上避免严重塞车,就得让大家都把尾灯打开,这样可以让整个交通系统的利用率保持在安全的水平,一些正常的变化也就不会被无限放大、造成问题。我们在处理生产系统服务器的CPU占用率问题时,采用了同样的方式。我们会让CPU的占用率不超过30%,这样就可以防止峰值流量对服务器造成过大冲击。

因此,系统中必须提供反馈机制,使得它可以应对变化,不至于因此而崩溃:

在敏捷中,可以调整一个sprint接受的故事点数,以使sprint中的所有任务都能在sprint之内抵达“完成”状态。这就是“尾灯效应”。

Jurgen Appelo在《敏捷项目时间管理10原则》一文中提出的十项原则,可以视作敏捷软件开发的调整和“尾灯”:

  1. 定义“完成”条件
  2. 使用时间盒管理工作
  3. 不要为任务估算添加松懈时间
  4. 推迟决策
  5. 减少周期时间
  6. 让处理管道短小而狭窄
  7. 保持纪律
  8. 减少任务切换
  9. 防止长时间连续加班
  10. 分离“严重程度”和“紧急程度”

Jurgen详细阐述了这十条原则,并提供了各自深入阅读的参考资料。软件开发之难,很大程度上因为其过程类似于复杂的自适应系统。敏捷,如果可以正确实施,将会提供稳定的反馈。

查看英文原文:Software Developer:A Traffic Jam Waiting To Happen


在英文站文后的评论中,读者Karl Scotland指出:利用“看版”系统限制在制品,可以“让整个系统的利用率保持在安全的水平,一些正常的变化也就不会被无限放大、造成问题。”

读者Jim Leonardo在名为“避免拥塞,保持距离”的评论中说到:

若想使用拥塞作为比喻,我建议先定义其真正含义。拥塞等同于瓶颈。团队构成上的问题,可能会造成有些人在忙着解决难题的时候,其他人却处于空闲状态。如果有这些情况发生,你应该考虑一下因素:

1) 团队中人员的职责是不是划分得太明确了?如果有瓶颈产生,是不是因为在跨职能方面做得不够?赶紧多做点培训,多进行知识分享吧。

2) 有多少任务需要其他任务作为前置条件?如果因为前置任务没有完成,导致有些人的工作限于停滞,是否有其他的任务可供这些人上手开始工作?对于团队和项目来说,功能特性切分成任务的方式合理么?是不是可以用另外的方式进行划分、组织开发?

3) 简单之极……为任务的开发准备足够的时间了么?现实一点,如果总是发现瓶颈(拥塞),也许是因为过于低估了某些类型的任务的完成时间,或者在做规划时没有考虑到不同的开发速度(要注意,“速度慢”的开发者之所以慢,可能是因为他们对代码质量的要求比较高,所以要全面考虑问题)

最后一点,也是我最想在infoq上反复强调的……

4) 团队的工作时间是不是太长了?有人陷入停滞,是不是因为他们觉得自己应该每周工作70个小时?相反地,总是成为瓶颈的程序员,是不是也是把所有时间都投入工作的那位?倘若果真如此,这个人就像一个正在形成的火药桶。如果它现在还没有爆发,将来一定会(强制对他的代码进行复查绝对不可取!)。

作者Amr Elssamadisy引用了Flemming Funch的博客,对于complex和complicated之间的不同进行了分析:

我们每天都会用“complicated”和“complex”,不相区分。要讨论复杂性(complexity)就变得困难了,比如说探讨自然界中的复杂性。

可以说我们需要复杂性的科学定义,可是科学却给出了至少32种不同的诠释,每种都不一样。要是我们能摆脱迷惑的困扰,就可以发现下面这种可行的说法:

构成上的复杂性(complicated),是指某项事物包含了很多错综关联在一起的组成部分,很难搞清楚各个部分之间的关系。即使能搞清楚,也不能保证这些部分是以合理的方式组合在一起的。

系统上的复杂性(complex),是指某项事物作为一个系统出现,它所展示的系统属性并不明显。这与一些部分的简单叠加之和有所不同,更难以理解。构成的部分不一定很多,但是组合在一起之后的结果却难以搞得很明白,在某些方面以一个整体的方式呈现。

一架空客380具有构成上的复杂性(complicated)。一条水母具有系统上的复杂性(complex)。巴黎地铁网络具备构成上的复杂性(complicated),人们使用它的方式具有系统上的复杂性(complex)。你的骨骼框架具备构成上的复杂性(complicated),作为人的你具有系统上的复杂性(complex)。一栋建筑物是具有构成上的复杂性(complicated),而一个城市具有系统上的复杂性(complex)。

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

《第五项修炼》中有类似的描述 by 熊 小

系统思考的第三项基本元件“时间滞延”……

关于complex和complicated by 张 军

我阐述一下自己的理解:complex就是静态复杂性,complicated是动态复杂性

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

2 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT