bug解决的一些方法

今天我们就来说说,程序员的日常工作之一解bug,解bug时间与正常编码时间几乎都快符合二八法则了,当然是bug占八了。
接下来笔者会围绕bug产生的原因,各种类型的bug修复方案,以及如何必免大部分bug的产生,来一探bug的真面目,希望能对您有所帮助。
首先我们来看一下,都有哪些原因会产生bug呢?以笔者经验来看,可能有如下几条:
**1.业务需求没搞清楚,这种是典型的逻辑bug,不符合基本的业务逻辑。
2.没考虑边界条件,或完全没处理边界条件。
3.马虎大意,如等号写成了赋值,少个逗号,变量引用错误等等。
4.第三方库的bug。
5.编码不一致引起的乱码。
6.ui没有自适应,引起文字超出或布局错乱
7.改了他人遗留代码。
8.自己觉得可能是个bug。
9.如果是手机应用还有屏幕适配问题等等**
简单介绍完bug产生的原因,接下来说一说不同情况下bug的修复方法:
断点调试法:这种是比较常见的修复方法,在代码适当的位置加上断点,按步看执行逻辑,找出原因。一般适用于重现步骤明确,必然出现的bug。
版本比对法:一般是切换到最后一次稳定版本,和刚产生bug的那个版本做比对,看前后代码有什么不同之处。这种适用于在稳定版本上改出来的bug,时间紧迫,调试较慢,或重现步骤不明确等情况。
打印输出法:和断点类似,只不过是断点变成了输出打印,可以输出到控制台,控制台不方便看的也可以输出到文件或屏幕。这种省去了启动调试模式的步骤,适用情况和断点调试类似。
删代码法:删去部分代码运行观察,一般会找到关键的一行,然后对该行分析,查找原因。此法多见于调试或看代码逻辑没发现问题时。
假设法:根据bug的表象,假设bug产生的条件,并通过编写假设代码,人为重现出来,并尽一步分析原因。这种适用于偶现,重现步骤不明确,但又比较严重而不能忽略的bug。
直接读代码:就是直接逐行读相关代码,仔细分析问题所在,虽然这个方法效率比较低,但有时面对一个不容易重现的bug,还是很有效的。
忽略法:顾名思义就是直接无视,适用于非常不容易重现,不影响系统正常运行的bug,但选择忽略之前一定要仔细分析定位,反复确认,不然忽略可能会埋下隐患。
更改需求法:有些bug可能是某些条件或需求没考虑,后期测试覆盖了此种情况,这种情况下,可以做些沟通看是否可以更改下需求,以消除bug。
说了原因和方案后,笔者觉的,其实大部分bug是可以避免的,因为大部分bug是马虎和沟通不善引起的,关于这个问题笔者会专门写篇关于bug产生原因和避免的文章。敬请关注!!

猜你喜欢

转载自blog.csdn.net/weixin_42811486/article/details/81236869