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


14

我将缺陷定义为:

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

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


5
我将用“用户需求”或“预期行为”代替“需求”,因为甚至需求可能是错误的。
mouviciel 2010年

要求不对吗?(代码正确吗?)

Answers:


13

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

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

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

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

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


如果我只能让该死的阅读器模块正常工作,一切都会很好。
HLGEM

@Gamecat:与世界各地的人们合作时,情况甚至更糟。不仅存在语言障碍(通常,至少有一个参与者英语水平不高),而且还存在文化差异。
Matthieu M.

2
您错过了一个-“程序员的解释不同于编译器的解释” ...;)
Alex Feinman 2010年

@Alex:我知道编译器将对我编写的代码进行处理。这些知识并不是很容易获得,但是我做到了。现在,我们对未编写的代码进行了解释,这与编译器和运行时数据相反。
David Thornley,2010年

@David,除非您编写并维护了编译器,否则您对内部工作的了解是对实际运行情况的抽象,并且这可能是最好的,因为它使您可以在实际的应用程序上花费脑力。
Alex Feinman

8

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

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

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

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

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


8

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

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

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

管理不善

(免责声明:我应该雇用和管理开发人员)


不要以为这是主要问题,大多数开发人员都在安静的条件下工作。我同意AnonJr和Gamecat-无法完全理解问题域,只有快速迭代和测试才能提供帮助。
radekg's

1
大多数开发人员如何在安静的条件下工作?去年访问过的十几家公司中,没有一家是安静的。

良好的管理可以带您走远,糟糕的管理可以将您带到任何地方!
克里斯,2010年

+1关于安静的工作环境。我曾经工作过的每个公司都是一个Dilbertesque隔间农场,您可以不断听到人们离您4英尺远的地方剪指甲,嚼食物和打电话。
鲍比表

5

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

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




4

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

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


3

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

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


从事新工作四个月后,我对“全面了解”任何事情仍然只占很小的百分比。我不会着急;你说的是真的。不过,这么长时间很糟糕。
2010年

我花了一年或两年的时间才能完全使用我所使用的系统(200万行系统)。即使那样,我仍然不知道其中的很大一部分。
Joeri Sebrechts


2

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

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


2

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


2

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

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


1

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


1

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


1

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

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


1

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

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


0

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

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.