Flex与JSON及XML的互操作
平台需要互操作性。在这篇文章中，作者仔细研究了Flex和JSON及XML的互操作性。文章也包含了使用E4X库来将XML映射到图表和表格组件的内容，还演示了如何使用as3core库来解码JSON消息。
新闻
以生产力为导向的决策：原因，影响和局限
作者 Sadek Drobi译者 赵劼，郭晓刚 发布于 2008年1月13日 下午9时29分
软件项目中有许多决策是出于生产力方面的考虑而决定的，尤其是在项目比较成功的情况下，市场发展了，与此同时领域知识和客户需求也变得愈发复杂。产品的目标范围很可能会发生无法预料的改变，而且需要更进一步按照用户的需求来定制。就像Lispy所特别指出的那样，很多团队通过“使出丑陋的招数”来快速适应新需求，“哄着客户高兴了，钱就滚滚而来”。他把这种对软件的质量的影响称为“成功之痛”。
Bob Martin描述了这些影响，并且认为这种“快速而拙劣”的做法不可能长时间维持下去，因为它最终会不可避免地使项目进展速度变慢。
我最近刚见过一个客户，他们是一家成功的初创企业，一开始可以说是突飞猛进。他们的软件发展得飞快，不过从头到尾都是不择手段拼凑出来的。现在这个一团乱麻的软件让他们寸步难行。任务失败率很高，修改引起的非预期副作用很多，生产效率很低。
[……]“快速而拙劣”这个词是自相矛盾的，拙劣总是意味着慢。
常有人觉得不管怎样业务软件都会是一团糟，并以此来作为不择手段的正当理由，Bob Martin非常不同意。他认为虽然业务规则有着“复杂、武断、不通用”的趋向，但代码与之相反，必须尽可能整洁：
要是再把业务规则的烂摊子丢进另一个烂摊子，你就更没办法理清它们了。要想从规则的乱麻中理出一个头绪，唯一的方法就是用最最清晰的代码来表达它们。
Roland Kaufmann在Martin的文章后评论说，把生产力摆到首位的想法，其解释可以归结到“一个荒唐的内部收益率（IRR），令短期的节省比长期的收益更有利”。尤其有许多经理总是假定任何项目只要存续的时间够长，肯定免不了周期性地完全推倒，再重新设计和实现。其中一条评论还认为这种短视的、以生产力为导向的合理性，正是计算机科学专业的毕业生被责怪不会写软件的原因。
David Chisnell说得没错，“计算机科学和软件工程是非常不同的两种训练”。后者“从工具和过程两个方面教授开发软件的方法”，而计算机科学课程只“简要地接触这些主题”，且计算机科学并不是“职业训练”。毕业生对许多语言走马观花，而得不到这些语言及相关工具的任何深入的知识。因此，他们很可能没法高效率地编码并遵守紧迫的期限。但正如一位博客作者所说的，“毕业生们的不称职谁都看得到”，但有些人“没什么大规模设计/架构的智慧”却大干快上，反倒并不会“因糟糕的设计决策令整个系统慢慢变得不可维护而遭受责难”，因为“他们初期的成功让管理层觉得最后的失败是非人力所能避免的。”
不过，Lispy认为，生产力低下的计算机科学毕业生却具备一些技能，会随着项目的大小和复杂性的增长，而成为开发成功的关键。“增加数之不尽的特性，或者每张单子都要进行昂贵的定制工作”，这些都是“规模增长之大敌”，Lispy认为，就算很努力而且运气很好，“没受过训练的野路子程序员”也只能把项目扛到某个程度，超过之后他们就会需要“帮助他们编写他们的工具的工具”。Lispy相信计算机科学是提供这样的工具所必需的，因为那需要更深一个层面的理解才行。爱因斯坦曾说，“我们面对的重大问题无法在我们创造出这些问题的同一个思维层面上解决。”要解决现实的开发工作中所面对的问题，我们可能需要计算机科学的毕业生，虽然他们显然没法在现实世界中以生产力为导向的要求下编写代码。
查看英文原文：Decisions driven by productivity concerns: Reasons, implications and limitations
疑问
发表人
小 熊
发表于
2008年1月13日 下午11时2分
Re: 疑问
发表人
Stone Shi
发表于
2008年1月14日 上午1时41分
Re: 疑问
发表人
小 熊
发表于
2008年1月14日 上午8时27分
Re: 疑问
发表人
Jie Zeng
发表于
2008年1月15日 下午11时32分
Re: 疑问
发表人
Xiaogang Guo
发表于
2008年1月17日 下午1时6分
Re: 疑问
发表人
Xiaogang Guo
发表于
2008年1月14日 上午5时49分
Re: 疑问
发表人
凉粉 小刀
发表于
2008年1月14日 下午7时51分
-
『但正如一位博客作者所说的，“毕业生们的不称职谁都看得到”，但有些人“没什么大规模设计/架构的智慧”却大干快上，反倒并不会“因糟糕的设计决策令整个系统慢慢变得不可维护而遭受责难”，因为“他们初期的成功让管理层觉得最后的失败是不可避免的。”』
这句话，我有点不太明白，尤其是最后一句：为什么“初期的成功让管理层觉得最后的失败是不可避免的”？ -
初期的成功不代表架构的成功以及最后结果的成功。失败往往是在第一步决定的
-
初期的成功令管理层以为失败是自然规律，不关设计者的事。
译得看不懂吗--b，要检讨…… -
那又怎么能够根据初期的成功来判断架构和结果是否能够成功呢？那么成功的架构和项目，初期是什么样的？难道不应该是成功的么？
我是说，此处管理层根据“初期的成功”就来判断“最后的失败不可避免”似乎有些逻辑上不能自圆其说。 -
嗯，“他们初期的成功让管理层觉得最后的失败是不可避免的”和“ 初期的成功令管理层以为失败是自然规律，不关设计者的事”分明是两个意思……
-
这里的意思是说“他们初期的成功让管理层觉得最终到来的失败是非人力所能避免的”，就是说他们初期的成功让不甚了解架构重要性的管理层充分信任了他们的个人能力，如果最后失败了，他们会认为这本来就是mission impossible，无需怪罪个人和整个开发过程。
-
"是非人力所能避免的",就是要找这几个字,thanks!
7 条回复
回复