错误修正何时会变得过大，如果有的话？

#1 楼

您必须务实。

如果错误不太可能在现实世界中触发，并且修复成本很高，我怀疑许多人会认为这是对修复资源的良好利用。在此基础上，我会说保留它，但要确保在几个月内为您或您的继任者记录了这种黑客行为（请参阅最后一段）。

这就是说，您应该将此问题用作“学习体验”和下次执行循环操作时，请不要不必要地使用递归循环。

还要为该错误报告做好准备。您会惊讶于最终用户如何突破界限并发现缺陷。如果确实成为最终用户的问题，那么您将不得不对其进行修复-那么，很高兴您记录了该黑客行为。

#2 楼

Windows 95中有一个类似的错误，导致49.7天后计算机崩溃。它只是在发布后的几年才被发现，因为很少有Win95系统能够保持这么长的时间。因此，有一个观点：错误可能会与其他更重要的错误变得无关。

您要做的是对整个程序进行风险评估，并对单个错误进行影响评估。 />

此软件是否在安全边界上？
如果是，此错误会导致漏洞利用吗？
此软件对预定用户是否“至关重要”？ （请参阅Java EULA禁止您将其用于以下目的的清单）
该错误会导致数据丢失吗？经济损失？名誉损失？
此错误发生的可能性有多大？ （您已将其包含在方案中）

，依此类推。这会影响错误分类，即决定修复哪些错误的过程。几乎所有的运输软件都有很长的小错误列表，这些小错误尚未被认为很重要，可以修复。

#3 楼

其他答案已经非常好，我知道您的示例只是一个示例，但是我想指出此过程中尚未讨论的大部分内容：

您需要确定您的假设，然后针对极端情况测试这些假设。

看看您的示例，我看到几个假设：


递归方法最终将导致错误。
没人会看到此错误，因为视频播放所需的时间太长，无法达到堆栈限制。

其他人讨论了第一个假设，但看看第二个假设：如果我的视频只是一秒钟的一小部分？

当然，也许这不是一个很常见的用例。但是您真的确定没有人会上传非常短的视频吗？您假设视频是最短的播放时间，您甚至可能没有意识到自己在假设什么！这种假设还会在应用程序的其他地方引起其他错误吗？

未识别的假设是大量错误的来源。

就像我说的，我知道您的示例仅仅是一个例子，但是这个过程会确定您的假设（通常很难听起来），然后考虑这些假设的例外情况，这是决定在哪里花费时间的重要因素。

因此，如果您如果发现自己在想“我永远不必为此而编程，因为它永远不会发生”，那么您应该花一些时间来认真研究这个假设。您经常会想到比原先想像的情况更为普遍的极端情况。

话虽如此，这在某种意义上是徒劳的。您可能并不在乎您的JavaScript应用程序是否可以在TI-89计算器上完美运行，因此在此上面花费任何时间都是浪费的。

其他答案已经涵盖了这一点，但是想出“这很重要”和“这是浪费时间”之间的界限并不是一门精确的科学，它取决于许多因素，这些因素可能与一个因素完全不同。个人或公司。

但是该过程的很大一部分是首先确定您的假设，然后尝试识别这些假设的例外。

#4 楼

我建议您阅读以下文章：

可靠性及其威胁：分类法

它还描述了程序中可能发生的各种类型的错误。
您所描述的被称为休眠故障，在本文中，其描述如下：


故障在产生错误时处于活动状态，否则将处于休眠状态。活动故障是a）先前处于休眠状态的内部故障和已由计算过程或环境条件激活的
，或b）外部故障。故障激活是将输入
（激活模式）应用到导致休眠
故障变为活动的组件。大多数内部故障在它们的休眠状态和活动状态之间循环


已经描述了这一点，所有这些都归结为成本效益比。费用将包含三个参数：


问题多久会出现一次？
后果是什么？
你个人会为此感到困扰吗？

前两个至关重要。如果某个漏洞会在蓝色的月亮中表现出来并且/或者没有人在意，或者有一个完美的实用解决方案，那么您可以安全地将其记录为已知问题，然后继续进行一些更具挑战性的工作重要的任务。
但是，如果该错误会导致某些金钱交易失败或中断漫长的注册过程，从而使最终用户感到沮丧，那么您就必须对它采取行动。
第三个参数是我强烈建议您不要这样做。用Vito Corleone的话来说：


不是个人的。没关系。


如果您是专业人士，请放开情绪，保持最佳状态。但是，如果您正在编写的应用程序是您的业余爱好，那么您会在情感上参与其中，并且在决定是否修复错误方面，第三个参数与任何参数一样有效。

#5 楼

直到有人将您的播放器放到运行24/7公司演示文稿的大厅屏幕上的那天，该错误才会被发现。因此，它仍然是一个错误。

答案是什么？确实是一项业务决定，而不是工程决定：


如果该错误仅影响您1％的用户，而您的播放器缺乏对另外20％所需功能的支持，则选择很明显。记录该错误，然后继续进行。
如果该错误修复在您的待办事项清单上，通常最好在开始添加新功能之前对其进行修复。您将获得零缺陷软件开发过程的好处，而且因为它已列在清单中，所以您不会浪费太多时间。

#6 楼

特别是在大公司（或大项目）中，有一种非常实用的方法来确定要做什么。

如果修复的成本大于修复所带来的回报，则保留该错误。反之亦然，如果修复程序返回的费用超过其成本，则修复该错误。

在您的示例方案中，这取决于您期望失去的用户数量，或者如果开发新功能将获得多少用户更正那个昂贵的错误。

#7 楼

tl; dr这就是为什么RESOLVED/WONTFIX是一个东西。只是不要过度使用它-如果您不小心，技术债务可能会堆积。这是您设计的基本问题，将来可能会引起其他问题吗？然后修复它。除此以外？保留它，直到它成为优先级为止（如果有的话）。

#8 楼

您描述的情况实际上存在三个错误：


缺少评估所有记录的错误的过程（您确实将错误记录在故障单/积压/任何系统中位置，对不对？）确定是否应该固定。这是一项管理决策。
您的团队缺乏技能，导致使用这样的错误解决方案。迫切需要解决此问题以避免将来出现问题。 （从错误中开始学习。）
视频很长一段时间后可能会停止显示的问题。

只有三个错误可能不需要修复。

#9 楼

这里有很多答案讨论如何评估修正错误的成本，而不是离开。它们都包含了很好的建议，但是我想补充一点，就是错误的成本经常被低估，甚至可能被大大低估了。原因是现有的虫子混淆了继续开发和维护的范围。在测试您的软件以查找新错误的过程中，使您的测试人员可以跟踪几个“无法修复”的错误，这会使他们的工作变慢并且更容易出错。一些不太可能影响最终用户的“不会修复”的错误仍然会使继续开发变慢，结果将是错误的。

#10 楼

我多年的编码中学到的一件事是，错误会再次出现。最终用户将始终发现并报告该错误。
是否修复该错误“仅”是优先事项和截止日期。

我们遇到了主要错误（在我决定不再在一个发行版中进行修复，但由于最终用户一遍又一遍地偶然发现了该发行版，因此成为下一发行版的展示广告。反之亦然-我们被迫修复了一个没人使用的功能中的错误，但便于管理人员查看。

#11 楼

这里有三件事：

原理

这是硬币的一面。在某种程度上，即使没有人注意到它，我仍然坚持要修复错误（或错误的实现，即使它们“起作用”）也是很好的。

这样看：真正的在您的示例中，问题不一定是bug，而是程序员首先认为以这种方式实现循环是一个好主意。从一开始就显而易见，这不是一个好的解决方案。现在有两种可能性：


程序员只是没有注意到。好吧……程序员应该对自己的代码如何运行产生直觉。并不是说递归是一个非常困难的概念。通过修复该错误（并费力地完成所有其他工作），他可能会学到一些东西并记住该东西，即使只是为了避免将来进行其他工作。如果原因是他没有足够的时间，则管理层可能会得知程序员确实需要更多时间来创建更高质量的代码。
程序员确实注意到了，但认为这“没问题”。如果放任自流，那么就会发展一种放任的文化，最终会导致真正伤害的错误。在这种情况下，谁在乎。但是，如果那个程序员下次要开发银行应用程序，并确定某个星座永远不会发生，该怎么办？然后就可以了。困难时期。

实用主义

这是另一面。当然，在这种情况下，您可能无法修复该错误。但是要当心-有实用主义，然后有实用主义。如果您找到一个快速但又扎实，有充分根据的问题解决方案，则是实用主义。也就是说，您避免过度设计内容，但是您实际实现的内容仍需要深思熟虑。实用主义很差，就是您只是一起破解某些东西，而这些东西“恰好如此”，并且会在第一时间就崩溃。

失败很快，努力失败

如有疑问，请快速失败，然后再进行失败。

这意味着，除其他外，您的代码注意到错误情况，而不是环境。

在此示例中，最少您可以做的是通过将其替换为您自己的硬异常，从而避免发生硬运行时错误（“超出堆栈深度”或类似的错误）。例如，您可以设置一个全局计数器，然后任意决定在1000个视频后（或任何数量足够高而在正常使用中不会出现，而数量又足以在大多数浏览器中运行）的情况下，您可以纾困。然后为该异常（可能是通用异常，例如Java中的RuntimeException或JavaScript或Ruby中的简单字符串）提供有意义的消息。您不必费心创建新的异常类型，也不必执行特定的编程语言所要做的任何事情。

这样，您就有了


...在代码内部记录了该问题。
...使其成为确定性问题。您知道您的例外情况将会发生。您不必担心基础浏览器技术的变化（不仅考虑PC浏览器，还考​​虑智能手机，平板电脑或未来技术）。
...当您最终需要进行修复时，可以轻松地对其进行修复。修理它。问题的根源由您的消息指出，您将获得有意义的回溯以及所有这些。
...仍然不浪费时间进行“真正的”错误处理（请记住，您永远都不会期望错误发生） 。

我的约定是在此类错误消息前加上“ Paranoia：”一词。对于我和其他所有人来说，这是一个明确的信号，我从没想到会出现该错误。我可以清楚地将它们与“真实”异常分开。如果我在GUI或日志文件中看到类似的图像，则可以肯定知道我有一个认真的问题-毕竟我从来没有想到它们会发生。在这一点上，我进入了紧缩模式（有一个很好的机会来快速，轻松地解决它，因为我确切地知道了问题的出处，使我免于进行很多虚假的调试）。

#12 楼

在我工作场所的高级开发人员桌子上的贴子上写着


它对任何人都有帮助吗？


我认为这通常是一个很好的起点进行思考的过程。总会有很多事情需要修复和改进-但是您实际上增加了多少价值？ ...无论是在可用性，可靠性，可维护性，可读性，性能...还是任何其他方面。

#13 楼

想到三件事：

首先，在以负责任的方式做出将错误保留在代码中的决定之前，需要彻底调查已识别错误的影响。 （在您的示例中，我立即想到了不断增长的堆栈代表的内存泄漏，这可能会使您的浏览器在每次递归时变得越来越慢。）与彻底解决该错误相比，这种彻底的调查通常需要更长的时间，因此，我更喜欢修复在大多数情况下都是错误。

其次，错误的影响力往往比人们最初想象的要大。我们都非常熟悉工作代码，因为这是“正常”情况。另一方面，错误是“例外”。当然，我们所有人都已经看到了很多错误，但是我们看到了总体上可以运行的代码。因此，与错误代码的行为方式相比，我们对工作代码的行为方式具有更多的经验。有成千上万的关于工作代码及其在何种情况下将如何工作的书籍。错误代码的行为几乎没有。

原因很简单：错误不是有序的而是混乱的。他们通常会留下一些痕迹（或者反之亦然：他们不会完全破坏命令），但是它们的错误本质是破坏了程序员想要的命令。混沌本身倾向于不正确估计。仅仅因为一个程序不再符合我们的思维模式，就很难说一个有错误的程序将做什么，而一个正确的程序将很难做。

第三，您的示例包含了修复问题该错误意味着必须重新设计该程序。 （如果剥夺了这一方面，答案很简单：修复错误，因为不需要重新设计，它不会花太长时间。否则：）在这种情况下，我对程序的设计方式失去了信任。重新设计将是恢复这种信任的一种方式。

综上所述，程序是人们使用的东西，而缺少功能或其他地方的第二个非常麻烦的错误可能比修复错误具有优先权。当然，然后采取务实的方式，并先做其他事情。但是永远不要忘记，对错误影响的初步快速评估可能是完全错误的。

#14 楼

低概率/轻度后果=低优先级修复

如果发生的可能性很低
如果发生的后果是轻微的
则该错误不会构成威胁，则不是优先解决方案。

但这不能成为懒惰的开发人员的拐杖...

“很少出现”是什么意思？
“轻微后果”甚至意味着什么？

要说明发生的可能性非常低且后果是轻微的，开发团队必须了解代码，用法和安全性。
大多数开发人员感到惊讶的是，他们本来难以克服的事情将永远不会发生，实际上会发生很多。
我们的教育系统不能很好地教授概率和逻辑。包括大多数软件工程师在内的大多数人都具有破碎的逻辑和破碎的直觉。我知道解决此问题的唯一方法就是体验现实世界中的问题和进行广泛的模拟。
用现实世界中的数据来面对您的直觉
重要的是要制作多个日志以遵循使用模式。用对您认为不应该发生的事情的断言填充代码。您会惊讶于它们的作用。这样，您就可以用硬数据面对直觉并对其进行完善。
我的一个温和问题和控制措施的例子
在我很久以前工作的一个电子商务站点中，另一个程序员犯了一个错误：在某种模糊的情况下，系统从客户那里扣除的借方费用比日志中记录的少1美分。我发现该错误的原因是，我制作了报告以识别日志和帐户余额之间的差异，从而使会计系统更具弹性。我从未修复过此错误，因为差异很小。每天计算出差额，每月少于2.00美元。碰巧我们正在开发一个全新的系统，一年之内就可以取代现有的系统。将资源从可能有利可图的项目中转移来修复每月花费2.00美元并受到适当控制措施的东西是没有道理的。
结论
是的，有些错误不需要修复马上，这些都不足以延迟新功能的开发。但是，由于我们不能相信自己的直觉，系统必须控制此错误的发生率，以确保它很小。

#15 楼

我认为这从一开始就是在问一个错误的问题。

问题不是“我应该修复此错误还是应该不修复此错误”。任何开发人员都有有限的时间。因此，问题是“在一小时，四个小时或一周内我能做的最有用的事情”。

如果修复该错误是最有用的事情，因为它对大多数人来说最大程度地改善了该软件，则请修复该错误。如果您可以通过添加人们所缺少的功能或修复更重要的错误来在其他地方进行更大的改进，则可以执行其他操作。并为任何使您未来的开发更有效率的事情提供额外的奖励积分。

#16 楼

错误修复始终是一个过大的问题

让我们首先对错误进行分类。

这是一个诚实的错误，例如一个一次性错误或逃脱测试的可变阴影？在这种情况下，我当然希望除了“解决”问题之外，您还编写了新的单元测试，还可以借此机会重构附近的代码，其中所有后者都是有用的工作。

如果，这实际上是设计上的缺陷，您应该重新评估设计，或者在最坏的情况下，请禁用此功能。

因此，请不要尝试仅对其进行修复。

当然，您可能会做得更糟---您可以尝试采用hack-up-hack技术。视频循环是一种黑客行为（架构不良，并且有已知的损坏）。您可以添加一个循环限制，以便在N次迭代（您测试过的次数低于浏览器限制）之后循环终止。

后果很明显，现在您必须同时支持这两个损坏的代码和新的循环限制。

PS对于极端观点表示歉意。

P.P.S.关于术语的注释：您无法“修复”错误。兽医也许可以，但是我们不要去那里;-)。问题已解决或“修复”，而错误已消除或解决。