与Bug的斗争

半年前做的小项目，昨天突然说要拿去演示。当时抱着学习的心态，没有明确的需求，只求完成程序的功能。得知要去拿去演示的时候，我已然慌了。又遇到的一系列“诡异”的事情，我索性选择崩溃。现在究其原因，与bug的斗争中，我还是缺少一些方法论。

“诡异的调试结果一”：代码在我电脑上连接数据库成功，在其他人电脑上运行时，直接报数据库连接错误。当时就觉得不可信，我以为自己都没有写死，为何就不行了呢？后来逐步跟踪才发现，原来还是我最底层的代码有问题。主要是连接数据库服务器，如果他人电脑上安装了oracle客户端，则连接的数据库名要使用本地tns配置文件中的名称，而我以为表面上我没写死，其实在代码最底层我是写死的，因此在他人电脑上很可能由于配置的数据库别名不同而导致数据库无法连接。

这个问题当时弄的我有点崩溃。现在想想主要是我不会分析问题，或者说压根我就没有对问题进行一个分析。你像，.Net连接数据库，利用OracleClient，连不上数据库肯定是连接字符串没写对。可能包括连接字符串的格式不对或是参数不对。这个问题我觉得应该提醒自己，发现bug，先要分析bug的可能原因，有目的地去修改。

“诡异的调试结果2”：程序在我电脑上顺畅的飞起，运行在其他电脑上就直接崩溃退出。当时脑壳有点昏，只想着不对劲。而苦于我对写日志这件事情做得并不好，于是乎想不出来是什么问题。我又带有一点情绪，因为半年前程序运行时根本不会出现这些“诡异”的事情。于是乎，我改bug并没有找方法，随心所欲。于是乎就加班了。

这个问题的解决我最终通过MessageBox.Show()方法定位出来的。定位出来的结果又是令我吃惊。是fastreport初始化这一句出错了！这下我就不懂了。我程序跟的好好的啊，为什么到别人电脑上就初始化失败了？dll文件我也引入工程了哈，纠结之余，我在想难道要求别人装fastreport？这不合理，本身自己程序也没多大，还要要求人家装个别的程序。关键fastreport对于不搞开发的人员也没啥用。于是于是，我有加了fastreport的几个dll，心想着多加几个dll不管用就另寻他法。果然，奏效了。现在回过头来总结，很可能由于我引用的dll依赖于后面几个添加的dll，而我电脑上有环境，所以运行没问题。拿到其他电脑上运行就会出现找不到相关dll，因此崩溃。

其实总结来说，这次经历增加了我与bug斗争的经验。1.分析bug，估计可能的原因。2.定位bug,追根究底，探索本质。3.引入的dll可能依赖于其他dll，所以在程序中增加与环境相关的应用的时候一定要小心。总之，与天斗，其乐无穷；与地斗，其乐无穷；与bug斗，我要看看差到哪里！