bug和debug的定义

写了九年的博客，我猜测至少有一半的内容是围绕代码质量或调试进行的。 虽然我写关于这些主题的文章，花费了很多时间，但是无论出于何种原因，直到昨天，我才意识到我没有一个可靠的关于debug定义，或者甚至是针对debug问题的bug定义。在debug的时候，我们到底在debug什么。 我想我是还是有对什么是bug以及debug代码意味着什么的通常的理解的。 意识到这可能并非如此，我想出了一个定义来解释bugs对我来说是什么......

Bug：一个特性被定义，实现和/或预期满足特定目的，但未能实现的状态。

这是一个相当广泛的定义。 我想说这是一个明显的定义，但考虑到我花了这么长时间才想出来 - 不必介意我在写这个过程中多次修改它的事实！ - 这让我想知道这是不是真的。 让我解释我是如何来到这个的。

首先，我认为观点很重要，在硬件方面，我认为有三个截然不同的观点。 首先是架构师或决策者的视角; 他们的观点就成了定义。 其次是开发人员和功能的实施。 最后是用户的角度以及他们对该功能如何影响其使用模式的期望。 在宏观层面上，成功的应用情景要求，所有三个方面保持一致是似乎是很容易的：一个功能必须按预期定义并正确实施。 但实际上，它比听起来更复杂。

（在细节方面，往往会有很大的摆动空间，完全一致性依赖于团队在常见假设下开发和工作，我知道我们作为一个行业喜欢相信产品说明书中的规格说明，但我倾向于看到常见的假设对feature生命周期比任何spec更有影响力，而且它们只能来自一起工作。）

现在转到“但未能这样做”来查看所有不同的可能故障模式。我们可以定义一个不符合预期的feature：它可能通过设计产生不正确的结果，也许它会产生正确的结果，但形式不可接受; 也许它不会产生一些预期的结果。

然后有一些实施中的错误，我们可以将其分成几个子类别。最常见的是开发人员理解定义，但不会产生与之匹配的实现。较少但仍然很常见的是牢固实现自己的misunderstanding。当然，我们也可能在实施的格式和完整性方面存在问题。

请注意，我正在根据期望定义bug。有时期望是有效的，设计或实施需要改变; 有时需要改变的是期望。

最后，什么时候可以安全地得到期望（即什么时候bug成为bug）？对于我来说，如果某个功能发布给用户，或者只是简单地让用户可以接受，并且它可以工作。如果没有，就有一个bug。这是一个很高的要求，但这对于通过开发和部署来保持一致的质量水平至关重要。并不是很多硬件团队都这样做，这可能就是为什么我们在这里。就我个人而言，我知道每当我绕着这条规则行事时，就会有人出其不意在黑暗深林中释放出一个bug。

说到漏洞中的bug，这里有一个debug的定义...

调试：努力花费时间对bug进行调整并从中恢复。

另一个（故意）宽泛的定义。当我们从端到端的角度来看，开始和结束时，bug会激发一个永远不会存在的长链。认识到存在一个错误; 有时他们很明显，其他时间不是那么多。然后是根本原因分析。基本缺陷可能会直接发送给设计和应用补丁的人。对于更复杂的错误，正确的解决方案可能需要长时间的电子邮件讨论和/或更正式的会议。还有处理bug报告的数据库。不要忘了管理者要专门维护数据库，编写报告等。如何统计回溯和更新补丁花费的时间？最后还有发布补丁，这可能会或可能不需要更多的会议和/或团队之间的协调。这很多，不是吗？ 可能我错过了某些步骤，但底线在这里：调试不仅仅是我们致力于分析和重新编码的时间。

无论如何...给（de）bug的定义一些想法，让我知道你的想法！