少用 debugger，多从 debugging 中学习

Source: Dev.to

背景

在我上一个项目中，我负责一个大型、复杂的专家系统。使用调试器检查 bug 很困难，原因有以下几点。我们从真实系统中获取实时数据，以便替换它，所以流量很大，跟踪单个请求变得很麻烦。

当 bug 出现在客户端时，调试更为艰难。客户端是基于 Eclipse RCP 的自定义 Java 前端，而我们对这项技术的经验有限。UI 逻辑隐藏在许多层次的 Java 代码和 XML 文件中，使得使用调试器追踪执行流变得困难。

新的调试策略

我采用了一种依赖深思熟虑的日志记录，而不是用调试器逐步执行代码的方法。关键是先问自己 到底想了解什么，再开始调试会话。

步骤 1：定义需求

1. 确认需要检查的变量。
2. 确定这些变量值的哪些属性是相关的。

与其带着模糊的“看看吧”心态启动调试器，我现在只有在阅读代码后真的对问题毫无头绪时才进入调试会话。

步骤 2：添加有针对性的日志语句

• 记录已识别变量的值。
• 选择任何便于阅读的信息格式。
• 包含时间戳——它们对诊断调试器难以捕捉的时序问题非常宝贵。

步骤 3：使用临时提交

创建一个 临时提交（短期更改），其中包含新的日志语句。将该版本部署到测试环境，使用真实数据运行，然后收集日志。调查完成后，在合并到主分支之前删除临时提交。

分析日志

手头有日志后，你可以：

• 编程方式解析并分析数据。
• 与团队成员共享分析结果和原始数据。
• 包含分析代码本身，使他人能够复现或扩展工作。

这种做法让调试知识得以持久保存，而不像调试会话结束后就消失。

调试器仍然有用的情况

当你 完全不知道执行流 时，调试器仍然很有价值，例如代码依赖于难以仅凭阅读理解的通用机制。在这些情况下，我会使用调试器发现相关类和控制流，然后再切回日志进行更深入的分析。

结论

从以调试器为中心的工作流转向以日志驱动的方式，使我对系统行为有了更好的理解，并降低了对交互式调试的依赖。如果你还没有尝试过使用日志进行调试，试试这种策略——它可能会让你的调试会话更有目的、更结构化，也更易于分享。