对于难以解决的bug,您的最佳实践是什么?[闭门]

有一件事很有帮助,那就是在专注和不沉迷之间找到一个很好的平衡。

• 确保您可以在不受干扰的情况下处理该bug
• 但是如果你不能集中注意力,也要知道什么时候该休息一下

是的,有一点是你能做的最好的就是睡个好觉。

Rubber duck debugging .

都是好答案。

对于真正棘手的bug,比如运行了很长时间的数值例程,得到的答案与以前略有不同,有一种费劲的方法通常是有效的。

例如,在调试器下运行旧版本的好程序,同时在调试器下运行新版本的坏程序。一步一步地让他们并排走,直到他们做了不同的事情。然后重复,回到他们开始不同的步骤。

我发现这种从两边向内工作的方法适用于所有类型的难题,而不仅仅是软件。

如果不想设置断点,则在任何地方打印输出。调试时帮了我大忙。然后,当然,当你看到可变输出与你认为应该的完全不同时,就像光线穿透一样。

• 使用调试器,确保您知道“预期”行为是什么,找到“预期”行为不再发生的点
• 当您可以回滚到代码的工作版本并开始一点一点地添加更改时,源代码管理会有所帮助,直到您发现有一点破坏了功能。
• 使用事件日志。我最近有一个bug,它在应用程序事件日志中记录了一个DllNotFound异常。那没有意义,因为文件在那里。我花了一些时间查看系统日志,其中还有一个关于缺少依赖项的错误。因此,请使用所有可用的日志。亲自将关键信息写入事件日志,并确保其按预期显示。
• 开始向stackoverflow写一个问题。对于我提出的每个问题,至少有一个或两个问题我没有回答,因为只要用书面形式正确地阐述问题,我就能找到解决方案
• 利用同事的帮助
• 如果没有帮助,请阅读文档和手册。( :-) )

一个没有任何帮助的例子:有一次我变得很粗鲁,因为我的DataGridView不会在复选框列中显示复选框。这是绝对不可能的。 我花了很长时间才发现,由于某种原因,如果一列的宽度小于某个宽度,复选框将不会显示。它们仍然可以在设计器中看到。(我认为原因是我们使用的某个UI工具包)。我不知道,但只是在运行时意外地移动鼠标,我调整了一列的大小,瞧,它们就在那里,我的复选框一直都在那里,看不见。

我发现有一点很有帮助,那就是要记住,在处理真正有趣/讨厌的bug时,不必一下子找到正确的解决方案。任何告诉你一些你还不知道的事情都是朝着正确方向迈出的一步,从而让你更接近答案。甚至弄清楚问题出在哪里 有帮助,因为你知道去别的地方看看。

虫子是间歇性的吗?然后暂时忘记试图弄明白 为什么? 它会发生,并专注于 什么时候 . 如果您能够提出一个可靠地复制bug的测试用例,那么您就可以很好地解决它了。

认为代码的某个特定部分看起来可疑吗?然后用断点或打印语句(在您的环境允许的情况下)大量地散布它,并向您自己证明它运行正常。检查输入变量。检查输出变量。见鬼,甚至可以检查环境变量。

当我被难倒的时候,我试着回到基本的实验上:收集数据,形成假设,检验假设,起泡,冲洗,重复。你知道,在我的计算机科学中加入一些“科学”。:-)

使用您的版本控制系统,及时返回到bug出现之前,并将代码与引入bug的第一个版本进行比较。

我听说有一个git命令或工具可以让这变得简单。

使用一个编辑器,让您

使用断点,您不必在调试时反复从代码的开头开始,这使逐步完成代码变得更容易

别管它,打电话给你的同事,让他重新审视这个问题。一次又一次,我发现这种方法可以在5分钟内解决问题,而你可能会浪费一整天的时间。

忘记调试器吧。浪费时间,大部分时间。

第一 rubber duck

计划B:确保你有 . 然后,您可以使用诸如Kent Beck所称的 Saff squeeze ".

在3D(例如游戏)渲染中,调试总是一场噩梦。它有时会转到像素调试器,它会显示该像素在什么时候和什么时候被修改,从什么颜色到什么颜色。

有几个选择。你可以:

• 在linux机器上调试。mono有一个命令行调试器。

这个问题涵盖了许多相同的理由: Best practices for debugging

应该 我一直在工作,但不是,我经常太努力了。抓住一个朋友,一行一行、一点一点地向他们解释它应该如何工作,通常会导致问题突然出现。

当我像我一样编程时,我必须善于发现和修复bug

首先,我必须承认这个错误是我的。与团队合作时,很容易将问题归咎于他人。当我有了这种倾向,我就开始收集足够的证据来证明这个bug是他们的。大约有一半的时间,我收集了足够的证据来确定它是我的。到那时,我已经找到了解决办法。否则,我会向另一个开发人员解释我的代码是什么,响应是什么,以及该响应有什么让我惊讶。这使得他们更容易指出我的期望是错误的,或者他们的贡献可能不正确。

当我确定这是我的问题时,我会用“逻辑的无情应用”来解决它。我收集了所有关于不当行为的信息。然后我将它和代码并排检查,试图找出什么可能导致意外行为。通常,这会指向代码中可疑的部分。在这一点上,我尝试进一步插入代码,保存变量副本或记录关键信息。根据收集到的进一步信息,我评估并完善了我的原始假设,然后继续。几次这样的迭代通常会确定错误或指向一个新的调查区域。我想这可以归结为分析->仪器->测试->重复当我发现问题时,我总是至少再检查一个仪器->测试迭代以确保错误确实已修复。

正如其他人提到的,向同事寻求帮助。这有两方面的帮助。首先,在向他们解释代码时,您将更好地理解代码。即使你的同事与你的水平不一样,这也会有所帮助。其次,他们可能会看到你没有注意到的事情,或者问一些没有发生的问题。

找一个了解基本问题和技术的人(这样他们就不会茫然地盯着你看),然后 解释 这是他们的问题。他们通常甚至不需要回答,只要把你的想法组织得足够好,向别人解释问题,往往就能找到解决问题的办法。

编辑:我指的是 Rubber Ducking 即使我不能给它起个名字。非常感谢。 Morendil .

知道你试图修复的东西的价值。不要把时间浪费在“绒毛”上。记录、解决问题,如果价值低于成本,则继续前进。

设定一次完成任务的时间限制,例如2小时。一旦到了这个时间,你没有取得进展,休息10-15分钟,可以出去散步,吃零食,与人聊天,除此之外的任何问题都可以帮助你“重置”你的精神焦点,因为一段时间后,试图用暴力解决问题是没有用的。

确保您清楚地了解错误的确切含义。有时候我会遇到一个bug,它会说,“这看起来很难看。请修复”,然后想,“我不知道如何让它看起来很好,我应该让它看起来像什么规格?”这样的想法。如果你不得不找人来评判开发人员和测试人员之间的相互指责,其中每个人都在说“我在遵守规范”,那么这种情况也可能发生。这个评判人可能是开发人员、测试人员或项目的经理,但我确实为那些陷入这种情况的人感到抱歉。