解bug这事儿码农都熟悉,其中滋味谁解谁知道。
试想这样一个场景:小A入职不久,参加开发的一个新功能加班加点终于成功上线了,刚要松一口气,想着可以有时间系统性地熟悉一下产品架构和代码逻辑,这时突然接到一个serv1的bug,新上线的功能出问题了,影响部分用户使用!小A慌忙打开code分析到底哪儿不对,老板一会儿一个电话问进展如何,老板的老板也在不断向老板施压... 这时候小A那种紧张、焦虑、无辜、无助的心情可想而知,相信很多码农都有切身体验。
好吧,这个例子有些极端,这种情形不是经常发生,且不说一个serv1的线上bug不大可能让一个新人去处理的,事实上,大部分bug还是在内部测试阶段发现的,处理的压力不会这么大。面对或大或小的bug,我们应该怎么应对呢?作为一个码农,工作也有五年了,bug解过不少,也有过类似小A的经历,很多时候眉毛胡子一把抓,没有章法,甚至靠运气,这周又解了两个bug, 产生了总结一下的想法。
1. 问一个问题:这个bug真的需要解么?这可以让我们避免盲目沉入对细节的关注,通过对bug带来的风险、解bug的成本、deadline等因素综合评估,可能需要的是workaround,甚至是无视bug接受其带来的风险。当然,大多时候这是PM考虑的事情...
2. 通过bug描述和相关日志,快速的看看能否直接定位原因,有些低级的bug往往瞅一眼就知道怎么回事儿。
3. 在开发环境重现bug,如果能够做到这一点,就相对就比较好办了,debug走起,再加以耐心和细心,离胜利曙光就不远了。有时候local环境测不了,因为涉及跟其他模块的交互,需要用远程环境(如集成环境、daily build环境),可以启用java的远程debug功能,或者更原始的给代码加一些日志然后打patch.
4. 有些bug很难在开发环境重现,有的是因为运行很长时间才发生(比如内存泄露),有的是高并发情况下才发生(比如线程死锁),有的甚至是随机发生的(比如:被我们称为“诡异”的事情)等等,这种情况下,我们只能依赖日志了,根据日志去分析代码,逐步缩小范围,这个过程可能需要更详细的日志(比如每个方法的入口出口)才方便定位原因,如果可以的话,修改日志级别(比如info -> debug),然后期待bug再次发生。
5. 当我们找到原因,修改了代码,准备提交的时候,要格外小心。有时候由于时间紧迫,常规的流程能省则省,导致由于解bug引入新的bug。至少,起码的单元测试、代码review还是要做的。
6. bug管理很重要,好的工具可以把bug和对应的代码修改关联起来,可以通过一个编号追踪到bug的各方面信息,包括:详细描述、日志、RCA、解决方案、修改的代码等。
对应很多人来讲,解bug是一件令人紧张焦虑但同时又带来成就感的事情。不过,写代码还是要考虑周全少一些bug为好。有一种现象,小A写代码认真仔细追求完美很少出bug,但比较慢,给人感觉效率一般,小B呢开发效率很高,bug也很多,不过出了bug总能解老板之所急及时地修复,结果大家都猜到了,小B的visibility要大于小A,可能在奖金和升职方面更加分,你怎么看?