第十三章 软件科技的发展和Borland的未来[1]

"into the future？"

在前面的章节中，本书讨论了许多现象和问题。除了borland本身的发展故事之外，
也讨论了一些科技的现状和未来的发展。在java和.net平台的竞争以及许多科学技术
的发展下，borland的未来到底会如何呢？borland又要如何适应才能够持续在信息界
竞争、生存下去，进而茁壮成为更大的信息公司呢？在本章中我将提出一些个人的看
法。

除了软件公司的发展之外，我也观察到了一些信息技术的走向。这些信息的发展在未
来也都将牵动着开发人员的走向。除了在第10章中讨论的事项之外，我也认为更精致
化的程序开发能力、面向对象和modeling的平民化、web service的发展以及.net平
台的普及化都将在2003年开始对于开发人员产生愈来愈深的影响。其中，web service
和.net是开发人员无法控制的信息发展潮流。开发人员唯有在了解了它们的趋势之后，
及早准备以适应未来的趋势。

而精致化的程序开发能力、面向对象和modeling技术的平民化，则是属于比较贴近开
发人员的发展，也是开发人员能够掌握和进一步控制的因素，是软件人员必须了解未
来继续从事软件开发工作时必须克服和掌控的技术趋势。

到底这些因素的影响事项是什么呢？为什么它们对于软件人员在未来有很大的影响呢？
这些也是本章讨论的重点。


不都是整理和抽丝剥茧吗？

我在从事信息工作的生涯中使用过数种不同的程序语言、数据库、组件模型以及
framework。面对许多新的技术不断地出现，开发人员似乎陷入了永远学不完新东西的
梦魇。不过，如果开发人员仔细回味许多技术的本质，却会发现这些技术其实只是把
我们已经了解的东西再以更细致化的方式加以运用，关键在于开发人员是否注意到了
这些本质和趋势而已。

例如，目前在c++中流行得火热的template、policy-based template，在java、object
pascal和c#中当红的接口程序设计，以及各种组件模型和web service中的服务接口
等，如果我们仔细地咀嚼，会发现许多的东西正是发挥程序员原本就拥有的整理和抽
丝剥茧精神，再加以发挥的东西。这怎么说呢？让我们以数个例子来说明读者就容易
了解了。

首先让我们想想为什么会出现数据库这类的产品？很简单，因为由于数据愈来愈多，
数据种类也愈来愈繁杂，因此造成了我们需要一种软件产品能够整理这些数据让它们
更容易的被我们处理和使用，因此才有了数据库的想法和产品。

在每一个程序员学习撰写程序代码时，也会发现随着撰写的程序代码愈来愈多，许多
的程序代码不断重复出现和被使用，因此很自然的程序员开始使用例程(routine)/子
程序(subroutine)或是过程(procedure)、函数(function)等机制帮助我们进行程序
代码整理和抽丝剥茧的工作。

这些数据和程序代码整理的工作几乎是每一个程序员的求生本能，只是有的程序员只
做基本的整理工作，而更聪明的开发人员则对于整理的工作有不同的看法，进而促使
了许多延伸软件技术的出现，也开始对软件开发产生了重大的影响。例如，对于原本
杂乱的程序代码以数据和程序代码分离的看法而逐渐产生了面向对象的技术，以分离
例程/子程序和数据类型为看法的应用则产生了类似c/c++中的template技术，而以函
数面对服务的看法，认为开发人员应该面向服务的开发模式则造成了接口程序设计
(interface programming)的应用热潮。虽然现在这些从程序代码延伸出的技术都独领
风骚，在软件开发界中产生了重大的影响和开发模式的改变，但是，如果我们追根究
底来观察，这些技术不都是从对程序代码和数据的分析、整理和抽丝剥茧之后，以更
精致的方式来处理和开发软件吗？

因此，本着相同的想法和精神，聪明的开发人员开始脱离单一程序语言的架构而进入
了开发出可重复使用的软件组件模型，让不同的程序语言都能够在统一的组件模型中
达成团队开发的功效。这个更聪明的整理和抽丝剥茧的想法造就了corba、com/com+
和ejb等组件模型的驱动力。

除了脱离程序语言之外思考的开发人员外，另外有一些开发人员则再次回头检视本身
和他人的程序代码，并且努力搜寻优良和成功程序代码的基因，因此发现了这些优良
和成功的程序代码似乎都有着类似的模式和架构，再经过进一步的分析之后终于产生
了design pattern，这成为目前最重要的软件开发模式和技巧之一。在这之后，这些
聪明的开发人员了解到如果能够成功运用design pattern，并且把程序设计转变成以
服务为目标的方式，将更能够简化、标准化和结合design pattern的运用，并且隐藏
复杂的实现技巧，这就进而产生了service interface programming的观念和技巧。
由此可见，只要开发人员能够发挥细心整理和抽丝剥茧的能力，那么即使无法创造出
伟大的新软件工程或是软件技术，但是仍然能够帮助我们增加生产力和软件品质。因
此，对于开发人员来说重要的不是无止境地学习层出不穷的各种新技术，而是到底有
没有了解这些技术之后代表的观念、思想，以及学习最重要的对于软件开发整理和抽
丝剥茧的能力。在我的工作生涯中，一直认为技术终究是会被大多数的人学会的，但
是在辛辛苦苦地努力这么多年后，到底我们的思想、眼光和抽丝剥茧的能力是否有所
精进呢？如果没有，那么我们永远就像被蒙着眼睛，只能尾随着他人告诉的技术前进，
永远找不到自己的方向。

现在，再让我们以一个c++的例子来证明只要开发人员能够看透程序语言和技术背后
代表的真实意义，那么即使是在已经被众人熟知的技术中，仍然能够创造出新的技术
和含义。在andrei alexandrescu先生所著的"modem c++design"一书中，我们再次看
到了聪明的开发人员对于程序语言的了解和对于程序代码撰写整理以及抽丝剥茧的惊
人能力。andrei的想法不算复杂，但是却巧妙地运用了对于c++ template深刻的了解
而创造出了自己的精彩之作。其实，全书呈现的思维之妙，让读者可以从一开始的小
范例就看出如何运用已经广为人知的技巧之后呈现出的不同风貌。

例如，andrei想法是以policy-based想法为主，以各种不同的准则来提供服务函数，
那么通过c++ template的能力，让开发人员能够根据自己的需求来选择需要的policy
和数据类型，结合于c++的template，可以捉供开发人员前所未有的自由度，并且开
启了以往函数库开发人员无法想象的挥洒空间。例如，下面的程序代码中提供了三个
不同的类别，这三个类别都可以建立指定类别t的对象实例(object instance)，但是，
这三个类别各自使用了不同的方式来建立t的对象实例。在这里提供了建立t类别的对
象实例的准则create()方法，但是却允许开发人员自由地根据自己的需求选择要使用
那一种方式来建立对象实例。

由于上面的三个类别提供了相同的policy(其实，从service programming的角度来看，
可以说它们都提供了相同的服务)，因此，开发人员可以再自行定义一个consumer类别，
并且结合c++的template功能，让这三个服务类别成为客制化数据类型，再通过template
的能力，自由地被开发人员选择使用。例如在下面的程序代码中，widgetmanager
类别通过template功能可以在编译时期动态决定使用那一个policy类别作为父代类别，
而自动拥有建立t类别的对象实例的能力。

最后，我们可以再次使用template能力在编译时期由开发人员代入欲建立的t类别的
实体类别定义，通过template功能结合policy服务和各种不同的数据类型。例如，下
面的程序代码即指定了使用opnewcreator这个policy服务类别，以传统的new操作数
来建立widget类别的对象实例，并且定义成新的客制化类型mywidgetmgr：

typedef widgetmanager>mywidgetmgr;

在这个范例中，我们看到了andrei真正了解了程序语言的机制，并且经过他的思考和
抽丝剥茧之后，开创出了以policy为主的template class library。andrei的这番思
考的确为c++语言开创了新的应用和视野，这正是发挥开发人员聪颖的整理和抽丝剥
茧能力的另外一个好典范。

不过，c++的template功能却只局限于c++程序语言本身，这是因为template是c++语
言本身的特性，只有c++编译器提供了强劲支持。所以，c++的template无法在程序语
言之外和其他的程序语言合作提供类似组件模型的能力，因为其他的程序语言并不了
解template，也不支持template，这也是为什么microsoft会以com来提供不同程序语
言之间的整合，ejb则更单纯地只限定使用java的原因。

其实在上面讨论的c++ template中，仍然可以通过混合编译时期和执行时期的功能来
提供c++在组件模型和其他程序语言或是技术结合的能力，同时又能够使用c++本身强
劲的语言机制。例如，我们可以在外部使用xml作为组态文件，以指定我们想要使用
的creator以及想要建立的对象。例如下面的xml内容即指明了和前面相同的creator：
opnewcreator，以及要建立的对象：widget：

而c++可输出一个纯粹的服务接口，类似com的接口以便和其他组件模型或是程序语言
整合：

最后，在cppcreator的实体衍生类别中可以通过分析xml组态文件的内容来决定建立
何种的manager：

上述的机制可以让c/c++语言提升至组件模型和其他的技术整合的层面，又能够仍然
使用本身强大的template、policy-based template或是template函数库。当然，这
里我并不是以讨论c/c++程序语言的技巧为主，不过，上面的程序代码仍然可以进一
步使用dynamic dispatch来改善，成为品质更好的程序代码。

其实，这些想法和实现机制仍然是在使用整理和抽丝剥茧程序代码的方式来解决问题，
只是以更细致的想法重新给予程序语言或是工具新的意义并且运用在日常的开发生活
之中，有时候只要脑筋稍为转个弯就能够看到新的应用。

现在，除了在程序语言层面运用各种整理和抽丝剥茧的技术来增进我们开发的速度和
品质之外，许多人已经开始运用相同的想法在建立企业应用系统了。例如，现在许多
人已经了解desi