vector不是模板 错误_这不是错误，而是…

vector不是模板 错误

错误何时会变成错误？

谁认为这是一个错误？

多少腿呢羊羔有，如果我说的尾巴是腿？ 答案是4，仅因为我说尾巴是一条腿，并不意味着它是一条腿！

错误应该很明显，但是我们说这不是错误，它是一个功能，因为通常它并不明显。 沃森·汉弗莱（Watson Humphrey）认为我们应该使用“ 缺陷”而不是“错误”一词，因为大多数人并不认真对待错误，所以让我们改用“缺陷”一词。

那么什么时候缺陷会变成缺陷呢？

• 什么时候质量保证告诉您您有缺陷？
• 产品管理何时说这是缺陷？
• 当客户说这是缺陷吗？

答案是： 以上都不是 。 现在可能会发现存在问题并且需要更改代码，但是只有在以下情况下存在缺陷： 代码的行为与需求规范不同 。 这很重要，因为大多数系统都未指定 （如果完全指定了）。 如果代码与规范不同，则只能将其视为缺陷。 我们将缺陷称为未记录的功能，因为我们知道问题在于从未编写要求。

要求不完整和不一致

许多组织在开始开发之前就没有创建足够完整的需求，这是因为他们不知道如何正确捕获需求，或者是因为他们没有能够捕获完整需求的资源。

不完整（和不一致）的要求和不切实际的期限通常迫使开发人员做出有关如何实现功能的决策。 最终结果是定期告知开发人员其代码中存在缺陷。

尽管此过程很常见 ，但却具有破坏性 。 当需求未指定时，不一致的开发人员最终需要进行认真的返工。 返工可能需要进行重大更改，从而影响代码的体系结构。

找到解决方案（如果可能）所需的时间很少包含在项目计划中。 使事情变得复杂的是，那些不愿意花时间来创建需求的组织也往往低估了他们的项目。 这给工程部门带来巨大的压力。 这促进了软件开发中的5个最坏的做法（请参阅Stop It！不……真的停止它。 ）

当性能较差或未记录在案的系统需要未指定的更改时，我们应将其称为更改请求，而不是缺陷。

工程师仅解决了54％的问题

严重误导了所有缺陷必须由工程部门解决的态度。 Capers Jones对18,000多个项目的分析表明，工程师只能解决所有缺陷中的约54％！ （仅以下3个突出显示的行）

缺陷角色类别	频率	角色
需求缺陷	9.58％	BA /产品管理
建筑或设计缺陷	14.58％	建筑师
代码缺陷	16.67％	开发者
测试缺陷	15.42％	质量保证
文件缺陷	6.25％	技术文件撰稿人
数据库缺陷	22.92％	数据库管理员
网站缺陷	14.58％	运营/网站管理员

这意味着将浪费宝贵的时间分配给开发人员无法解决的问题。 将问题重定向到正确的人所需的时间是消防的主要因素

控制缺陷过程

对于大多数组织而言，修复缺陷过程涉及正确理解和分类缺陷。 没有跟踪缺陷的不同来源的组织可能有一个错误跟踪器，该跟踪器已经死了。 这是解决问题的方法，请参见Bug Tracker地狱和如何逃生！

至少您需要实施需求缺陷 ，一旦您发现了由于需求不佳而引起的问题，它将使羞耻的白光闪耀在捕获您的需求的资源上。

一旦意识到系统中存在多少需求缺陷，就可以开始将需求问题通知高级管理层。

减少消防

减少灭火的最好方法是开始编写更好的要求（或编写要求）。 为此，您需要确定以下哪项是无效的：

1. 没有足够的时间分配给需求阶段
2. 不熟练的人正在捕获您的需求

很可能这两个问题都需要在您的组织中解决。 当需求不完整且不一致时，您将举行无休止的消防会议，涉及每个人（请参阅软件项目中“消防”的根本原因 ）

如果没有相关要求的文档，如果有人告诉您您已编码缺陷，请站稳脚跟。

参考： 这不是错误，是……来自我们的JCG合作伙伴 Dalip Mahal，在Accelerated Development博客上。

翻译自: https://www.javacodegeeks.com/2013/10/its-not-a-bug-its.html

vector不是模板 错误