那些该死的bug，上周，我基本上整整修了一周的bug。其实，这些年一直在做移植，所以总是碰到很多很多的bug，然后年复一年，日复一日的修复。现在，我已经不想懒的解释这些bug是如何产生，因何产生的了，事故发生之后，互相指责显然是于事无补的，首先的是，如何解决这些该死的bug。
我想说的是，不会修bug的程序员不是好的程序员。在遇到bug的时候，第一要做的事是停止工作，修复bug，而不要因为工期紧张拖着不解决。如果你像我一样，碰到的不是自己的程序，这个更是首要前提，往往一个bug会引出很多莫名其妙的问题，所以，在引起更大的轰动之前，先将它消灭掉。
不要惧怕bug的数量或等级。上周，在指定的最后一天的最后一个下午，我的项目依然出现了几个被标定为A(最高等级)的bug。想一想，在最后的两个小时内，依然存有这些bug，将会意味着什么。这个时候千万别慌。分析下bug的状况，仔细的观察，越仔细越好，以我的项目为例，检测部门给我的报告是在某种操作的情况下，可能会出现内存不足黑屏。我按照他们的提示操作了一遍，没有出来，两遍，没有出来，后来将程序产生的记录删除掉，重现了bug。然后重复操作，100%确定，但我认为，记录不会产生任何问题。然后添加调试代码，看看屏幕上显示的当前状态是什么。然后，发现状态不对了，跳转到我的一个未处理的状态中了，整个代码搜索，修复。
从上述的例子也可以看到，看到的，感觉到的也可能是表现给你的一些迷惑。但要相信一点，计算机是不会出错的，程序计算的结果永远是对的，错的是你的程序，你的代码。但从另一个角度来说，种什么瓜，得什么果，你要想得到想要的果，就要种对瓜。幸运的是，程序可以测试，bug总是可以重现。还是上面的例子，在上周四的样子，大概报了我N个bug，ABCD几乎应有尽有，别人觉得这个项目要悬了，这么些个bug啊。我首先简单的将这些bug进行了分类，确定修复的优先级，当然，其中一些明显的问题，但可能优先级并不高的内容，但却又容易修改的问题（比如文字错误之类），在查看的过程中，就顺便修复了。然后去按照优先级，排个时间表去调查，比如某某bug为A，某某为B,怀疑原因为内存问题，这两个一并查，需要时间最多为半小时，就这样一一安排。但在执行的时候，可能并不能按照计划完全执行，可能有些需要的时间长了，有些需要的时间则短了，长了的问题必须设定一个上限，最长时间。在我的项目中，发现程序所需的内存不足。但从哪儿可以找到临时不用的内存呢？图像，不可能，数据，也不可能，图像格式，时间需要的较多，效率可能不好，修改也可能较麻烦，扩展接口？自己不熟悉，而且，最占用内存的是图像，这部分能否如期进行还是问题。然后我总结了一下，列了几个方案，回家睡觉去了。
是的，我回家睡觉去了，有些内容需要额外的时间，谁也没有办法的事情，在目前的安排之中，不管如何就是没有办法如期进行，我所做的就是，为延期做准备，为延期负责，但在我回家的路上，听着地铁里面烦杂的声音，声音，我为什么没有想到声音数据呢？刚开始的时候，为了防止声音的切换出现中断，我将所有的声音数据全部扔到了内存中。然后，第二天，我将声音数据只有在使用的时候才加载到内存中，然后不用的时候再卸载掉，内存问题解决了。
因此，在我们繁忙的时候，在我们盯着一个点使劲的钻牛角尖的时候，也应该稍稍中断一下，回忆下美好的细节，看是否能有其他的出路，上述时间的安排上也可以为了这点考虑。
但实际上，在很多的时候，项目中的问题大都可以采取更好的检测的方法，并不像上面提到的类似心理分析的方法。在某年，同事碰到的一个问题，项目在运行大约半个小时的样子，会出现错误，陷入死循环，但什么地方出现问题就是查不出来。我查看了代码，里面有几个数组，从java代码转换过来的，看了下数组的使用方法，非常整齐规矩，只有几个地方有些不太一样，然后，将代码改为C++代码，顺便一说，C代码改为C++代码非常的简单，就是改下文件的后缀名而已，然后，将代码中的数组用数组模板替换（之前的java数组模拟的代码），然后，实现重载[]的函数，添加调试信息，在异常的判断中下个断点，然后就开着，等待bug的重现。接下来就简单多了，很简单的就找到了数组下标越界的地方，然后修复，整个过程几个小时之内搞定。
上述的方法适用于数组越界，一个经常看到的问题，要说更容易出的问题，可能要数内存泄漏或者内存非法访问吧，内存非法访问基本上就不用多说了，很多情况下都是直接爆掉的，然后停在爆掉的地方。内存泄漏是个麻烦的事情，但如果你在这个网站往前查看的话，会看到内存监视的代码，所有未释放的内存都会被监视出来，然后就是找在什么地方new或malloc了。因此，在合理的地方使用合理的工具也是很重要的。
还有就是要重视别人的提示，我上周的项目有一个问题就是这样的解决掉的。测试人员发现在某个地方有一张图片显示不正常了，也不是每次都出来，但每次将记录文件被清除掉的时候，基本上肯定可以出来。但那个地方应该不需要额外的图像，我告诉她说，如果能告诉我那个地方应该显示什么，告诉我点线索，这样修复就比较简单了，否则，全代码的查看，非常的费时，费力，更容易引起别的错误。然后她说，在原始的版本中，有一个提示，在我的版本中，没有发现什么提示，会不会因为这个错误。我回忆说，我发现那些提示的图像确实使用了，但我不知道在何种情况下使用，但我可以查看一下。然后我就发现在加载的时候，我使用了错误的图像，错误的尺寸。然后问题就修复了。
以上基本上就是我这些年制作项目所获得的经验，之所以一直拿最近的项目做例子，一个是因为记忆比较清晰，另外一个是这个项目经过了十多个人的努力，每个人又都自以为是的增加，强制的修改，也由此引发了各种各样的问题。虽然最好的解决办法是在开始，是项目管理，但你不能指望你所遇到的主管都可以像你那么熟悉这些技能。好的项目从好的构思开始，坏的项目则从错误的尝试中盲目前行。