Debugging 修复严重时间限制下的错误

最近我不得不修复一个从现场报告的bug。当测试团队试图重现这个问题时，客户对我们垂涎三尺，我们必须在一周内准备好生产代码。当我们终于能够重现这个问题时，只剩下3天了。我和我的同事花了将近30个小时的不间断的努力来寻找原因，并在代码中找到不是我们编写的修复方法。幸运的是我们做到了。然而，我担心的是测试团队没有足够的时间来运行他们通常的测试用例。我们不得不忽略代码中的其他小错误，以限制代码更改

---

我想从社区了解在这种时间紧迫的情况下应遵循的最佳实践。忽略其他问题（不是您正在处理的bug的原因）可以吗？如何尽可能地限制遗留代码中的代码更改，这样我就不必担心只有最小的测试是可能的。没有充分休息的连续工作也会增加问题。请分享您的想法和经验。

无论您做什么，

---

你所能做的就是在老板/公司规定的时间限制内做到最好。

有一个最佳做法是显而易见的不要“连续工作而没有足够的休息时间”

---

另一个是把你的商业头脑和一些常识，什么是风险，你已经介绍了另一个严重或更严重的错误？客户对此有何反应？如果您解释您需要更多时间，客户会如何反应？权衡答案，做出商业/行政决策。

当你处于极端的时间压力下时，你必须让它发挥作用。即便如此，仔细检查您的解决方案以确保它确实解决了问题，这一点至关重要。您必须理解所涉及的代码，了解问题是如何发生的，并确保您的修复是正确的。太多的时候，补丁被匆忙推出，结果是错误的，并导致另一个快速补丁

至于沿途遇到的问题。。。记下它们，继续前进。一定要回到他们身边，但暂时离开他们，除非他们与当前问题有关

---

总而言之，这是一个丑陋的处境，没有优雅的解决方案。只需确保您正朝着一个不会遇到此类问题的方向前进。

在开始使用该应用程序之前，您已经使用常用的测试用例对其进行了测试。因此，如果你只有一个小的时间框架来做出具体的改变，那就是你应该做出的唯一改变。虽然您应该彻底测试该案例，并尽可能多地进行回归测试，但您可能会没事

---

您可能希望向上司推荐的一件事是，在看过遗留代码之后，请提及您在代码中发现了其他小缺陷，或许您应该在应用程序上运行维护版本。通过这种方式，您可以返回并更加小心地清理发现的其他问题，并有时间进行一轮完整的测试。

如果您发现源代码中存在错误，而这些错误从未产生过问题，请不要在未进行广泛测试的情况下进行修复

您可能会发现从未调用过错误的代码，但也可能在其他地方出现错误，即“修复”此错误，并且更改源代码以执行正确的操作可能会破坏应用程序

---

所以，如果您没有足够的时间进行测试，不要修复与当前问题无关的东西！请注意这一点，稍后通过广泛的测试进行修复。

我认为，在尝试修复一个关键的错误时，忽略可能发现的其他（更无问题的）错误当然是可以的。但是，当然不应该忘记它，也不应该在一些票务系统中报告它

我认为，在这种情况下（当然会发生这种情况），为了获得一个平滑的结果，大多数工作都需要提前投入，以获得一个好的自动测试套件。这样，您至少可以确保在修复错误时不会引入新的错误。代码审查和类似的工作也会增加这一点

---

因此，在编写软件时，当您需要快速做出反应并做好准备时，请始终考虑这种情况。

这里已经有一些很好的建议，但我想补充一些其他建议：

如果你只是在极端的时间压力下完成了一个bug修复，记得在压力关闭时回来看看那个修复，以确保它不仅仅是一个可怕的黑客，而是一个真正问题的绷带

早在20世纪80年代末，我就修复了一个非常古老的程序中的错误。但在一个曾经有效的案例下，它不起作用了。当我进一步调查时，我发现一个“临时”的解决办法已经到位。评论说：

C TEMPORARY WORK-AROUND UNTIL I FIND THE REAL CAUSE.  I CHARNY, SUMMER STUDENT, AUG 1971

---

当我发现这个15岁以上的“临时解决方案”时，Irv Charny是我的老板。

如果您觉得客户的压力迫使您在没有充分测试/审查的情况下修复一个bug并进行部署，我建议告诉客户该bug已修复，但尚未完全测试。告诉他们进行全面测试需要多长时间，并让他们做出选择。如果bug真的像他们所说的那样重要，他们几乎肯定会立即部署——但这将是他们的选择，如果以后出了问题，他们有更好的机会了解发生了什么。如果他们在一些不太重要的事情上施加压力，希望他们能让你先测试一下。

这个问题给我带来了很多担忧

我“一直在那里，做了那件事”，甚至通宵工作试图解决问题。我可以免费告诉你你可能已经知道的事情——凌晨3点你没有想得太清楚，你的修复可能会造成比解决问题更多的问题

不仅如此，在促进这种疯狂的工作文化中，