Debug 的一些经验

[gy134340]

这篇 blog 是对过往 debug 的经历做一下总结。

Make it reproducible

靠猜去解决一个不能复现的问题只会浪费修复时间，靠 hack 的方法修复问题却不能最终定位问题，无意义。

"最小"可复现

一定要尽力尝试最小的那种可复现方法，在一个极其复杂的代码库中改代码，各种业务掺杂在一起，很容易导致一种情况，我简单的注释 if else 的一种情况，或者说在一个组件下把其他不相干的代码都注释掉

系统极其复杂，各种可能的原因都可能导致这个问题，我注释掉”几乎“所有可能出问题的地方，这个问题还是有怎么办。这里的一个经验是，把这段代码”拿出去”，放到一个单独的地方去，这也是很多 Github 上很多仓库的 owner 希望提 issue 的同学的做法，类似的线上工具有很多，比如 https://jsfiddle.net/ 和 https://codepen.io/。

作为 web 开发者是幸福的，可以轻易的通过一个链接就可以拿到一个可复现的 bug。

二分法

如果从各种 debug 的经验中选择最重要的一条，那我一定投这条一票，基本上我们日常开发中，无时无刻不在应用这个方法，软件的复杂度是无限的，而人的理解力是有限的，这样可以在一堆逻辑中迅速通过指数级的速度降低复杂度找到问题。

举一个关于应用二分法的实际例子，大部分的业务代码是一个大仓，每天都会有人往这个仓库 merge 代码，这样我稍微隔个几天更新下代码，发现本地的仓库跑不起来了？

这里我完全可以通过一个 git 命令 git bisect 来操作下，这个命令简单来说就是在很多个 commit 中通过二分法迅速找到有问题的 commit。

---

另外推荐书，《调试九法.软硬件错误的排查之道》 。

豆瓣链接 https://book.douban.com/subject/5376270/