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

Question

最近我不得不修复从该字段报告的错误。虽然测试团队正试图重现这个问题，但客户却喘不过气来，我们必须在一周的时间内完成生产就绪代码。当我们能够重现问题的时候，还剩3天了。我和我的同事不得不花费近30个小时的不间断努力找到原因，并在我们未编写的代码中进行修复。幸运的是我们做到了。但是，我担心的是测试团队没有足够的时间来完成他们通常的测试用例。我们不得不忽略代码中的其他微不足道的错误来限制代码更改。

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

Answer 1

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

如果你只是在极端时间压力下修复错误，请记得在压力消失时回过头来看看那个解决方案，以确保它不仅仅是一个可怕的黑客，而是一个真正的问题。 / p> 回到20世纪80年代后期，我修复了一个在一个非常古老的程序中深陷的错误。但它曾经在一个过去工作的案件下工作。当我进一步调查时，我发现已经实施了“临时”工作。评论说：

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

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

Answer 2

一个最佳实践是明显的不“没有足够的休息时继续工作”

另一个是让你商业化，并使用一些常识，你引入另一个严重或更严重的错误的风险是什么？客户将如何应对？如果您解释需要更多时间，客户将如何反应？权衡答案并做出商业/行政决定。

Answer 3

无论您做什么， your software will contain bugs 。

在老板/公司指定的时间限制内，您所能做的就是最好的。

Answer 4

这个问题引起了我的一些担忧。

我已经“在那里，做到了”就工作全能者来试图解决问题。我可以免费告诉你你可能已经知道的事情 - 凌晨3点你没有想太清楚，你的修复可能会导致比他们解决的更多问题。

不仅如此，而且在促进这种疯狂的工作文化中，通常会在第二天早上8点出现，准备继续给予100％。当你年轻的时候，你的身体会应付一定数量的这个，但是在20岁左右，你会产生严重的副作用。哎呀，即使在你年轻的时候，你也只能睡不着这么久。如果你在睡眠不足的状态下驾驶，最终可能会让你失去生命。

我希望您能为贵公司的管理层提供更好的商业案例，以获得更明智的做法。几乎任何一个客户（无论多么咄咄逼人）都可以确信，等待一周比在软件中冒险使用showstopper bug更好。通宵编码马拉松可能适用于罕见情况，但当它变得司空见惯时，每个人都会受苦。

Answer 5

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

  

另一个让你商业化   并使用一些常识，是什么   你引入另一个风险的风险   严重或更严重的错误？怎么会   客户对此做出反应？怎么会   如果您解释，客户会做出反应   需要更多时间？称重答案   做一个商业/执行   决定

但是“权衡”答案是什么意思？这意味着你开始为事物分配权重字面意思：你停下来，休息一下，制作一个列表然后想出来。你应该告诉客户这是不可能的吗？一个小虫子会成为你在为期一周的疯狂匆忙中引入的噱头的风险是什么？

显然，没有固定的答案，但总的来说，我尽可能快地工作但不会更快。有些客户只是为了好玩而放松下来，但其他错误非常重要，修复它们的其他方面并不重要。如果没有客户的帮助，您无法确定。请记住，你们都朝着同一个目标努力。

如果客户太忙而无法与您交谈，您应该解释（通过电子邮件或血迹，无论如何）您将短路QA并可能在此过程中引入其他错误。您需要简要地谈谈那些比相关错误更重要的可能性。您有经验并知道您在做什么（在某种程度上），所以您必须提供帮助客户要了解他们要求的是多么疯狂（<或p>）。

无论如何，经过一段时间的漫无边际，这就是我的观点：你的工作就是保持冷静并做好自己的工作。我怀疑通过多天不间断工作，你实际上发现了更快的错误：你可能试图走得太快。您的工作也是告知您的客户每项决策的可能性，不可行性和风险。但是比你最快的速度 - 比如没有休息 - 没有任何意义，也没有人帮助。

但在所有情况下，没有什么可以失去你的禅宗。永远。

Answer 6

如果您认为客户压力迫使您修复错误并在没有经过充分测试/审查的情况下进行部署，我建议告诉客户该错误已修复但未经过全面测试。告诉他们需要多长时间才能完全测试并给予他们选择。如果这个bug真的和它们一样重要，那么它们几乎肯定会立即进行部署 - 但这将是他们的选择，如果以后出现问题，他们会更好地理解发生了什么。如果他们给那些并不重要的东西施加压力，希望他们能让你先测试一下。

Answer 7

当你处于极端时间压力之下时，你必须让它发挥作用。即便如此，重要的是要检查解决方案以确保它真正解决问题。您必须了解所涉及的代码，了解问题是如何发生的，并确保您的修复是正确的。很多时候，补丁只会被淘汰出错，导致另一个快速补丁。

对于沿途遇到的问题......记下它们并继续前进。一定要回到他们身边，但现在留下他们，除非他们对当前的问题有所影响。

总而言之，这是一个丑陋的情况，并没有优雅的解决方案。只要确保你朝着不会遇到这些问题的方向前进。

Answer 8

在您开始处理之前，已经使用常用测试用例对应用程序进行了测试。因此，如果您只有一个小的时间框架来进行特定的更改，那么这是您应该做的唯一更改。虽然你应该彻底测试这个案例，并做尽可能多的回归测试，但你可能没问题。

您可能希望向老板推荐的一件事是，看过遗留代码，提到您发现了代码中的其他小缺陷，也许您应该在应用程序上运行维护版本。通过这种方式，您可以更加谨慎地回顾，清理您发现的其他问题，并有时间进行全面的测试。

Answer 9

如果您发现源中存在错误，从未出现过问题，请不要在没有进行大量测试的情况下修复它！

你可能会发现错误的代码从未被调用过，但是在其他地方也可能出现问题，这就是“修复”这个错误，并且更改源代码以执行正确的操作可能会破坏应用程序！

因此，如果您没有足够的时间进行测试，请不要修复与当前问题无关的内容！请注意这些内容，稍后通过大量测试进行修复。

Answer 10

在最初的错误修复发布完成后，没有什么能阻止您继续努力使修复尽可能稳定。

最重要的是阻止火灾并让客户满意。

完成后，您需要安排额外的工作才能完成所有工作;修复“环境”错误，让QA通过测试计划，之后你可以创建另一个“官方”版本，正式修复初始问题并提高安全性。

Answer 11

这实际上取决于手头的问题。

我最近与一家在心脏起搏器公司工作的开发人员交谈过。然而至关重要的是，他们只是不能急于求成。但如果需要，他们会有一些硬件检查软件行为并将起搏器重置为“保存”状态。

如果真钱丢失了，那么快速修复它的需要可能会更大，需要安全地完成它。

无论您做什么和/或修复，请确保 记录所有更改 并以慢动作检查它们以检查是否存在潜在错误。

Answer 12

如果您在紧迫的截止日期前工作，则需要关注。因此，如果您看到一些代码向您发送清理我，但与手头的问题无关，请稍后重新访问此地点但不要现在重构它。它不仅可以这样做，而且是强制性的。

Answer 13

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

我认为在这种情况下（当然确实会发生）获得顺利结果的大部分工作需要预先设置好的自动测试套件。这样你至少可以确保在修复那个错误时不会引入新的错误。代码评论等增加了它。

因此，当您需要快速做出反应并为此做好准备时，编写软件时可能总是会考虑这种情况。

Answer 14

首先，我认为你必须将“情感剧”分开，然后做出冷静的决定，确定修复bug是否比发布完成更优先。希望这是别人的工作。他们应该让开发人员免受所有“客户正在呼吸我们的脖子”的压力。如果客户端也在等待发布，也许它可以被抛回给他们，修复这个bug会/可能会延迟发布

然后丹尼尔说“尽可能快地工作，但不会更快”。如果客户抱怨，甚至失去收入，这实际上不会影响您修复错误或快速修复错误的能力。

至于修复，我会做绝对的最低限度来修复那个特定的bug。如果可能的话，我会编写一个单独的代码块来处理（希望）导致错误的一个条件，并将其他所有条件都留下。这个想法是为了隔离那个问题并且知道（有点）由于变化而没有其他任何东西会破坏。并且能够轻松地测试那一个条件。