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