程序员如何在复杂代码中查找到程序的bug?

javaEE 专栏收录该内容
58 篇文章 0 订阅

最近在挑选更合适的物品来兑换,请牛牛们不要着急。

程序员新人怎样在复杂代码中找 bug?

姚冬,程序员:

我曾经做了两年大型软件的维护工作,那个项目有10多年了,大约3000万行以上的代码,参与过开发的有数千人,代码checkout出来有大约5个GB,而且bug特别多,open的有上千,即使最高优先级的showstopper也有上百。

分享下我的debug的经验

1. 优先解决那些可重现的,可重现的bug特别好找,反复调试测试就好了,先把好解决的干掉,这样最节约时间。

2. 对于某些bug没有头绪或者现象古怪不知道从哪里下手,找有经验的同事问一下思路,因为在那种开发多年的大型系统里,经常会反复出现同样原因的bug,原因都类似,改了一处,过一阵子另外一处又冒出来,而且无法根治。
比如:我那个系统里有个特别危险的API,接口参数比较难用,一旦有人用错了某些情况下就会出诡异的现象,解决很简单,找到调用这个API的地方把调用方式写对就好了。为什么不根治呢?因为要保持兼容性不能改接口了。Windows系统里就好多这种烂API。
问下老员工吧,说不定他们都遇到过好多次了。

3. 放大现象,有些bug现象不太明显,那么就想办法增大它的破坏性,把现象放大。这只是个思路,具体怎么放大只能根据具体的代码来定。
比如:美剧《豪斯医生》里有一集,怀疑病人心肺有问题,就让病人去跑步机上跑步,加重心肺负担,从而放大症状。

4. 二分法定位,把程序逻辑一点点注释掉,看看还会不会出问题,类似二分查找的方法,逐步缩小问题范围。

5. 模拟现场,有时候我会问自己,如果我要实现bug描述的现象我要怎么写代码才行?
比如:我遇到一个死锁问题,但是检查代码发现所有的锁都是配对的,没有忘记解锁的地方,而且锁很简单就是一个普通的临界段,保护几行赋值语句而已。这样的代码怎么写才能让他死锁呢?
我想如果让我故意制造这样一个现象,只有在上锁的时候强制杀掉线程了。
既然这样就可以去看看有谁强杀线程了没有。

6. 制作工具,针对某些bug编写一些调试辅助工具。
比如,我那个系统没有完善的崩溃报告,虽然也有dump,但是分析出来的callstack经常不准。于是我为解决崩溃问题编写了个工具,会自动扫描代码,在每个函数入口和出口插入log,以此来定位崩溃点。

7. 掩盖问题,虽然这样做有点不厚道,但是有时不得不这么做。有些bug找不到真正的root cause,但是又要在规定时间内解决,那么我们就可以治疗症状而不去找病因。比如用try catch掩盖一些奇怪的崩溃。不到万不得已不要这么干,未来可能会付出更大代价。

我在做这份工作的时候也在追美剧《豪斯医生》,豪斯大叔解决病症的思路和debug差不多,对我很有启发。

Kenny Lang,热血软件工程师 / Googler:

同为刚毕业的新人,入职快6个月,非常理解楼主的问题。关于怎么找bug的问题,有人已经回答的很全面了。而且,其实最应该回答这个问题的应该是你的mentor。

首先,从bug入手,了解codebase,应该是平衡mentor和新人之间利益最大的办法。其实要想入手最快,就应该是让mentor24*7的在你旁边手把手教你,但这根本不现实,也没有意义。所以从修改bug入手,通过一个个小bug去了解整个project的结构和design pattern,对新人来说,这种学习既直观又不会被复杂的代码吓死。最主要的是,当你成功fix了一个bug,这种成就感是一个新入职的程序员勇往直前的动力。而且,修了一个bug,最重要的不是你unblock了多少人,或者帮助了多少用户,而是你从这个bug里看到了project怎么样的结构。当初为什么这么设计,为什么会出bug,时不时codebase里还有类似的bug,以后怎么避免。

别觉得不好意思去问你的mentor。他也许很忙,但他既然是你的mentor,就有义务帮助你平稳度过最开始的几个月,(而且,往往你的成功可以直接证明他的领导力强大)如果觉得过意不去,就多向你的老板/他的老板讲讲你们的事情。但是,一定要问有意义的问题。其实很多时候,如果你再多深入地看一页code,再多搜索一次别人写的wiki或者文档注释,就可以得到解答。这种问题,既浪费别人的时间,也不会让你养成深入思考和探索的习惯。久而久之,有事没事去问mentor就取代了你自己思考的过程。

mentor再牛,也不可能手把手的教你。但他可以教你的,是学习的方法/习惯、debug的方法/习惯、以及写code的方法/习惯。认真观察他的思路是怎么建立起来的,认真学习他是怎么debug的,认真看他是怎么涉及结构的。学会了,你也就出师了。

善用debug工具。不要小瞧debugging的过程。我真的见过已经是很成熟的程序员还在用二分法println debug。这不科学。。。尤其当你的project 变得很大,每次build就要好久,这样特别浪费时间。(尤其android)。设置break point和写有针对性的unit test必不可少。虽然又时候必须要看log,但有很多超级好用的debugger,稍微花时间去学习一下怎么用,或者看你的mentor怎么debug,会大大加快你的效率。(我曾经见过我的mentor用chrome debug。真的是觉得帅爆了!目瞪口呆”

其实新人很多时候都会觉得程序某个地方很“神奇”,明明应该这样,但却那样。千万不要跟你的mentor抱怨“神奇”,因为这两个字在整个代码行业就不存在。我的老板经常给我讲的一句话是,“code never lies”。代码运行异常,一定有运行异常的原因。不要揪着“为什么是这种异常”不放,而要去想“什么样的结果是对的”以及“怎么产生对的结果”。

学习framework。project变大了,framework必不可少。但因为framework的存在,让整个project变得更“捉摸不透”。所以,花点时间学学你们用得framework,以及针对这种framework debug的工具,静下心看看文档,自己在动手写一写,其实framework真的很美。

最后,时刻保持跟你mentor之间的sync up。让他知道你的困境,也让他知道你的成就。mentor也是从新人走过来的,没什么不能讲的。

我最绝望的时候是在入职两个礼拜。自己拿到了一些bug,也有了starting project。当时觉得自己对着电脑就像看着又大又丑的金刚。我也听说这个过程所有人都有,就算从别的公司跳过来、再资深的工程师,面对一个成熟的project,也都要花时间学习,经历失败、绝望。所以,没必要灰心,也没必要过度担心自己的表现。大家对新人的期待都很现实,所以稍微超出预期,就会得到很好的反馈。

祝题主顺利度过开始的几个月,逐步步入正轨,享受工作。

  • 2
    点赞
  • 0
    评论
  • 4
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值