0x00 背景
春节过后，小组将许多日积月累问题的解决进度提上日程，这使得年后工作显得更为繁重。事实上，许多小问题可能经过日长时间的沉淀，演化成更为复杂的问题。产品业务极速膨胀，开发团队如何把控代码质量则显得极为重要。
今天我要回味一个bug。今天不关心这个bug是个什么问题，这不重要。修复这个bug的代码不超过10行，但前后整整用了一周的时间给予排查。从来没有花这么长时间查找一个bug，多少都有些许感叹，因此想把一些思考记录下来，警示自己。
在这之前，简单描述一下这个bug所处的位置：
· 项目中，通过源码的方式引入了一个第三方库；
· 因为架构需要，对这个第三方库进行了更改；
· 随着架构的变更，更多的人对它进行了更改。
感受一下，这真是一件很让人沮丧的事情。。。这种方式直接导致失去社区的支持，以后遇到问题只能通过内部解决了。顺带一提，引入第三方库需要注意两点：谨慎引入（必要的代码审查）以及避免修改源码（尽可能通过中间层修改）。
以这个bug作为引子，总结一些debug的想法思路，以及可能要注意的陷阱和问题。这些总结并不针对上述的bug，更多是日常debug的心路历程。想到哪写到哪，尽管不全面，但值得相互交流和借鉴。
0x01 犯错的是你，不是库
大多数时候，就是这种情况。不要对自己过于自信，更多是因为没有仔细阅读文档以及查看代码。当然了，若是抱怨糟糕的API大家还是会同情你的。
除了私有库，一个社区维护的库经过了千万人的踩坑和补坑，才有机会到达你的项目里。不要小瞧那些为库贡献代码的人，那些很容易就触发的bug，通常在第一时间就已经修复了。给点耐心，即使文档并不详细，通过多尝试几个demo以及不同的设置，很容易就能够定位问题。
当然了，对于一些出自个人开发者的库则要加以小心。除去大厂牌，其他第三方库在引入之前都应当做代码审查——至少，骨架要摸得透。
0x02 顺藤摸瓜
这可能是最常见的debug方式了。但要留意到，不同的debug姿势会产生不一样的功效。
举个栗子。现有一个函数，输入一个数据，该函数经过一系列复杂的调用栈，在控制台输出结果。就像这样：
input(data) -> a() -> b() -> c() -> ... -> -> z() -> output:"hello world"
当你发现输出与你预期不一致的时候，你有两种debug方式：在input()打个断点，一步一步往里面跟；或者从z()开始向上跟踪，看看是从哪一步开始发生了突变。
这两种方式所应用的场景并不是完全一样的。前者通常发生在想要搞清楚调用流程的情况下，这意味着，你对整个调用流程并不了解，借机通过单步调式理清逻辑。后者则常用于已经悉知调用栈及顺序，并且认定是某个函数运算出错时所用，因为此时意图很明显：查看方法栈中的每一个数据是否符合预期。
0x03 眼观四路，耳听八方
某些时候，执行器明明还在断点卡着，某一个外部变量突然就被修改了。
其实真没那么玄乎，又不是只有当前线程才能修改变量。别总是盯着你当前debug的这段代码，其他代码乃至线程也要盯好。如果你十分在意这个变量的情况，记得找出所有能够对它进行赋值（写？覆盖？随便你怎么叫）的地方。要当心各种风吹草动，可能在你debug的方法块没有任何修改，你放行了之后紧接着就被修改了。
还有！看清楚了！是不是每次调用该代码块的都是你期望的那个线程！
0x04 别人写的代码，跟你想的不太一样
“嗯。这一看就是return true。”
“奇怪。。。怎么不对”
别自以为是了，代码也许跟你想的完全不一样。特别是在排查阶段，如无必要，不要跳读代码，这是最致命的，也是最浪费时间的。
0x05 斩草除根，高可用
找到bug所在之处那当然是最喜悦不过。但切记，如果是某一个工具内部或者库出错，那么请记得修复它，而不是依赖调整业务代码来达到修复目的。至少，如果外部传入的参数不合法，工具或库应当给予警告。
特别注意。工具或库，应当被设计成高可用的，外部随意调用都不应当出错。一个普遍的错误：
public List<String> find(Data data) { int rank = data.rank(); // ... something else // return List // ... something else // return List return null; } |
在这个栗子中出现了返回null的分支。这使得调用者不得不警惕，并极为容易出错。若返回Collections.emptyList()，可用性则大大提高。最后记得，善用注解：
public List<String> find(@NotNull Data data) { int rank = data != null ? data.rank() : 0; // ... something else // return List // ... something else // return List return Collections.emptyList(); } |
