首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >降低大型软件开发项目中的缺陷注入率

降低大型软件开发项目中的缺陷注入率
EN

Stack Overflow用户
提问于 2009-06-29 01:19:22
回答 6查看 4.5K关注 0票数 2

在大多数软件项目中,缺陷来源于需求、设计、编码和缺陷修正。根据我的经验,大多数缺陷来自于编码阶段。

我有兴趣了解软件开发人员用于降低缺陷注入率的实用方法。

我见过以下应用程序,其成功程度和相关成本各不相同

  • 代码检查
  • 单元测试
  • 静态代码分析工具
  • 编程风格的使用
  • 对等程序设计
EN

回答 6

Stack Overflow用户

回答已采纳

发布于 2009-06-29 01:49:20

根据我的经验,允许缺陷的原因是流程的错误,而不是开发人员。有关流程如何影响bug,请参见他们写的东西是对的

竞争性测试

软件开发人员应该希望防止测试人员在他们编写的软件中发现问题。测试人员在发现软件问题时应该得到奖励(不一定是财务方面的)。

注销

让拥有既得利益的软件负责人确保该软件没有问题。在该人满意之前,软件是不发货的。

需求

避免更改需求。从开发人员那里获得实现需求所需的时间估计。如果时间不符合要求的交付时间表,不要雇用更多的开发人员。相反,消除一些特性。

任务交换

允许开发人员在将其分配给另一个开发人员之前完成他们正在处理的任务。回到新任务之后,很多时间都花在熟悉任务被放弃的地方以及完成任务所需的剩余项目上。在此过程中,某些技术细节可能会被忽略。

度量

收集尽可能多的度量标准。每个方法、每个类、依赖关系等代码行。

标准

确保每个人都遵守公司标准,包括:

  • 源代码格式。这可以是自动化的,而不是讨论。
  • 命名约定(变量、数据库实体、URL等)。在可能的情况下使用工具,并每周进行代码评审以强制执行。
  • 代码必须在编译时没有警告。注意并检查所有例外情况。
  • 一致(重新)使用API,无论是内部开发还是外部开发。

独立评论

雇佣第三方来执行代码评审。

合格程序员

雇佣你能负担得起的最好的程序员。放开那些逃避公司标准的程序员。

发布信息

举行评审会议,让开发人员(与整个团队)共享他们对框架的最新更改。允许他们自由地放弃代码的旧部分,以支持更好的方法。

任务跟踪

让开发人员记录每个任务花了多长时间( 15分钟内)。这不是用来衡量业绩的,必须强调的是,这与审查或薪金无关。它只是衡量执行某些技术任务所需的时间。从那里,您可以看到,一般来说,有多少时间是花在系统的不同方面。如果有必要,这将允许您更改焦点。

评估过程

如果许多问题仍然存在于软件中,请考虑重新评估软件的开发过程。指标将有助于确定需要解决的领域。

票数 4
EN

Stack Overflow用户

发布于 2009-06-29 01:35:47

首先,在需求时注入的bug比编码错误要昂贵得多。正确实现的零值需求是零值、未使用(或不可用)功能的一部分.

有两件事可以减少bug的发生。

  • 敏捷。您不太可能在每个步骤(需求、设计等)注入bug。如果你在每一步都没做那么多的话。如果您尝试编写所有的需求,您将犯可怕的错误。如果您试图为下一次冲刺编写需求,则更好的是您将使这几个需求正确。
  • TDD。如果您必须先编写测试,那么您不太可能遇到糟糕的需求或糟糕的设计。如果您无法确定您正在测试的是什么,那么您就有一个需求缺陷。停止编码。离键盘远点。 如果您不知道如何测试它,那么您就有一个设计错误。再一次,停止编码。修正设计,使其可测试。那就往前走。
票数 4
EN

Stack Overflow用户

发布于 2009-06-29 01:36:01

我认为注射速率的主要问题可以从很多方面来解决,而且它因环境而异。

您可以使用许多最佳实践,如TDD、DDD、对编程、持续集成等等。但是,您永远无法摆脱bug,因为产生bug的是人,而不是确切的过程。

但是,IMO,使用bug跟踪工具可以给您提示哪个问题更常见。从那里,你可以开始攻击你的主要问题。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/1056206

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档