【声明：版权所有，欢迎转载，请勿用于商业用途。 联系信箱：feixiaoxing @163.com】
软件由于其特殊性，始终和bug紧密地联系在一起。没有bug的软件是不存在的。为什么这么说呢？我们知道，软件是由很多人完成的，不同的人完成代码的水平是不一样的，一旦沟通不畅是很容易引入故障的。另外软件的需求是时刻在改变的、软件的修改是每时每刻都在进行的、软件的外部硬件环境也是在不断变化的。某些软件即使现在不存在bug，也可能是因为我们暂时还没有发现而已，和软件本身是否没有bug其实关系不大。
其实，只要你进入软件开发这个行业，基本上每天都需要和bug打交道，这是不以你的意志为转移的。问题的关键是，对待这些bug故障我们应该这么做？哪些是必须完成的，哪些是有待改进的，哪些是必须拒绝的。在发现和验证故障的过程中，有几条原则是我们需要牢记的，
（1）故障的处理是需要成本的，需要优先处理那些基本业务故障；
（2）必须使得故障复现，故障必现或者有概率地复现，这样解决的可能性才会大大提高，否则极有可能没办法解决；
（3）做好故障的描述工作是一件十分重要的事情，恰当、精确的描述可以大大提高问题解决的速度，比如说
a）当前软件的版本是什么；
b）故障是否必现；
c）有没有前提配置；
d）错误号是什么；
e）故障出现前的最后一个操作是什么；
f）故障的基本现象是什么。
当然，出现了故障总要解决吧。要是故障出现了，真正的原因却一直查不到，这也是一件什么恼人的事情。就我个人的经验来说，一般只要故障可以稳定复现出来，基本上都可以解决的，但是这个中间会有一些处理效率的问题。所以，有一些简单的准则和方法是需要注意的，
（1）寻找到故障的真实原因，通过日志和二分法寻找到故障发生的精确地点；
（2）充分利用故障发生时的日志信息、内存数据、回溯堆栈和调试信息等等；
（3）掌握单步调试的技巧，关注内存数据发生的每一点变化，尤其是验证内存越界的时候十分有效；
（4）解决故障的时候，注意一并处理同类的故障的，比如相似代码段的故障；
（5）修改故障，验证代码，注意不要引入新的故障，其实这是极难的一件事情；
（6）编写测试用例，防止类似事件的发生，我自己做得也不好。
当然，话又说回来，正所谓知易行难。很多事情说说很容易，但是真正实施起来的时候往往打了很多的折扣，这也导致我们处理bug的效果常常很不理想。其实也没有什么好的方法，关键还在于我们自己要及时反省、及时总结吧。不过有一点是肯定的，好的编程习惯可以消除一批类型的故障，比如说内存、死锁、重复编译、野指针等等。愿这篇文章和大家共勉。