【问题标题】:How to record the context of a debugging session?如何记录调试会话的上下文?
【发布时间】:2013-10-24 01:47:03
【问题描述】:

寻找错误通常需要 97% 的“了解代码库的特定部分”和 3% 的“在正确理解后写几行来解​​决问题 em>”。

当 bug 真的难以理解时,可能意味着要花一整天的时间查看代码、尝试一些实验、设置断点并单步调试代码以了解这个神秘的 bug。这一整天的工作将在 CVS 中被记住为代码库中的一个非常小的更改(包括简短的注释)以及“已修复的 #xxxx 问题,[某些组件] 做错了 [whatever]... ”作为提交消息。

因此,最终该错误不再存在,但唯一存储的有关它的信息将是 CVS 中的差异。花在调试器中以便能够编写最终修复错误的代码行所花费的时间将永远消失。

我希望能够记录调试会话的一些关键指标/事件,例如:

  • 我在其中设置断点的函数
  • 输入数据我手动输入程序以重现问题
  • 为了测试某些行为而修改和恢复的代码
  • 调用堆栈
  • ...

将此“调试摘要”链接到提交注释将在以后处理相关错误时实现更快的上下文切换。

有没有一些工具可以做到这一点?
(这个问题与语言/IDE 无关...)

【问题讨论】:

    标签: debugging


    【解决方案1】:

    我通常在调试过程中写日记。这是保持生产力和保持方向的一种方式。但之后我很少真正阅读该杂志。我怀疑您所要求的工具也会出现这种情况。

    相反,我的建议是确保您只修复一次错误。将测试用例添加到自动化测试套件。清理这个杂乱区域周围的设计,这样下次它出现不当行为时您就不必花太多时间在上面了。 (测试套件是保存“我手动输入程序的输入数据”的最佳场所,除了非正式的单元测试之外,还有什么是“经过修改和恢复以测试某些行为的代码”?)

    【讨论】:

    • 我想看看你的一些调试日志。怎么样?
    • 抱歉,它们不容易共享。我通常用笔和纸(螺旋垫)写日记,我的笔迹真的很糟糕。但是,为了给你一个想法,它们充满了这样的东西:要解决的问题写得很清楚(在尝试回溯时非常有帮助!),假设,尝试的想法(如清单)等。但通常缺少的一件事是问题的实际解决方案;而是在签入评论中。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-03-27
    • 2015-01-27
    • 1970-01-01
    • 2019-01-07
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多