performance - 更改方法的记录性能是否应被视为重大更改？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

4年前关闭。




Improve this question




似乎软件开发中的一个常见规则是，一旦您部署了一个公共(public) API，尤其是如果您已经记录了该 API(是的，您应该有)，您必须在进行任何可能向后中断的更改之前仔细考虑与该 API 的兼容性，因为此类更改将是重大更改。事实上，我敢肯定，许多开发人员会争辩说，你根本不应该这样做，不管你可能想了多长时间和努力。

有时，开发人员会实际记录方法的性能。许多 MSDN 文档都这样做，例如，使用 Big O notation .改变这一点也会构成“破坏性”变化吗？也许这不是一个明确的问题；换句话说:应该避免吗？

在我看来，在某些情况下，例如，您可能已经开发了一种更好的算法来解决问题，如果您之前曾记录过该算法是 O(N2)，那么您可能会原谅通过将其替换为该高级算法来改进您的 API算法，例如，O(log N)。您的 API 的用户可能会注意到这一点，并且我想他们只会对改进感到高兴。

另一方面，我想知道由于其他原因而恶化 API 组件的性能是否会被认为是“可以原谅的”——例如，您针对最常见的用例进行了优化，这会导致一般情况下的性能更差；您在 CPU 周期内优化内存，反之亦然；您消除了导致其他问题等的外部依赖项。

我的直觉告诉我，提高性能几乎肯定总是可以的。相反的呢？可以吗，假设您更新了文档？只是错了吗？我只是在这里寻找一些合理的指导方针。

Answer 1

好吧，如果你表演更好我怀疑你会收到任何投诉。

否则，我会说这取决于。如果您可以访问所有客户的源代码，那么正确的做法是查看所有客户并验证您的更改不会给他们带来任何麻烦。

如果它比这更复杂，并且您可能会使某些用例的性能显着变差，那么您应该与您的客户交谈并警告他们所做的更改。

如果您也不能这样做(例如:某种收缩包装的 API)，那么是的，最好将更改实现为替代调用或其他东西，而不要理会旧调用。