在大多数软件项目中，缺陷源于需求，设计，编码和缺陷修正。根据我的经验，大多数缺陷都来自编码阶段。
我有兴趣了解软件开发人员使用哪些实用方法来降低缺陷注入率。
我已经看到以下appraoches用于不同程度的成功和相关成本
答案 0 :(得分：3)
首先，在需求时注入的错误比编码错误要昂贵得多。正确实现的零值要求是一个零值，未使用（或不可用）的功能。
有两件事可以减少错误的发生率
敏捷。如果你没有在每一步做得多，你就不太可能在每一步（要求，设计等）注入错误。如果您尝试编写所有要求，您将犯下可怕的错误。如果你试图为下一个sprint编写需求，那么你可能会更好地满足这些要求。
TDD。如果必须先编写测试，则不太可能遇到不良要求或设计不良。如果你无法弄清楚你正在测试什么，那你就有了一个需求错误。停止编码。离键盘一步之遥。
如果您无法弄清楚如何测试它，那么您就会遇到设计错误。再次，停止编码。修复设计，使其可测试。然后继续前进。
答案 1 :(得分：3)
根据我的经验，允许缺陷的是流程的错误，而不是开发人员。请参阅They Write the Right Stuff，了解该过程如何影响错误。
竞争性测试
软件开发人员应该立志防止测试人员发现他们编写的软件问题。对于发现软件问题，测试人员应该得到奖励（不一定是财务方面的）。
注销
让负责软件的人负责确保软件没有问题。在该人满意之前，该软件不会发货。
<强>要求
避免改变要求。从开发人员那里获得实现需求需要多长时间的时间估计。如果时间与所需的交付时间表不符，请不要雇用更多的开发人员。相反，消除一些功能。
任务切换
允许开发人员在将其分配给另一个人之前完成他们正在处理的任务。回到新任务后，花了很多时间熟悉任务被放弃的位置以及完成任务所需的剩余项目。在此过程中，某些技术细节可能会被遗漏。
<强>度量
尽可能多地收集指标。每个方法，每个类，依赖关系等的代码行。
<强>标准
确保每个人都遵守公司标准，包括：
独立审核
雇用第三方执行代码审核。
有能力的程序员
雇用你能负担得起的最好的程序员。放开推卸企业标准的程序员。
传播信息
举行审核会议，开发人员可以（与整个团队）共享他们对框架的最新更改。允许他们自由地弃用代码的旧部分，以支持优越的方法。
任务追踪
让开发人员记录每个任务所花费的时间（在15分钟的括号内）。这不是用来衡量绩效，必须强调它与审查或工资无关。它只是衡量某些技术任务实施需要多长时间的标准。从那里，您通常可以看到在系统的不同方面花费了多少时间。如有必要，这将允许您更改焦点。
评估流程
如果仍有许多问题进入软件，请考虑重新评估开发软件的过程。度量标准将帮助确定需要解决的领域。
答案 2 :(得分：0)
我认为注射率的主要问题可能来自很多来源，并且因环境而异。
你可以使用很多最佳实践，比如TDD，DDD，结对编程，持续集成等等。但是你永远不会摆脱错误，因为创造错误的是人，而不是过程。
但IMO使用bug跟踪工具可以为您提供哪些问题更复杂的提示。从那里，你可以开始攻击你的主要问题。
答案 3 :(得分：0)
编码过程中可能会出现大多数缺陷，但编码缺陷的影响通常远低于理解需求过程中和开发弹性架构时产生的错误的影响。因此，使用简短的可执行生成迭代集中于
可以在一个显着范围的项目中节省大量的时间和集体的胃肠。
单元测试，场景测试和静态分析工具可以在创建后检测到缺陷，但是为了减少首先创建的缺陷数量，减少开发人员必须忍受的中断次数：
答案 4 :(得分：0)
第1步 - 了解您的缺陷注入位置。
使用Orthogonal Defect Classification (ODC)等技术来衡量软件生命周期中何时注入缺陷以及何时检测到缺陷。一旦您知道何时注入缺陷并确定何时发现缺陷，您就可以开始了解缺陷注入和去除过程中的缺陷。
第2步 - 开发缺陷“过滤器”并调整您的流程
一旦您知道何时注入缺陷，您就可以制定策略以防止它们进入系统。不同的策略在软件生命周期的不同阶段是有效的。例如，静态分析工具无助于产生需求的缺陷，而是应该进行某种同行评审或检查，甚至可能改变指定要求的方式，以便您使用自动分析或实现更多意义签字等等。
一般情况下，我会使用检查，静态分析和测试（许多不同类型）的组合来尽可能多地过滤错误，因为我可以尽快注入错误。
答案 5 :(得分：0)
另外：
项目知识库。它说明了我们如何在这个项目中进行活动X（如表格验证＆＃39;）。这样可以统一和重复使用经过测试的解决方案，防止在重新发明轮子时注入错误。
生产错误监控。当生产错误发生时，它会被调查。为什么没有抓到这个bug？我们如何确保这不会再次发生？然后我们相应地改变过程。