debugging - 在严格的时间限制下修复错误

Question

最近我不得不修复一个从现场报告的错误。当测试团队试图重现这个问题时，客户对我们嗤之以鼻，我们不得不在短短一周的时间内准备好生产代码。最后，当我们能够重现该问题时，只剩下 3 天了。我和我的同事不得不投入近 30 个小时不间断的努力来查找原因并在不是我们编写的代码中进行修复。幸运的是我们做到了。然而，我担心的是测试团队没有足够的时间来运行他们通常的测试用例。我们不得不忽略代码中的其他小错误以限制代码更改。

我想从社区中了解在这种时间紧迫的情况下应遵循的最佳做法。忽略其他问题(不是您正在处理的错误的原因)是否可以？如何尽可能地限制代码更改，在遗留代码中也是如此，这样我就不必担心只能进行最少的测试。没有足够休息时间的连续工作也会增加它的问题。请分享您的想法和经验。

Answer 1

AnthonyWJones 上面高度评价的答案是正确的，基本上

Another is put you commercial head on and use some common sense, what is the risk you have introduced another as serious or more serious bug? How will the customer react to that? How will the customer react if you explain your need for more time? Weigh the answers and make a commercial/executive decision

但是“权衡”答案是什么意思呢？这意味着您开始为事物分配权重 字面意思:你停下来休息一下，列一个 list ，然后想一想。你应该告诉客户这是不可能的吗？一个小错误会成为你在为期一周的疯狂匆忙中引入的表演障碍的风险有多大？

显然，没有固定的答案，但总的来说，我会尽可能快地工作，但不会更快。有些客户只是为了好玩而深呼吸，但其他错误非常重要，以至于 其他什么东西坏了修理它们并不重要。 没有客户的帮助，您无法确定这一点。记住， 你们都在朝着同一个目标努力。

如果客户太忙而无法与您交谈，您应该解释(在电子邮件中，或在血迹中，无论如何)您将缩短 QA 并可能在此过程中引入其他错误。您需要简要地谈谈这些人是 的可能性。比问题中的错误更重要。 你有经验并且知道你在做什么(在某种程度上)，所以你必须帮助客户了解他们的要求有多疯狂(或不疯狂)。

不管怎样，在闲聊了一下之后，我的观点是: 你的工作是保持冷静并做好你的工作。我怀疑通过连续工作多天，您实际上更快地发现了错误 : 你可能是想走得太快。您的工作也是告知您的客户什么是可能的，什么是不可能的，以及每个决定会带来什么风险。但是比你最快的速度更快——就像不休息一样——没有意义，也没有帮助任何人。

但在所有情况下，都没有什么可失去您的禅意的。曾经。