#优质博文 #调试 #方法论
断点单步跟踪是一种低效的调试方法

云风大佬的挺有意思的一篇文章，其实我最近写游戏开发也有同感，CR 和 log 很多时候比调试好用，这篇文章很好的解答了我的一些疑惑

《断点单步跟踪是一种低效的调试方法》

曾经我以为编程像解数学题，不同人的解法或稍有区别，但终究殊途同归。然而最近两年，我发现编程更像画画或写作，各人信奉着自己的道。云风的这篇文，坦率说标题有些骇人听闻，但读后确能感受到数十年经验特有的编程智慧，一种哲思。

Source by Twitter Piglei

摘一些片段：

交互调试工具通常缺乏回溯能力，也就是它们通常反应当下的状态，而不记录过去的。这有些可以通过改进工具来完善，有些则不能。一个常见的场景是，你定下了下一个断点的位置，当调试器停下来的时候，发现状态异常，只能确定问题出在上次断点到当前的位置之间，但想回溯到底发生了什么，某个中间状态是什么，工具却无能为力。而靠大脑推演程序的运行过程的话，一切都是静态图谱，回溯和前行并无太大区别，只是聚焦到时间轴上某个位置而已。这就是为什么受过良好训练的程序员可以一眼看出 Bug 在哪里，而调试器运用高手却需要反复运行两三次才能找到 Bug 的缘故。

试想我们在用交互调试工具时，其实是想知道些什么？无非是程序的运行路径，是不是真的走到了这里，以及程序运行到这里的时候，变量的状态是怎样的，有没有异常情况。日志输出其实在做同样的工作。关键路径上输出一行日志，可以表达程序的运行路径。把重要的变量输出在日志里，可以查询当时的程序运行状态。怎样有效的输出日志自然也是需要训练的技能。

和外挂的调试工具相比，日志具备良好的回溯查询能力。作为 Code Review 的一个辅助，我们大脑其实需要的只是对判断的一个修正：确认程序是否是沿着脑中模拟的路线在行进，内部状态是否一致正常。和调试工具不同，日志不会打断运行过程，对多个程序并行运行的软件，例如 C/S 结构的系统就更为重要了。

其实保留状态信息在交互调试工具中也是非常重要的技巧。我相信很多人和我一样，在调试程序时有时会增加一些临时的全局变量，把一些中间状态写到这些变量中。在交互调试过程中偶尔需要去查看这些状态值。这种临时状态暂存变量，其实也充当了日志的功能。