debug记录曾经解决过的bug,并简历索引其实很多bug

我曾在 360 带领过数十个技术团队,同时开发多个业务线。在参与的产品中,日活过千万的产品有一款,日活过百万的有三款。

在这个过程中,我看到了很多奇怪的Bug,我都一一解决了(不然我估计我就滚蛋了)。

在这里分享我的调试经验,希望对你有用:

1.尽可能详细的记录

编程界有一句话:必须出现的Bug不是Bug。

因为容易重现,所以容易解决。代码已经跟踪,或者通过查看堆栈信息,可以快速定位问题。

真正困难的是偶尔出现的错误,即使是有千分之几的机会,但后果严重的错误。要解决它们,你需要详细的日志,尤其是关键点的信息,这一点非常重要。

2.谷歌很好

Programmer + google = 好程序员千行代码bug率合理性,这句话说的很对,技术bug很多,不知道的时候不如google一下,可能很多人都遇到过。

当然,最重要的是搜索关键字,这取决于你对bug现象的描述。搜索越简洁全面,您会找到越多的信息。

3.排除

这个方法老实说不推荐,但是经常在手忙脚乱的时候使用。用法也很简单。当你不确定哪一段新代码引入了问题时,尝试删除部分代码,看看程序是否OK。

如果不行,换成另一部分代码删掉,很快就能缩小bug搜索范围,定位问题所在。

4.模拟用户环境

首先,可以使用一些工具来模拟前端或后端来创建假数据和假操作。一旦你有了这些工具,就可以模拟你怀疑的问题,看看它是否会出错。

其次,如果遇到一些极端情况,比如疑似多线程/多进程死锁,不妨在某个进程/线程中写一个无限循环,看看是否出现bug。当然,这样的操作数以千计。不要忘记,提交,就结束了。

5.记录已解决的bug,并恢复索引

事实上,许多错误会以不同的模式反复出现。俗话说,好记性不如烂文。记录已解决的问题并做一个索引。下次遇到同样的问题千行代码bug率合理性,先搜索一下。找到答案了。

6.查看更多官方文档

特别是引用第三方代码或开源代码引起的问题,请反复查看官方文档的相应部分,可能会解决问题。

7.引入放大问题的工具

比如很多线程注入工具,你启用后,所有依赖线程顺序的bug都会从偶然变成不可避免。

这相当于主动将代码运行环境转为地狱模式。比如你的一个线程的结果依赖于另一个线程的输出,但是你忘记添加同步代码,但是大多数情况下,另一个线程运行得很快,但是有些机器就是不工作。

这个工具就是在这个时候加入的,在某些情况下会直接让另外一个线程跑的更慢(我猜大概率是加了一个sleep(1000)),结果你的程序会crash。

这是好事,直接打开crash堆栈,问题很快解决!很开心~

以上7点都是在实战血腥过程中总结出来的,希望对大家有所帮助。

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论