高效平台掀“完美风暴”

开篇：润墨网以专业的文秘视角，为您筛选了一篇高效平台掀“完美风暴”范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

名词解释

鸭子理论

将动态类型称作鸭子类型，这有两层意思。第一层意思是说，这种语言不真正实现类型 ―― 它利用鸭子理论 解决这个问题。第二层意思是说，如果什么东西走起来像鸭子，叫起来也像鸭子，那么它很可能就是一只鸭子。在编程语言的上下文中，类型意味着如果一个对象对于某种类型的方法有反应，那么事实上就可以把它看作那种类型。这样的特性可以导致一些有趣的优化。

IT界一直有一个争论：究竟是软件带动了硬件的提升，还是软件吞噬了硬件的性能。在所有变革都在悄然进行的时候，软件开发方法也在酝酿着新一轮的“风暴”。

当AMD和Intel竞争到64位的时候，已经预示了一个新的时代已经开始到来。64位CPU并不是一个新的事物，小型机上早就有了。但对于PC用户来讲，这次普及必然有划时代意义的。对于那些依赖于PC操作系统的软件开发商们，这也是一场不小的变革。

平台之争

从布鲁克斯那个精彩的”没有银弹”论断诞生之日开始，无数IT精英们都在使用自己的方式来提高软件开发效率。很多系统提出的时候，都是高呼着“高效的生产率”上台的。

其中，呼声最高的是.Net。号称软件开发效率能提升10倍。在.Net会上，微软使用了很多案例来证明这点。.NET提供了非常好的开发框架，这点对于以前进行Web开发来讲，是一个大大的革命。另外.Net还在此基础上，提供了丰富的类库支持。更加提升了开发效率。

谈到.Net，就不能不谈Java。Java和.Net一样，也是运行在一个虚拟机上。不同的是，Java不提供本地化过程。在Java所提倡的开发效率是:“一次编写，到处运行”。但是，在很长的一段时间中，很多人认为Java的运行效率低。因此不适合开发桌面应用。这在很大程度上限制了Java的普及。但是在一些高性能的服务器上，Java的优势却发挥的淋漓尽致。开发商充分利用J2EE等优秀成熟架构，来部署稳定、高效的应用服务器。现在电信业几乎都是使用J2EE架构。

另一个呼声很高的是动态语言。现在最火的是PHP和Ruby语言。

我们知道，编程语言的发展是从最基本的二进制CPU语言开始，发展到汇编语言，进而发展了高级程序语言，这些一般是说C、BASIC、Pascal等。随着软件工程的规模扩大，慢慢发展起来的软件工程方法，开始影响着语言。这里面最大的就是面向对象概念的提出，导致了大量的支持对象概念的语言出现。最有名的就是C++,Delphi,C#,JAVA。

以非常有名的“鸭子理论”提出来的动态语言。也是高呼“生产率”，吸引了很多开发者。可是，它也是遭遇了运行效率的问题。引来很多争议。

历史总是有惊人的相似，每一次软件方法的发展，都伴随着性能争议，每次都带动了硬件的发展。而硬件的发展，又为软件方法的的发展铺平了拦路石。不管谁是鸡，谁是蛋。重要的是，这是进化的鸡，进化的蛋。进步才是最重要的。

当我们在谈论硬件性能被软件吞噬的时候，软件工程已经发展到了空前的高度。我们现在已经不可以想象，如何使用汇编，编写一个简单的应用系统。现在的复杂度，已经迫使我们使用更高层次的抽象，对系统进行高层次的架构。可是每一次抽象，都意味着不同程度的运行性能降低。汇编抽象出指令是这样，C抽象出语言是这样，C++抽象出对象是这样，Java抽象出虚拟机是这样，Ruby抽象出类型也是这样。.Net抽象的时候，针对这个性能问题，又提出了一个本地化（在本地进行编译）的概念。这是一个好的想法，可是对于抽象本身并没有帮助。

每次好的思想都能将运行性能的拦路虎打败。这些除了依赖于硬件性能的提升，更是基于人们解决问题过程中对于新思想的依赖性。

我们在抱怨软件吞噬硬件性能的时候，其实正是我们遇到新问题的时候。硬件的发展总是有它发展的需求所在。在这个时候，我们不是抱怨，而是要正视这个发展趋势。

追求高效的梦想

软件开发商对于开发效率的追求远远高于运行效率。因为开发效率就是开发成本。但是客户的体验又是软件开发商必须考虑的方面。如果客户不满意，那么再好的办法也值得商酌。在这两者之间来回权衡，是一件痛苦的事。好的方法能带来高的生产率，但是却暂时不能使用。

64位软件开发，对于应用软件开发本身来说，并没有多大的变化。这得归功于微软的不懈努力，以及各大硬件厂商在兼容性上的考虑。CPU的X86架构当年从16位转换到32位的时候，就非常明智地选择了一条兼容16位处理器、逐步推广32位处理器的发展路线。与当时架构虽然好，但是却不兼容16位的RISC架构来比，兼容最终笑到最后。RISC最终也只能被被市场淘汰，在一些细小局部应用。

这次从32位到64位的转换，也是遵循着兼容的原则。所以大部分32位上的应用软件都是可以顺利运行。除非调用了依赖于32位的硬件驱动。

表面上，64位编程和以前不存在什么差异。这也正是容易误导我们的地方。技巧的表象，容易让我们忽略技巧背后的方法变革。在运行效率不再是问题的前提下，一些人会慢慢尝试使用具有更高开发效率的思想和方法，而不再拘泥于原有的方式方法。

在.Net刚的时候，大家的普遍想法，都是.NET适合进行Web开发。而原来的Win32平台上的应用开发，不如使用原生的语言（如C++/Delphi）进行开发。Borland公司也正是看准了这点，推出适合原生Win32开发和.Net开发的Delphi2006，两种方式同时提供。

可是，这种方式并没有被大家接受。大多数开发.NET还是选用了Visual ，而原本在Win32下开发的，还是用Delphi。这说明这两类选择正在分化。随着CPU速度的提升，性能不再是那些选择Win32原生平台开发所需考虑的问题的时候，选择.NET几乎是必然的。这样开发成本会降低很多。最大的成本就是不需要招聘两类语言的开发人员。这对软件开发商是一个非常大的诱惑。

很多PHP和Ruby的追随者，都是奔着“高效”去的，不是运行效率，而是开发效率。除了前面讲到的鸭子理论。动态语言中针对元数据（MetaData）的编程能力也是非常强的。简单点说，就是让代码编写代码。减少程序员的人为因素本身就是提高开发效率。

增加复用是提高效率的本质所在。最基本的是这些动态语言提供了丰富的类库，对于业务逻辑的最大程度的复用，也是动态语言提供的方式之一。这点Java语言也学习过来了。利用IoC实现的Spring框架就是利用这些特性来做的。Java在提高开发效率方面，很是不遗余力，很多动态语言方面的特性，都在后续版本中加进来了。

这几年炒的MDA的概念，在某种程度上也是因为没有令人满意的实现，在推广上没有大面积推开。在这方面，Borland公司提出的ECO概念比较先进。相信随着PC机器性能的提升，在应用软件的开发领域，必将能够好好利用起这个技术。

其实，很多概念并不是新鲜的，也不是没有成熟应用。只是很多技术都需要高性能的服务器做支撑。所以在一般的应用软件领域很难被广泛使用。因此，随着以前只有小型机才有的64位CPU安装到普通的PC机上，很多原本只能在小型机上的技术都可以移植过来。这个正如军事领域的技术应用到民用领域一样。飞机原本都是军事领域发展高端技术，后来应用到了民用航班，带给我们的变化是巨大的。PC的发展更是这样。

很多技术都和64位本身无关，可是这些技术又都是依赖于高性能的CPU才能茁壮成长。如果只是看到64位技术本身，对于应用软件领域的开发来说，确实没有多大影响。

这又得提到开篇的那句话，到底是谁促进了谁。硬件的性能提升让软件方法也可以发生变革。新的方法又使硬件的性能优势不能体现，促使了新的硬件技术发展。如果我们现在还在使用DOS，还在使用Windows95，你根本不需要购买现在市面上的任何档次的硬件。任何一个可以找到的配置应对这些应用都是绰绰有余。