应用JSF、Ajax和Seam开发Portlets（1/3）
.gif)
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目，怎样配置一个JSF应用去使用JBoss Portlet Bridge，以及JBoss Portlet Bridge所具备的功能。
新闻
软件开发与交通阻塞的相似之处
作者 Amr Elssamadisy译者 郑柯 发布于 2008年8月23日 上午3时51分
Ken Delong解释了他认为软件开发“超级困难”的原因：
每个人都知道编写软件很难，但是我想探讨一下为什么软件开发这么难。
软件开发受本身四个特性之困，而这些特性也将其推到了“复杂的自适应系统”之境地，并且更将其逼入混乱之困局（至少足够接近）。这些特性是：
- 非线性
- 反馈
- 时间延迟
- 变化
以上并不是什么新鲜的发现，而且我们很多人都已经对其习以为常。也许有些人虽然听说过，但却不能理解背后的真正含义。这也使得Ken的博客文章有了用武之地：
在高峰期时，公路上车流密集，也许大家的行驶速度都还不慢。突然，某个人想看看车外的风景，将时速降至30英里，而且只维持了几秒钟。这会带来什么后果？交通大堵塞。曾经经历过堵得一辆接一辆的路况吧，却没想到突然可以时速70英里前进？之前的状况，是因为出现了变化——有人想游车河，非线性因素掺杂在一起，造成堵车。很多类似复杂系统都是可以自我维系的，交通堵塞正是其中一例。最后还是畅通了，但是其恢复速度却远低于任何人的直觉。
一个人减速——这并非偶然事件——却造成全线大塞车！问题的关键在哪里？软件既难而又危险，最微小的事情也有可能导致全盘皆输。难道就这样束手就擒么？
要想在流量有限的高速公路上避免严重塞车，就得让大家都把尾灯打开，这样可以让整个交通系统的利用率保持在安全的水平，一些正常的变化也就不会被无限放大、造成问题。我们在处理生产系统服务器的CPU占用率问题时，采用了同样的方式。我们会让CPU的占用率不超过30%，这样就可以防止峰值流量对服务器造成过大冲击。
因此，系统中必须提供反馈机制，使得它可以应对变化，不至于因此而崩溃：
在敏捷中，可以调整一个sprint接受的故事点数，以使sprint中的所有任务都能在sprint之内抵达“完成”状态。这就是“尾灯效应”。
Jurgen Appelo在《敏捷项目时间管理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）。
《第五项修炼》中有类似的描述
发表人
小 熊
发表于
2008年8月24日 上午12时41分
关于complex和complicated
发表人
jun zhang
发表于
2008年8月24日 下午8时45分
2 条回复
回复