您认为什么是软件缺陷的主要原因（以及如何将其最小化）[关闭]

我将缺陷定义为：

“应用程序设计或代码中的某些阻止其按要求运行的功能。”

我正在寻找有关缺陷原因的想法，例如人为因素，缺乏测试，缺乏原型设计以及减轻这些缺陷的可能想法。

软件缺陷的主要原因是解释。

客户对功能的解释与设计者的解释不同。

设计者的解释不同于程序员的解释。

大多数方法已经发明了应对这种影响的方法。但是最后，我们只是人类，我们并非完美无缺。此外，通常存在时间压力，大多数方法论魔术常常在压力下被跳过。

测试只能及早发现问题。但是，即使测试人员也是人类，不可能进行100％的测试。如果要在Universe结束之前释放。

我认为软件缺陷的主要原因是程序员。

并不是说只是为了好笑，而是因为我在工作中发现的最大问题之一是需求收集不佳，加上对问题域的了解不足，从而导致项目中的重大缺陷和可用性问题。

部分原因是不愿意学习/理解最终用户的术语，从而引起误解。

部分原因是在过程中过早地向与不清楚您正在谈论的内容或重要性无关的人说技术。

最好的例子是，当我听到一位程序员试图弄清楚问题/答案将以字符显示多长时间时...我知道他正在试图弄清楚数据库中要使用的大小字段，但是要求这样做的部门并不是最雾的原因-还是要计算空间。对我们来说，这似乎是显而易见的，但对他们而言，这确实是一个启示。

缺陷的主要原因是管理不善 ;）

认真地说，一个工作状况良好的开发人员，而不是要求过度劳累，降低质量，拥有合适的工具，安静的工作条件等，所产生的错误要少于在压力下工作的人员。

此外，管理层雇用不良的开发人员还有助于增加错误的数量。

管理不善。

（免责声明：我应该雇用和管理开发人员）

我看不到任何一个主要原因，但是没有提到的一个原因是与其他代码的无意耦合。编写具有隐形副作用的代码，突破抽象层，对数据进行假设（变量不可变，常量不可变，并且用户没有输入是安全的），弄乱不需要处理的内容本身等等。

我研究的大多数开发实践都归结为减少N，因为程序的复杂性至少是有O(N^2)可能的O(k^N)。定义N留给读者练习，但我在这里考虑的是诸如循环复杂性之类的事情。封装逻辑和数据具有通过分隔问题来减少N的作用。

无法考虑一切。

不完整

沟通差距。在需求收集中。按计划。在设计文件中。在功能规范中。在代码中（程序员想要什么和他告诉编译器之间的差距）。

社交礼仪。称呼没有能力的人在社会上是不可接受的。

在没有完全理解它们的情况下冲入事物。在不完全了解功能要求或技术架构的情况下开始编写代码。

编程应该几乎是自动的，只需写下不言而喻的想法就可以了。在实践中，我看到代码中有很多麻烦，试图确切地理解代码应该做什么。我本人对此一直感到内gui。

人文错误

时间表压力从某种意义上说是强大的动力。

匆匆忙忙的开发人员不会花时间完全指定需求，也不会充分理解需求背后的意图，也不会充分研究替代方案以找到最佳解决方案，也不会充分考虑所有边缘情况以及他们所做更改的相互作用，或者开发全套测试用例，或完全执行所有单元测试，或执行完全集成测试，或充分考虑平台依赖性，或充分测试安装程序，或充分记录其所做的工作，以便下一开发人员可以理解....

应该提到的另一件事是没有外部测试。当开发人员编写测试并运行它们时，他仅测试其解释而不是实际需求。尽管开发人员编写的单元测试对于捕获某些错误很有用，但是大多数错误将通过这些测试，但并不是用户想要或需要的。未经开发人员以外的任何人未经测试的任何软件都未经测试（而且我并不是说仅运行开发人员的测试）。

这是因为软件工程本来就很复杂。文章“ No Silver Bullet”对此进行了讨论。

具有讽刺意味的是，这里的许多其他答案都以该论文的语言来讲述“偶然地复杂”的主题，而实际上大多数软件开发人员所做的事情都是“本质上复杂的”，因此创建它的本质就是软件很困难，软件会出现错误，而我们的工作就是对付它。

无法将软件理解为状态机的网络，其操作基础（状态，其确定和转换）以及状态机的交互作用的原理。

编写无提示失败的代码与报告所有错误的代码。

缺少检查“不可能发生”或不太可能发生的事情是一个很大的问题。有时候，完美是善的敌人。如果不值得考虑周全的异常层次结构，那么一些快速而肮脏的处理总比没有好。我很大热衷于快速失败，断言和留下断言对发布版本中的性能影响可忽略不计的人。即使在我控制所有输入数据的快速且肮脏的一次性脚本中，我也放置了一些快速/肮脏的错误处理程序，通常只是使用了一个等同于assert但始终存在的函数。我的经验法则是，如果它不太可能发生或您认为它不可能发生，则它不需要通过用户友好的错误消息来优雅地失败，但是它至少应该通过一条错误消息快速失败，该错误消息是给程序员一些有关出了什么问题的提示。

编辑：一种相关的有用策略是将断言用作主要的调试工具，并在调试会话结束后将其保留在其中。从那时起，您的代码库将具有一些内置的健全性检查，这使得相关错误很难再次发生。这对于难以进行单元测试的代码特别有用。

软件缺陷的主要原因是编写代码。

编写更少的代码，您的错误也会更少;-)

一方面，管理。但这不只是PHB。这是代码本身的管理，可能反映或可能不反映公司管理。

在整个“生命周期”需要参加者可以完全投资于质量和制造产品，只是不会死。给定适当的抽象可靠性，软件本身具有永不中断的希望。这仅仅是软件构造者是否对拥有这种完美操作感兴趣的问题。