系统、组件系统等应用。各位读者可看到了未来所需求的人才？
组件架构使用趋势
Java的EJB和Microsoft的＋都想在企业市场竞逐，成为企业对象应用系统的核心组
件架构。但是EJB和＋却选择了两个不同的发展方向。对于EJB，SUN只是定义出其
标准功能规格，再由各个EJB厂商根据标准EJB规范来开发EJB服务器。而＋却是由
Microsoft定义标准规范并且自己实现。正由于EJB和＋采取不同的策略，因此EJB
获得了较多厂商的支持，推出了许多不同的EJB服务器，但是＋却凭借着内建于
Microsoft的操作系统而拥有较多的使用者。
目前EJB的功能规格已经发展到2。x版本，Microsoft也准备推出＋1。5版。SUN和
Microsoft推广了许多年的EJB和＋，到底这两个组件架构在业界被使用的状况如何？
两者是不是雷声大雨点小呢？
根据去年调查的结果显示，EJB的确已经开始在企业生根，已经有19。3％的企业在使
用EJB技术；另外有15。3％的企业准备开始使用EJB。这个趋势和Gartner Group对于
EJB的预测非常符合，估计到了2004年，有40％左右的企业会使用EJB。从这个现象来
看，EJB实在可以说是已经成功了，其实用性也获得了证明。台湾EJB的实用性正日渐
普及，许多的大型企业、ISV都已经开始使用EJB作为关键企业应用系统的核心技术，
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种程序语言是Web应用开发的主流。另外值得注意的是，虽然PHP最近声势不断地增
长、并且拥有Open Source的优势，但是居然只占有4％的使用率。PHP的成长率很惊
人，这在稍后也会说明，不过PHP要想在Web开发领域占有显著的地位，仍然需要多多
努力。
除了Web的开发之外，如果不注重开发工具的区别而纯以程序语言的角度来看，下图
显示的就是目前针对程序语言所做的调查统计结果，Java、Visual Basic、C/C＋＋和
C#是目前4大主流程序语言。不过下图中的C#数字是指C#在2003年的表现，而不是在
2002年的情形。
图中的调查结果，显然和我国台湾地区以及大陆的情形有些出入。在台湾，Java正快
速爬升，C/C＋＋的影响力则持续下滑，而最大使用的程序语言应该就是Visual Basic
和Object Pascal了。台湾地区的情形和大陆稍有不同，目前在大陆Java也是快速地
兴起，不过尚未形成最有影响力的语言之地位，反而是C/C＋＋仍然为大陆目前最有影
响力的程序语言，Object Pascal、Java和Visual Basic则紧迫在后。根据CSDN网站
统计的结果，目前各程序语言讨论的文章数分别如表所示。
从右边图形和数字，我们可以了解在大陆使用C/C＋＋语言的人数实在是众多，而Java
�