性能不佳会被视为软件错误吗？

Question

最近，我处理了一个票据，其中代码产生了受控输入的预期输出。代码通过了单元测试，集成测试和回归测试。但是，当输入很大时，返回输出的代码非常非常慢，尽管当它最终返回输出时，结果是正确的。不用说，我们没有做我们可能进行的所有详尽测试（例如验收测试），因为有太多的变量需要探索和控制（例如，模仿不同部署站点的环境）。

我的一位同事说，因为代码太慢了，所以这是一个错误。＆＃34;我完全不同意这位同事。对我来说，我（天真地）将（软件）错误定义为产生错误输出的任何编程代码。同事在我的定义中添加了一个软件错误，因为任何编程代码都会产生错误的输出，行为和/或副作用;副作用包括巨大输入的长处理时间。

然而，我们认为，我坚持认为这是一个性能问题，而不是一个错误，而同事反之亦然。这一争用点非常重要，因为在仅进行错误修复的代码分支中观察到了问题（错误和/或性能问题）（没有新功能，只有错误修复）。是否是一个错误将决定修复的去向（我不是想要失业）。

所以，我提出了一个问题，快速排序是一个错误吗？它的最坏情况运行时间复杂度是O（n ^ 2）。对于一个巨大的输入，Quick Sort会被认为是一个错误，因为我的同事的性能问题，但不是我的定义。但是，如果性能决定或影响问题的存在或缺陷维度，对于小输入，快速排序不会是一个错误。因此，在我看来，性能几乎应该作为确定问题是否是错误的一个因素。

我想要一些社区反馈，如何定义教科书和维基百科以外的软件错误，以及从业者的经验。我认为我的定义过于狭隘，但我认为我的同事的定义过于宽泛。但我仍然坚持我的直觉和感觉＆＃34;性能问题不是（不应该被考虑）软件错误，至少不是表面上的（可能存在导致性能问题的真正实际错误）。

我可以修改这篇文章，并从程序员的角度说，并尽可能地减少客户/用户。

Answer 1

臭虫这个词起源于一种真正的昆虫，它被发现阻碍了早期计算机中机械继电器的运动（我不知道这个故事是否是伪造的）。目前使用这个词是模糊的，在你的情况下，对生产力有害。术语“缺陷”更有用。同样，如果程序抛出意外异常或崩溃，许多人会使用术语“bug”。这超出了您对错误输出的定义。

由于系统性能是或应该是系统要求的一部分，因此只有在您认为性能不符合要求时才会出现设计缺陷。在您的问题中，如果“快速排序”不符合要求，那么将其纳入您的解决方案是一个设计缺陷。如果要求不足以指定性能，那么这是要求中的缺陷。在提到这样的缺陷时，我经常使用“bug”这个术语（例如，“规范中存在错误”）。

修复规范，让项目经理决定哪个分支包含已实施的返工。根据我的经验，这是基于感知或实际的用户可接受性。

Answer 2

请首先说明您的SLA（服务水平协议）。如果SLA包含性能等非功能性要求，请在此处列出，不论是常量限制，还是输入大小的函数。没有SLA - 没有错误。

Answer 3

开发人员之间的语义争论可以持续一段时间，而且看不到解决方案。在用户中，任何与预期非常不同的特殊情况（包括异常缓慢的性能）都可以算作“错误”。

我个人更喜欢“正确性第一”传统智慧，因为我从来没有因为功能正常但只需要实施级别优化而被咬得太厉害。我一直因为过于兴奋地优化我没有彻底测试过的东西而感到厌烦，并发现了一些新的用例，我把自己搞砸了，并把自己置于一个以前优化的角落里。

“产生错误结果两倍的程序无限慢。” - John Osterhout

......但当然，这只是一个观点（以及近似值？）。每个人都有一个观点，他们都可能有所不同。

我们可以尝试将主观性从场景中删除，并创建关于软件各个部分的预期和不期望的正式规范，但事后通常发现手中有一个剖析器和意料之外的用例，没有提前预见到。

有些值得注意的事情是，在某些类型的任务关键型软件中，如果依赖于快速响应，性能的显着高峰可能会导致某人被杀。在这种情况下，将这种意外延迟定义为故障要容易得多，但听起来并不像是在处理这样一个任务关键型软件。

值得注意的是人们在心理上看待表现的方式。例如，如果你的进度条即使操作需要很长时间也会稳定移动，那么它往往会让人们接受延迟为“正常”，远远超过你的软件长时间无响应而没有指示发生了什么事。实际上，事情往往“感觉”更快，而且“功能性”与进度指示器一样。

我在这里看到的真正问题是，你们两个人在争论是否有缺陷的时候，不应该是这种压力。这一切都在软件改进领域，我们可以做更多令人兴奋的事情而不是争论如何共同优化那些实际上是衡量性能瓶颈的事情。我和那些把所有注意力都放在性能预测上的人一起工作，甚至没有使用剖析器，也没有对正确性给予太多的关注，他们可以让周围的每个人都感到不愉快，所以如果你正在工作，你会表示哀悼其中一种类型。

当我们处于一个只有bug修复的分支时，我只是与整个团队的其他人沟通，并尝试确定是否应该进行优化，也许还要指出目前对于用户来说并不是非常不满意，从业务角度来看，将优化作为未来的改进保存起来可能非常聪明（将每项改进都塞进一次更新中并不一定聪明。）