如何对待用户认为是功能的错误？

问题：

解决最终用户认为是功能的错误的正确方法是什么？

详细说明：

我猜想，如果很大一部分用户希望将其作为一项功能，应该将其“未固定”还是“固定”才能更稳定？但是，如果很少的用户期望它是一项功能，例如0.1％或1％，该错误必须得到解决。

从理论上讲，由于这是一个较小的错误修复程序，因此按语义版本控制考虑，它可以称为PATCH：xyZ但是，由于它确实破坏了向后兼容性（即使仅针对少数用户），因此应该是主要的提高：Xyz正确吗？只要有文件记载，它是否仍可以称为PATCH（因为它原本不是功能）？

编辑：在这种特定情况下，这是其他开发人员使用的内部使用库的API中的错误。

我猜想，如果很大一部分用户希望将其作为一项功能，应该将其“未固定”还是“固定”才能更稳定？

该错误是否会增加价值？如果是这样，它更多的是功能。有时，“错误”最终可能会成为增值“功能”。

很难真正得出结论，因为每种情况都会有所不同。

在这种情况下，这是其他开发人员使用的内部使用库的API中的错误。

在这种情况下，作为向后兼容性的下一个重大更改，我将包含一个修复程序。您实际上不能在大多数环境中始终如一地做到这一点，并且可能为此制定了时间表/时间表。

作为开发人员，我要处理的最后一件事是行为不正确或不一致的API。错误被认为是这个。

至少，在内部创建某种“当前版本的已知错误”文档/ Wiki，以便您可以确保所有内部用户都知道该功能类似于错误。希望您有足够的测试，涵盖了人们使用“功能即缺陷”功能的领域，这样您就可以在修复缺陷时/何时看到问题何时何地发生。

我建议使其更稳定。用户是您软件工作的规范来源。如果他们想要它，并且已经依赖它，我想三思而后行。

电子游戏“部落”中的“滑雪”机制就是一个很好的例子。最初是物理引擎如何处理在山坡上跳跃的错误，最终成为了核心游戏机制之一。如果您感到好奇，可以在这里阅读更多内容。

由于该错误位于库中，因此可以采用以下另一种方法：

1. 克隆错误的库函数。在许多情况2下，在这种情况下，人们只需在函数名称后附加a ，但是，如果您要对该函数的接口进行其他更改，则可能会给它一个完全不同的名称。

2. 仅修复克隆中的错误（并在使用克隆时实施您想要的所有其他接口更改）。

3. 声明原始功能已弃用。

4. 在即将发布的主要版本中删除原始功能。

这种方法对于其接口从根本上被破坏的功能特别有用：您不会立即破坏用户代码，但是会向任何依赖破坏代码的人警告，以过渡到使用固定代码。即使人们不注意警告，但是一旦您真正删除损坏的功能，他们也不会真的怪您。

在这种情况下，这是其他开发人员使用的内部使用库的API中的错误。

如果其他开发人员认为该行为是功能，则很可能他们已经使用了该行为并在其上构建了可运行的软件。修复该错误可能会破坏他们现有的代码，并且他们会为此怪罪您。这使得修正错误成为一种折衷，您必须考虑

• 修复该错误真的很重要吗，例如，由于未修复该错误，很有可能让您的API用户崩溃其应用程序？还是仅仅是关于API的一致性？

• 还是保持现有软件稳定并且库向后兼容更重要？

问题的答案并不总是那么简单，您必须考虑到API的可能用户数量，他们需要更改软件的潜在工作量，更改API会破坏的软件数量，还有如果不修复API 可能会发生的风险。

仅仅因为将错误修正更改记录在“下一个主要版本的重大更改列表”中并不能使您的客户满意-如果这样做，至少应该有一些防弹的理由，为什么您不能让该API如此以前。通常，保持向后兼容性比修复bug更重要。因此，仅当您可以估计对用户群及其软件的影响并且确定他们在尝试更新到最新库版本时不会为他们做出不合理的努力时，才进行修复。而且，如果您没有足够的信息来对此做出正确的估计，那么最好不要更改其行为。

（是的，如果您要进行向后兼容的API更改，则您的版本号必须清楚地表明这一点，无论您是否将其命名为“ bugfix”都无关紧要）。

接受它。它可以使您的整个产品成为现实。

GunZ：Duel（在线游戏）有一个bug，您可以利用它并不断滥用它来改变整个游戏过程（称为K-Style；在YouTube上进行查找）。这使整个游戏方式更具挑战性。它花了很多技巧，使它变得令人惊奇和有趣。.如此有趣，甚至主持人都公开地将其用作他们的主要演奏风格。
这就是创造游戏的原因。
我已经好几年没玩游戏了，但是直到今天，作为一名游戏玩家，这是我有史以来最喜欢的游戏之一，因为它是如此的基于技能，也是如此有趣，而所有这些都是因为一个错误而给力。

他们最终确实修复了它，但是人们非常讨厌它，以至于开发人员将其严重错误修复了。

因此，我的答案是稳定并维持（如果需要，请重构）。

有人说这个美丽的故事，对于没有直接优势的事情，我认为没有相同的答案。如果您的错误引起了一个事件，而该事件导致了优势，那么通常更聪明的方法是修复该错误，并找到另一种方法来实现它。如果超出范围，请考虑仅出于超出范围而将其排除在外，或者创建另一个模块（可能是一个很小的模块）来介绍它。基本上：不违反单一责任原则。