• 15
  • 7月

今天升级了下wordpress,发现多了一样功能“加速器”,试着启用了一下,先转到Google的网站,给FireFox中安装了一个Google Gears插件,然后让它从我blog上下载了211个文件下来。换来的结果是后台管理界面的打开速度明显提升。

研究了一下这个东西的原理,其实非常简单,不过是把网站上用到的静态文件(html、css、js及图片)全部下载到本地机器。到用的时候直接从本地读取。对于我这种使用国外主机的用户,加速效果那可是非常明显。

这一下子让我想起了两个软件开发中及其常用的名词:B/S模式和C/S模式。在这次升级之前,wordpress是一个“标准”的B/S(浏览器/服务器)应用程序。所有的操作都必需使用浏览器从服务器下载相应的页面,并在服务器提供的网页中完成工作。而相对的,像QQ这类传统的C/S(客户端/服务器)模式应用程序,需事先在客户端的电脑上安装对应的软件,操作界面基本是由存储在本地的软件生成,与服务器交换的仅仅是内容数据。但现在“加速”后的wordpress以上两条都沾了边,又都不完全是──页面是事先下载到客户端的,但使用的依然是浏览器进行操作。那些动态页面还是得从服务器获取。

事实上,这不过又是一个解决网络软件布署/更新的及时性与易用性这一矛盾的方案。

最传统的C/S应用优点在于程序在客户端安装执行,功能强大,反应迅速,只要使用者的电脑不至于过于古董,使用时只有与服务器交换数据的那一丁点时间会让人等一下,而且这点等待时间还可以通过使用多线程,后台预读取等技术被完全消除掉。但其缺点也产生于它的客户端,每当系统有任何升级,必需下载安装新版的客户端软件。布署时很不方便,而且难以保证客户端完全、及时地更新。

而B/S模式则完全抛弃了客户端,一切都是浏览器从服务器上现下载。只要服务器更新了,使用者用到的一定是最新版本。但限于浏览器的功能,B/S软件使用起来往往不那么方便,而且一旦与服务器之间的连接不那么高效,B/S模式的反应速度就会极其让人不爽。近年来兴起的Ajax技术虽然通过javascript后台异步传输及对浏览器功能的挖掘,使得B/S软件用户友好度有了极大的改善,但动则几十上百K的javascript框架文件和一大把的图片还是让人每次进入时等上老半天。

对于这一对矛盾,其实很多公司都推出过自己的解决方案。最早的可能是Java的applet,用它可以在浏览器中执行Java程序。然后有微软.net中的ClickOnce部署,实现了客户端软件的自动更新,而且程序员不需要为其多写半行代码。另外Sun还发布过一个Java Web Start。但由于这些方案都需要在客户端事先安装一个体积庞大的运行库,它们都没能在互联网上流行起来。

这两年随着Web2.0的兴起,又有一些崭新的解决方案出现在了我们面前:Flex、JavaFX、Silverlight、Adobe Air、Google Gears…不管它们的宣传是如何地花哨,把自己的功能吹得有多神奇,其根本目的都还是一致的──为用户提供更好的易用性,同时保证程序能被及时更新。

所以,作为一名软件开发人员,在为这些新技术兴奋的同时,不要忘记我们的根本使命:为客户提供高质量的问题解决方案。只有新技术能比原有技术更有效地解决问题时,才应该使用它。而更有效的评价标准包括效率、稳定性和安全性等很多方面。我们不能因为新技术更炫、更酷就去追求它。软件技术的创新一浪接着一浪,你不可能永远处于浪尖之上。

一句老话:不管黑猫白猫,抓得到老鼠的就是好猫。

此文与不断学习技术的同学共勉。

PS:刚升级完就发现了wordpress2.6的一个Bug──新增的字数统计功能不会算汉字。我写了这么半天才显示有17个words…

您可以对这篇文章发表一条评论,或者在您自己的网站中引用 (Trackback) 它

发表一条评论

所有标签:.net Ajax Java javascript Linux map MySQL RSS TD-SCDMA Ubuntu vim web Win7 乱码 基础知识 备份 奥运会 希望泉 性能 缓存 编程