1、放大现象,有些bug现象不太明显,那么就想办法增大它的破坏性,把现象放大.这只是个思路,具体怎么放大只能根据具体的代码来定.比如:美剧《豪斯医生》里有一集,怀疑病人心肺有问题,就让病人去跑步机上跑步,加重心肺负担,从而放大症状.烟台IT培训班
2、二分法定位,把程序逻辑一点点注释掉,看看还会不会出问题,类似二分查找的方法,逐步缩小问题范围.
3、模拟现场,有时候我会问自己,如果我要实现bug描述的现象我要怎么写代码才行?比如:我遇到一个死锁问题,但是检查代码发现所有的锁都是配对的,没有忘记解锁的地方,而且锁很简单就是一个普通的临界段,保护几行赋值语句而已.这样的代码怎么写才能让他死锁呢?我想如果让我故意制造这样一个现象,只有在上锁的时候强制杀掉线程了,既然这样就可以去看看有谁强杀线程了没有.
4、制作工具,针对某些bug编写一些调试辅助工具.比如,我那个系统没有完善的崩溃报告,虽然也有dump,但是分析出来的callstack经常不准.于是我为解决崩溃问题编写了个工具,会自动扫描代码,在每个函数入口和出口插入log,以此来定位崩溃点.
5、掩盖问题,虽然这样做有点不厚道,但是有时不得不这么做.有些bug找不到真正的root cause,但是又要在规定时间内解决,那么我们就可以治疗症状而不去找病因.比如用try catch掩盖一些奇怪的崩溃.不到万不得已不要这么干,未来可能会付出更大代价.
减少 bug 的第一步,是提升自己的程序员素养,努力不给自己和别人找麻烦.
程序员新人怎样在复杂代码中找bug?
另外,团队协作也很重要,前期的技术方案和设计评审、代码审查,对减少一些重大的错误和弱智的 bug 都非常有好处.
与几个有经验的程序员一起评审一个技术方案,常常会发现一些重大的问题,比如为什么用缓存,为什么做持久化,高并发下怎么应对,这部分设计支持线程重入吗,这个循环为什么设置成10分钟,这个超时设置为什么是60秒,传输协议加密了吗,等等.很多方案可能会仅限于解决当前的问题,但有经验的程序员却能透过时间的重重迷雾,发现这个方案在未来某个时间点可能爆发的问题.这就是评审的力量.
更多烟台IT培训班相关资讯,请扫描下方二维码