解bug这回事儿

解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，可能在奖金和升职方面更加分，你怎么看？