修复错误是否有边际收益[关闭]

我从一位前同事那里听说，并不是所有的bug都需要修复，因为当您按优先级排列bug时，导致该bug变得更加模糊的用例，或者获得的客户满意度降低了。但是您仍然必须花费大量时间来修复该错误。

为了使我们的产品所有者相信这一概念，我找不到任何好的资源。我所能找到的只是关于软件开发是否存在边际成本的讨论。

修复错误真的有边际收益吗？是否有其他术语解释这个概念？

从业务角度看，错误修复与功能请求没有什么不同。它具有一定的开发时间成本，并且对客户具有一定的价值。如果错误不很严重，则优先考虑该错误修复之上的重要功能完全具有商业意义。

但是从技术角度来看，错误可能更为严重，因为它们表示其他代码可能在其上使用/构建的基础中的错误，在这种情况下，该错误具有“传染性”，并增加了将来的维护成本。因此，不修复错误是一项技术上的负担，需要管理，而未实现功能并不会带来持续的成本。但是，错误所引起的技术债务水平很大程度上取决于错误的性质。

在确定优先级时，应考虑所有这些因素。

至于修复错误是否有边际效益：这是给定的。由于并非所有错误的严重性都相同，因此您自然会优先考虑最重要的错误。因此，您修复的错误越多，修复下一个错误的边际价值就越低。但是，是否达到修复错误的水平不值得付出努力，这是业务决策而不是技术决策。

这是一个很好的参考

http://www.joelonsoftware.com/articles/fog0000000043.html

您在编写新代码之前会修复错误吗？Windows的Microsoft Word的第一个版本被认为是“死亡游行”项目。[...]因为错误修复阶段不是正式时间表的一部分[...]

微软普遍采用了最优先的做法是在编写任何新代码之前消除错误。通常，修复错误之前等待的时间越长，修复的成本（时间和金钱）就越昂贵。 。

您可以确定，这些错误在这里出现的时间越长，当它们成为优先级时，修复它们所花费的时间就越长。因此，您现在可以避免日渐昂贵的损失，而不是立即获得原始收益。

管理该问题的一种好方法是定义分配的时间来处理积压问题。这不会像Microsoft那样大肆宣传，但是即使客户并不在意这些问题，即使将来还不是您的问题，它将确保一定程度的解决方案。

为了使我们的产品所有者相信这一概念，我找不到任何好的资源。

假设您在一家商业机构工作，那么肯定会有某个知道成本效益分析的人。

您的组织拥有有限的开发人员资源，并且有无数的有益工作要做。这些有益的事情包括添加新功能和删除现有错误-与添加新功能一样，删除错误可以改进软件。

因此，显然，对于如何针对此无限列表分配此有限资源，需要做出决策，结果有些错误现在，下周，明年或明年都没有得到修复也就不足为奇了。事实上。

如果您在这里寻找一种更结构化的方法，则可以尝试使用PEF / REV系统，该系统为错误的“用户”和“程序员”视图分配编号，以此作为确定已解决问题和未解决问题的起点。

另请参阅此处有关软件工程的这两篇文章：

解决哪些错误将带来最大的成本收益

几乎每个报告的错误都是高优先级错误

并非软件行为的所有无意或不良方面都是错误。重要的是确保软件具有有用的并记录有条件的条件范围，在这些条件范围内可以依靠它以有用的方式进行操作。例如，考虑一个程序，该程序应该接受两个数字，将它们相乘，然后输出结果，如果结果大于9.95但小于10.00，大于99.95但小于100.00，则输出伪数字，依此类推如果编写该程序是为了处理其乘积介于3到7之间的数字，并且永远不会被调用来处理其他任何数字，则使用9.95修复其行为将不会使其对其预期目的更加有用。但是，它可能会使该程序更适合于其他目的。

在上述情况下，将采取两种合理的措施：

1. 如果可行，请解决此问题。

2. 指定程序输出可靠的范围，并声明该程序仅适用于已知产生有效范围内值的数据。

方法1将消除该错误。方法2可能会使进度不适用于某些目的，而不是适合其他目的，但是如果不需要程序来处理可能不是问题的有问题的值，则方法2可能会使进度不适用于某些目的。

即使由于编程错误而无法正确处理99.95到100.0的值（例如，在四舍五入到一位后决定输出小数点后两位小数，从而得出00.00），也应仅将其视为错误，如果在这种情况下将程序指定为产生有意义的输出。[顺便说一下，上述问题出现在Turbo C 2.00 printf代码中；在这种情况下，这显然是一个错误，但是调用错误的printf的代码只有在它可能产生问题范围内的输出时才是错误的。

从广义上讲，是的，不是所有的bug都需要修复。所有这些都是关于风险/收益比的分析。

通常情况是，企业将与技术负责人和利益相关者举行会议，讨论“需要解决”的漏洞。他们将决定花费在修复错误上的时间（=金钱）是否对企业有价值。

例如，“小错误”可能是网站“条款和条件”部分中的轻微拼写/语法错误。提出此建议的个人可能会认为更改的幅度很小，但企业会认识到它可能对品牌造成的潜在危害，以及确定几个字符的相对容易性。

另一方面，您可能会发现一个似乎很重要的bug，但该bug难以修复，只会影响少量的用户。例如，对于使用旧版Google Chrome浏览器的用户，次要按钮链接已损坏，并且碰巧禁用了Javascript。

业务未修复错误的其他原因可能是，所花费的时间会使项目陷入无法预料的时间，或者开发人员的时间最好花在其他修复/编码上。该错误可能还很小，可以发布，然后在以后修复。

希望能更好地解释这个概念！我肯定会避免一般性地考虑这一点-每个错误都是唯一的，应该这样对待。

因为当您进入错误的优先级列表时，导致该错误的用例变得更加晦涩，或者获得的客户满意度降低了。

所以他们的“争论”实际上是

如果您足够长时间忽略该错误，则用户将忘记问题所在或找到解决该问题的方法。

像新的功能请求一样，应该对错误进行优先级排序并按顺序进行处理（但是，可以说，在所有功能请求之上）。