开发速度和运行速度

    毛主席教导我们，对立统一是普遍的，任何事物都有两面性,软件开发也一样,其中就存在着开发速度和运行速度的对立统一。

    有一种观点，说计算机硬件发展很快，软件可以做的浮肿一些，计算机硬件的快速能弥补这种问题。一些人反对这种观点，都拿单片机上的程序来说事。

    我是赞同这种观点的，根据我个人的软件开发经验，对于大部分在普通的PC机上面的用于信息管理的应用软件而言，是可以依靠计算机硬件的高速度来弥补软件的浮肿缓慢，但一定要有所控制，记住一定要有所控制。

    首先看看我们使用的是什么样的硬件，硬件中最重要的就是CPU了，记得以前看过一本书，里面作者提到使用一个很弱的8086时代的CPU来扫描键盘，也就几MHZ吧，他测试了一下，人们以最疯狂的速度点击键盘，CPU在两次点击间的时间中已经把键盘扫描了36遍了。大家用的CPU都不错了把，大部分已过1G赫兹吧。1G赫兹什么概念，那就是能在一秒钟内执行数于亿条的机器指令，一行C#代码怎么说也不会编译生成超过1000个机器指令吧，一秒钟下来，几百万行C#代码执行完毕了。更何况现代的CPU采用什么超级流水线，预跳转等加速手段。反正CPU很快了，内存也快，硬盘也快，而且以后会更快。

    再来看看我们要写的程序，在这里我们讨论的程序是普通的运行在PC上面的应用信息管理系统。这种程序有一个特点就是它不需要实时性，或者要求比较低，允许花费一定的时间来等待操作的处理。因为计算机的速度越来越快，但人类的反应速度是不变的，对于100毫秒，计算机在这段时间执行了几千万条指令，而人类移动鼠标并按下按键时，好几个100毫秒过去了，更何况人类操作的时候还需要进行很缓慢的思考。因此100毫秒的意义对计算机和人是不一样的，我们应当利用这个不一样来帮助我们开发软件。

    比如一个软件功能运行耗时100毫秒，过去花了1月的时间开发完成。现在复杂了10倍，我们需要花费10月来完成。但计算机硬件速度缺快了100倍，软件的运行耗时却为10毫秒。对于操作员来讲，100毫秒和10毫秒是没有区别的，但对于开发人员来讲，1月和10个月是存在巨大的区别的。此时若有某种手段，使得开发时间大为降低，比如2个月，但软件速度慢了100倍，此时软件的运行耗时不变。对于操作员这个改变是不会察觉的，但对于开发人员确是很大的利好消息。

    因此作为软件开发人员，我们可以确定一个原则，在不严重降低软件性能的情况下，我们应当更关注于软件开发速度，在一定的范围内，我们应当使用软件运行速度换取软件开发速度。

    最后来看看我们如何开发程序，根据目前的水平，不论是现在还是相当长时间的未来中，软件是不能自动生成的，我们还是手工开发软件，我们需要使用人类自然而具有的思维能力来设计程序，编写程序，所有开发工具只是帮助我们记忆当前的工作状态和减少低层次开发工作。此时计算机软件不能从根本上帮助我们开发软件。人类的思维能力有其发展速度的极限，远远低于计算机硬件的发展速度。若开发策略没有什么变化，则软件复杂10倍，我们就要花10倍时间开发，即使有各种辅助工具，这个时间也不会降多少。

    我们的软件越来越复杂了，我们程序员越来越烦恼了。我们如何开发不断膨胀不断复杂的软件？为此我们提出了很多方法。

    首先是代码重用。最开始我们没有代码重用，所有的功能都是放在一个程序中实现，然后出现操作系统数据库等系统软件，把一些底层操作集成在操作系统中，提供API函数供调用，然后越来越多的软件提供API函数，然后就是COM对象，而现在就是JAVA包或.NET程序集。这些转变，导致程序越来越慢，接口效率越来越低下，框架越来越浮肿。

    然后是计算机语言的改变。从汇编到C语言,C++, VB，然后是JAVA和C#，，那一次不是导致软件的臃肿和效率的低下。

    所有的这一些，我们都好像是在退步，在堕落。于是我们干脆也就开始破坛子破摔了。

    以前写程序，斤斤计较，不浪费一位内存，不多一条指令，现在则是有些大手大脚。

    以前我们构造精巧的数据结构，现在我们就闭着眼睛枚举。

    以前我们只调用快速而直接的接口，比如中断，API函数等，现在我们鼓吹缓慢低效的WebService.

    我们真的堕落了吗，真的变懒了吗？不是的，我们变得更忙了，更会思考了。我们知道低层次的操作大部分情况下不应当考虑，在这个软件规模越来越大的时代下，我们再过多的纠缠于底层操作是不明智的，是不以时俱进的，我们更应当关注于应用，关注于业务逻辑。但底层操作却是不得不考虑的，还好人类的集体智慧很强大，有很多框架可以帮助我们隐藏掉底层操作，比如各种COM库，.NET框架，JAVA框架，各种ORM框架。所有的框架都让我们的程序臃肿不堪，但我还是强烈推荐使用，因为这些框架能大大加快我们的开发速度，而且现在的硬件能让臃肿的程序运行如飞。

    我们程序员很多是追求完美者，在当前时代的大背景下还在过于追求软件的运行效率。比如对于调用Win32API上，言必使用C++来调用，因为速度快效率高，所谓的原生态调用，不屑于其他语言来调用API。但C++开发应用程序是比较难的，比如ASP.NET，很少有人用C++作，但用VB.NET或C#开发的ASP.NET程序调用Win32API照样运行得欢。

    在这里就谈到技术的意义了，我的观点是技术也是对立统一体，在实现过程中应当像艺术，追求完美，但它的最终目标是很现实的，就是让开发技术或使用技术的人省时省力。开发软件是技术活，得考虑这两点间的平衡。不完美或太完美的技术都不会导致省时省力。一般的，越完美的技术开发速度越慢，但运行速度越快，这就像抛物线，我们应当追求其最高点，此处我们获得最多，这就需要开发速度和运行速度的平衡了。

    在这里我提到普通程序功能模块中的一个特例，那就是图形化用户界面，对于图形化用户界面的程序，必须考虑运行速度，因为用户界面是给人看的，而人眼睛的反应速度是很快很敏感的，比大脑的思考速度和手的操作速度要快得多，因此我们必须考虑绘制用户界面程序模块的运行速度，它必须快，否则会造成屏幕闪烁，严重影响用户体验。

    最后说一下面对复杂技术难题的策略，在大部分情况下，解决多个简单问题比解决单个复杂问题工作量要大，时间长，效率低，但这个过程是可以控制的，这是正道。一些数学家证明复杂命题时就是这么干的。我们当然也可以这样啦。

    于是对于编程中的复杂问题，我们可以优先考虑把它拆成多个简单的问题来解决，这有不少好处，首先是过程可以控制，对于单个的复杂问题，我们很难解决，有时得依靠灵感，开发一个应用系统过多的依赖灵感是不可靠的，有很大的风险。但对于简单的问题我们可以根据以往的经验来判断所需的时间，这使得软件开发过程可以预估计和控制。其次是难题拆开来解决利于团体合作，一个人只能解决一个问题，若碰到难题，则项目组只能指望解决这个难题的人，但拆开来后，项目组所有的人都能参与解决这个难题，这就发挥了团体合作的优势了。虽然有时难题拆开来解决过程麻烦，运行效率下降，但这是值得的。

    总之开发速度和运行速度是一个天生的矛盾，需要平衡，调和。但在目前的环境下，我们应当更偏重于开发速度，但万事都有个度，不能只考虑开发速度，不考虑运行速度，否则这个天平就会轰然倒塌了，这对谁都不好。

    注意，本文所说的软件仅限于普通的信息管理类软件，包括桌面程序和WEB程序，无实时性要求，运行在PC机上面。对于其他的比如实时系统，嵌入式系统，系统软件等软件，本文观点不可靠。

袁永福( http://www.xdesigner.cn ) 2006-11-3