按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
EJB的人才需要也日渐升高。
由于＋是内建在Microsoft的Windows的操作系统中，理所当然地其使用率应该是不
低。只是＋的前身/MTS等由于其延展性受人质疑，因此使用/MTS作为企业核
心技术的并不多，大多数是使用作为客户端的可重复使用软件组件。但是＋推
出之后，由于其执行效率和延展性都大幅精进，再加上Microsoft在TPCC上显示的惊
人效率也都是使用＋组件，因此＋逐渐打入企业市场，成为Windows平台核心的
组件架构，被许多企业的应用系统所采用。
根据2002年调查结果显示，＋使用率已经超过了34。5％，同时还有13。9％的企业有
兴趣采用。Microsoft在努力推广技术数年之后终于有了一定的成果。不过Microsoft
现在面临的挑战是对于＋的影响，由于Microsoft的平台正从原生窗口转换到
的阶段，许多人也开始困惑起来，中的组件架构仍然是＋？还是有其他的
组件架构来代替？如果仍然要使用＋作为组件架构，那么纯的开发工具又
无法开发原生的＋组件，如此一来在中＋不就又不是First Class的组件架
构了吗？如果纯粹使用的组件，那么纯组件的延展性尚未经过实际的验证，
也不提供Two…Phase mit和分布式mit的能力，又如何能用来作为企业应用系统
的核心组件呢？看来Microsoft在这方面还有很长的一段路要走。
CORBA呢？在EJB/＋的强攻之下，CORBA似乎失去了原有的光彩，但是不可否认的是，
CORBA仍然是架构/服务最完整、经过最长时间验证的组件模型。根据2002年的调查结
果显示，CORBA仍然有相当数量的使用率，而且未来也仍然保有稳定的使用率，可见
CORBA仍然受到相当的欢迎。
随着Microsoft 的出现和成长，CORBA似乎反而可以在平台有更大的潜力，
相关的讨论请参考下一章〃EJB对抗CORBA？有趣的假设〃。
信息技术到了现在的阶段可以说是〃平台逐渐整合，但是程序语言则呈现百家争鸣的
情形〃。再加上UML等Modeling的技术和软件愈来愈贴近软件人员，数据库和SQL技术
更已经成为软件人员最基本的技能，因此软件人员本身也自然朝向身通18般武艺的阶
段。只是好的软件人员耍起来虎虎生风，而一般的软件人员在愈学愈多的情形下则一
无精通，到最后反而是害了自己。
回到前面的问题，目前的信息技术的确是朝着多元化的方向发展。太多的技术、产品、
架构、程序语言、数据库、客户端种类等技术，造成了许多软件人员的困惑和焦虑，
这是很自然的现象。但是另一方面，平台在收敛，系统开发正走向整合阶段，对软件
人员的要求也走向整合。因此，除了焦虑之外，软件人员在了解了软件趋势之后，更
应该提出疑问：
你准备好了吗？
快速的开发周期
上大学时，要学习系统分析和设计（System Analysis and Design）课程，正好看到一
个统计，说程序员一天只写一行有效的程序代码，当时我简直乐坏了。心想一定要进
入信息行业，又有高薪又有地位，更重要的是工作如此轻松，一天写一行代码，闭着
眼睛都可以做到。没有想到，在真正进入了信息行业之后，情形却大为不同。不但工
作繁重，每日更需撰写成百上千行的程序代码，这哪里是一天写一行的日子？不禁心
生感叹，自己似乎入错了行。
所有的读者都可以感觉到，现在系统开发的时程要求得愈来愈快。我记得5/6年前，
系统和项目开发的速度还是1年到1年半左右，到了3/4年前已经缩短成10个月左右，
在Internet/Intranet快速兴起之后，许多系统和项目甚至缩短到了3个月就要推出的
迫人时限。信息机构的调查显示，系统和项目的开发时程将持续地缩短，到了2012年
居然只有一天的时程，这种超高标准的要求可能会吓坏许多的软件人员。不管这份调
查的数据是否100％正确，但是从这份信息调查趋势以及我本身的经验来看，愈来愈
短的开发时程却是不争的事实。
面对愈来愈短的开发时程，软件人员应该如何适应？这是许多人面临的困扰。其实许
多的程序语言、开发工具、软件工程都强调帮助软件人员提高生产力，以适应快速开
发的要求，只是随着时程的要求愈来愈高，许多传统的程序语言和开发工具都已经呈
现力不从心的现象。既然如此，那解决问题的方案是什么呢？
数年前，业界对于软件开发的速度要求愈来愈快，这造成了软件品质的下降。许多软
件在完善率尚未达到一定的水准下便仓促推出，造成了更多的问题，因此软件业曾经
被许多人讥笑为〃不可靠行业〃。为了改善这个现象，许多软件工程技术相继出现，以
求提高软件品质。其中最为突出的是以面向对象的各种软件工程，强调软件IC、可重
复使用的软件组件为特质，以加快软件开发的速度并且提高软件品质。面向对象的大
旗造就了3位面向对象大师，也让UML等模型工程独领风骚，进而让Rational公司成为
近年来最重要的软件公司之一。不过几年下来，UML对于软件开发的贡献一直受到争
议，许多软件人员对于UML过于复杂的流程和过多的UML图形产生怀疑，因此前一阵子
又兴起了Extreme Programming的热潮，强调轻便、动态、快速开发的特性。其实这
个现象正反映了软件业界对于开发〃速度〃的要求已经超越了过份强调软件工程流程的
重要性。现在的信息业界需要的是〃灵活的〃开发速度。
右边的图片明确显示了从2002年下半年起，许多企业和软件公司对于软件开发特性的
要求，其中列为最重要的特质就是〃灵活性〃，接着仍然是强调速度的Extreme
Programming的特质。其实，这些对于软件开发的要求也正回应了上一张图形显示的
对于开发速度的要求。
我认为UML/RUP和Extreme Programming/Agile Development之间并没有冲突，反而是
相辅相成的。对于大型、复杂的系统开发，UML/RUP仍然是目前为止最好的方法之一，
只是需要适当的修正，不要过份强调所有的形式流程。而Extreme Programming/Agile
Development则特别适合中/小型系统，需要快速反应时间的开发要求。
既然快速开发已经成为现在最重要的软件开发要素之一，那传统软件人员应该如何适
应呢？其实这个原理也不难了解，答案就隐含在上图中Developer…Centric包含的意
义。想想看，现在的许多企业是如何增加效率的呢？答案之一就是组织扁平化，尽量
减少不必要的重复浪费。软件开发也是一样，软件工具应该尽量以开发人员为中心，
让开发人员使用较少的循环能够完成更多的开发阶段，并且提供更可靠的软件。例如，
新一代的开发工具允许开发人员在一个开发环境中，同分析/设计人员以UML的模型来
沟通，并且能够在一个开发环境中撰写程序代码，以可视化方式检视程序代码的关系
和可靠度，能够在相同的开发环境中进行单元测试、压力测试、负载测试，并且和测
试人员合作。另外，在这个开发环境中也能够和开发团队共同进行项目管理和版本管
理的工作。如此一来，开发人员可以在较短的时程内提供更高的生产力，缩减开发循
环。当然，这意味着以后软件人员必须知道得更多、要求也更高，但是，这的确可以
让开发人员更有效率，并且增加整个团队开发的生产力。
面对要求愈来愈高的动态开发时程，身为专业软件人员的你：
可准备好了吗？
程序语言的战争
从程序语言的发展史来看，数年前似乎就有统一的趋势。在商业应用上COBOL几乎是
事实标准，在科学计算上Fortran有不可取代的地位，而C/C＋＋则几乎垄断了大部分其
他的应用。但是随着Internet/Intranet以及RAD工具的兴起，这个由数个主流语言掌
握的局面很快被打破了。特别是在各种脚本语言（Scripting Language）和Java在Internet
应用上逐渐取得了优势之后，各种新的程序语言纷至沓来，让人眼花缭乱，不知如何
选择。程序语言战场在寂静了数年之后却突然陷入了前所未有的热战之中。
其实，各种程序语言的不断出现，反映的就是以往的程序语言已经不足使用或是不适
合使用在特定的应用中，因此才需要新的程序语言来解决问题。新的程序语言代表了
信息应用的多样化，而以往由COBOL、Fortran、C/C＋＋主掌的情势也被快速地打破。
如今的软件开发人员可能必须同时熟悉数种程序语言，并且在不同的应用中选择使用
最适当的程序语言。
以Web应用系统的开发为例，看看目前这个最流行、最重要的应用系统是由什么程序
语言开发的。在台湾地区，不可否认的是ASP绝对是最多人使用的解决方案，这是由
于台湾大部分的Web应用都属于中、小型系统，而且Web应用系统分布的区域并不算广
大，因此ASP就足够满足大多数的需求，软件人员选择的标准是好用、开发迅速的程
序语言。
但是，对于美国或是大陆这种幅员广大、并且拥有许多大型系统的应用而言，很可能
和台湾地区的情况大不相同。那么，到底世界上的软件人员是使用什么程序语言来开
发Web应用系统呢？对于这个问题的答案，我很有兴趣，因为可以拓宽自己的视野。
下图显示的是信息机构对美国软件人员调查的结果，从图中可以发现使用最高的居然
是XML，而不是ASP或JSP。不过XML、ASP和JSP这3者加起来占据了3分之一强，可见这
3种程序