保证程序可预测性

      设计程序的时候，如何保证可预测性呢？答案就是我们上面所说的，所有的代码必须是经过测试的，必须是一步一步调试过的。只有经过你调试过的代码，你才能知道这个代码做某种运算的时候，它是怎样的执行方法。如果你不知道它的执行方法，你没进行过调试，则你就没有任何预测性。要达到可预测性，代码在汇编级是怎么执行的，你都得非常清楚。代码对哪个部分进行了什么操作，你都得知道。如果达不到这点，你的可预测性就很差。

比如，有些程序，你看它的C或者C++的源代码时，都看不出任何的问题。你看静态的程序时看不出任何问题，动态的程序调试你也看不出任何问题，这时，你必须把它的汇编打开，看一看它具体的操作，才能知道。所以说，开放性思维非常重要，你必须从最低层到最上层都要清楚。VC本身提供了一个汇编的调试环境，但是打开汇编后，如果你都看不懂，那你说怎么调呢？调什么？如果一个程序经过调试出来，则它会出错的地方你马上就会知道，只要看一些表现，就知道它有些什么问题。

比如说，我们做“大眼睛”的时候有个这样的现象。当要显示一个很大的图的时候，屏幕上只能显示其中的一小块，这样就可能需要拖动整个图像，但是拖的时候，如果在Windows 2000或Windows XP系统下就会发现，一旦我将图像拖到右下角时，图像就一下到左上角去了。该图像在右下角没有到底的时候还是显示正确的，但一旦到底，就把右下角转到左上角去了，如图1.2所示。

这是怎么回事？在Windows 98和Windows 95下，从来没有这个问题，而且如果图像不到右下角这一行，只差一点，它也不会出现这样的问题。为什么在Windows 98下没有这样的问题，在Windows 2000下会有呢？难道是我的程序有问题？

图1.2  图像显示问题示意图

这时，我就做了一个区域的比较，即看这个区域和整个这个图像的区域，是否中间运算有错误。但程序是调用Windows本身的API，我就怀疑是不是这个API出问题了。于是又重新写了一个区域相交部分，一步一步去查它，也没有任何问题，在任何情况下都是好的，但是到达右下角时，图像就会翻过来。经过以上两个步骤后，我就能确定，这是Windows操作系统的问题，Windows 98下没有这个问题，Windows 2000有，Windows XP也没有改过来。这是操作系统的原因，绝对不是软件的问题。

为什么会出现这样的问题？这是因为微软设计系统的那些家伙自以为聪明。只要图像的左上角是0，不管三七二十一，肯定往下面放，但是它的图像是正向位图，所有的位图设计的时候是倒过来的。而一个正向位图的高度是负的，否则它显示的时候是倒过来的。高度是负的时候，这个0发生了变化，从上向下的，那么他设计操作系统的时候，只看了0而没去看高度，这时他没做条件处理。他的想法是为了加速这个位图的速度，是做优化的结果，但结果就出错了，而到现在他也没有解决这个问题。

所以，可预测性在这里就显得很重要了。当出现这个问题时，能想到要么就是区域合并有问题，要么就是直接显示的这个函数有问题。区域合并的问题可以解决，我写个函数还不行吗？我一步一步地去跟踪，就能肯定这个API有没有问题，最后得出结论是有问题，也的确是它有问题。如果你不会调试的话，这个问题你永远也查不出来；如果你不了解操作系统，你永远不会想到操作系统会出问题；如果你不了解这个平台，你根本就不知道问题所在。所以，要成为一个高手，视角一定要从里到外，从点到面非常开阔。如果你局限在一个封闭的思维里，做系统就很难。

评论