如果该错误已存在5年以上，那么它是否具有功能？[关闭]

请允许我添加详细信息：我在许多编码员，测试人员，质量检查分析师，产品负责人等机构工作，以下是令我感到困扰的事情：

十多年来，我们已经能够销售糟糕的（尽管功能很强大）软件。它具有许多功能，产品具有竞争力，但是那里存在一些严重的错误，以及成千上万的“剪纸”，这是客户需要习惯的小烦恼。

看某些事情让我很痛苦，因为我坚信，如果计算机无助于让我们的生活变得更轻松，那么我们就不应该使用它们。我对我的同事充满信心-他们很聪明，有能力，并且在专注于这样做时可以改善事情。

但是，很难将漏洞提交到某些旧功能，而又不会发现它们已关闭或被遗忘。一个典型的答案是：“它在无数个世纪中一直如此”。同样，当质量检查进行回归分析时，他们倾向于寻找与看起来不正确的差异不大的差异。因此，可以将一个旧问题的解决方案写为一个错误，因为“甚至在我之前就已经这样了”。

我心中的年轻程序员认为：重写这个怪异的东西！作为有机会接近客户的人，我想对此方法产生疑问。

我也对您的意见/经验感兴趣。请尝试考虑风险，收益成本和其他非技术因素。

我感到你很痛苦。

但是仅仅因为它是一个错误而修复它并不是一个足够好的理由。

您必须确保您的修复程序不会破坏任何其他代码（不仅是您自己的代码，而且还会破坏使用您代码的客户代码）。如果您推出一个修复程序，而这破坏了每个客户系统，您将有一些非常不满的客户。

有许多著名的示例，其中编写了新代码来替换旧系统。他们必须在旧系统中显式添加错误的功能，因为用户依赖于该错误（不命名，但我敢肯定您可以在Google上搜索它）。

回归测试基本上是对客户期望发生的事情的测试。在删除回归测试之前，请确保它不会伤害任何人（这几乎是不可能的）。如果你能修复bug 和这个不破的回归测试，然后它是一个真正的解决。

在决定修复错误时要考虑的一些事情……绝非包罗万象。

• 关键（系统崩溃）吗？...很明显，这些问题已经解决
• 客户经常抱怨吗？这可能是一个错误，例如代码中的某些内容已损坏，或者可能是一个要求错误，例如该功能对用户不友好或他们希望它以不同的方式工作。
• 从业务角度来看，修复错误或实施新功能是否更有益？
• 该错误是否需要进行重大的体系结构更改，或者是其他子系统高度依赖的系统一部分？这会极大地影响测试时间，并使验证错误所需的必要测试范围复杂化吗？如果确实很旧，则有时很难通过修改代码的错误部分来确切了解系统还会影响什么。
• 您是否由于系统故障而失去潜在客户？

定义错误。“规范说按日期排序，但按交易金额排序”不一定是代码中的错误。这可能是未记录的更改-有时，某个地方，有人要求更改排序顺序，但规格，要求，手册（甚至UI上的按钮和标签）都没有更改为匹配的，没人介意。对于您显示并将其更改为“按日期”将引起混乱，并且对于您更新ui而言，规格，手册等基本上浪费了您的时间，可能还有一些“破损的Windows理论” 。”

有些事情显然是错误。如果单击此按钮，它将炸毁。或者，如果您在星期一单击此按钮，它会爆炸。除非有人要求您花时间了解原因，否则您将花费​​大量精力进行调查。一旦找到原因，就很可能无法更改，因为这会破坏对用户或管理层更重要的内容。

如果您看到“松懈”（内存泄漏），代码显然需要进行一些与您不匹配的优化，缩进和命名约定，那么当您无所事事的一天或在您自己的时间修复时，这是极有诱惑力的。但是，这些“修补程序”使源代码管理的历史混乱，几乎没有收益，甚至没有收益，冒着诸如“我们从不编译该模块的原因，因为我们在生产中使用的二进制文件是从丢失的代码中构建的，而您只是重写了它” ”，这会严重困扰您“解决”其“错误”的人。

我建议与您的老板一对一。解释一下困扰您的是什么？它是编码样式吗，您确定必须使用户烦恼，数字不准确，不一致或等待灾难发生的事情吗？然后问路，这是关键。

如果您想修复一个已经过时的Bug，则必须小心不要破坏任何现有功能。如果有单元测试，这会更容易，但是鉴于公司和软件的隐含年龄，它们不存在。我建议阅读Martin Fowler的《 Refactoring》一书，因为它讨论了如何在最大程度地减少副作用的同时正确地重构和修复错误。我还建议您确保公司在正常时间内可以解决旧错误。如果您不定时加班，他们可能只会让您这样做。

同样，如果错误已成为一种功能，即由于它确实提供了某些东西，则实际上已由客户端使用，请确保在他们想要这种行为时提供适当的替代（或仅将其记录为功能而不是错误）。