程序员新人，如何在复杂代码中找 bug？

清华大佬耗费三个月吐血整理的几百G的资源，免费分享！....>>>

首先，从bug入手，了解codebase，应该是平衡mentor和新人之间利益最大的办法。其实要想入手最快，就应该是让mentor24*7的在你旁边手把手教你，但这根本不现实，也没有意义。

修改bug入手，通过一个个小bug去了解整个project的结构和design pattern，对新人来说，这种学习既直观又不会被复杂的代码吓死。最主要的是，当你成功fix了一个bug，这种成就感是一个新入职的程序员勇往直前的动力。而且，修了一个bug，最重要的不是你unblock了多少人，或者帮助了多少用户，而是你从这个bug里看到了project怎么样的结构。当初为什么这么设计，为什么会出bug，时不时codebase里还有类似的bug，以后怎么避免。

几点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掩盖一些奇怪的崩溃。不到万不得已不要这么干，未来可能会付出更大代价。

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

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

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

文章整理于【知乎】

图片来源于【网络】