由于我的代码存在错误，我有时会对自己的工作感到沮丧。但我认为我不再生产，而且可能比大多数人少。例如，我刚刚完成了一个项目，花了3个月的时间，测试人员发现了大约10个真正的错误，可能还有10个其他的非bug变化（即我可以改变这个按钮的颜色）。我认为经过3个月的发展后这还不错，但是其他人正在看着我，好像我刚检查了最大的垃圾。你觉得怎么样？
编辑：我将添加更多信息。
答案 0 :(得分：80)
汤中的一根头发太多而且头部太少。这完全取决于
答案 1 :(得分：20)
程序员每1000行代码（KLOC）的“外部”错误数量是一个常数。对于非常优秀的程序员来说，这个数字从3-4分到普通程序员的10分不等。
这意味着：对于每1000行代码，您会发现许多“错误”（来自字符串中的愚蠢错别字，以完全伪造一种方法中的代码，从而导致完全重写的灾难性设计）。
请注意，我们通常会犯更多错误，但程序员获得的越多，他们在代码离开桌面之前发现的错误就越多（因此“外部”错误 - >其他人发现的错误）。此外，优秀的程序员往往会制造一些灾难性的错误和更多“愚蠢”的错误（这些容易修复但更令人尴尬的是：“我怎么能监督这个？”）。
有趣的是，bug的数量在语言方面是不变的，所以非常好的汇编程序员会犯4个错误/ KLOC，所以非常优秀的C程序员会犯4个bug / KLOC，所以非常优秀的Java程序员会犯4个bug / KLOC，等
这意味着需要更少代码行来实现所需结果的语言才有优势。
现在回答“什么时候有太多错误？”退后一步。随着您的发展，您将遇到许多错误（大多数是内部错误）。最终产品将有更少的错误，因为大多数将在开发过程中找到。这意味着，当你看起来时，它很重要。这也意味着错误本身的数量并不是“健康”的良好指示。
要想知道你的项目何时开始生病，你必须以某种方式计算你的错误（我写了多少行，我找到了多少错误，我可以修复多少）。这需要付出很多努力，并且通常会产生负面的投资回报率。这些东西很难衡量，写下你在某处发现的错误需要时间，这一切都会让你分心：编写代码。
我的方法是在更多错误出现时开始编写更多测试。感觉到的“越野车”（或我身边的不安）是一个很好的迹象，表明是否有问题。因此，如果您觉得每行代码都会创建两个新错误，那么肯定会发出必须要做的事情。如果你写了很多代码行，并且所有东西都像魔法那样落到了位置，那么为什么要浪费时间来衡量一切顺利呢？
通过编写测试，我可以控制错误，我可以确保它们已经死了。
[编辑]一些链接信息，我得到了我的数字：
答案 2 :(得分：11)
我们没有判断你的背景，所以我会更加关注你周围的人，而不是我们。
那就是说，我认为你不能严格遵守这些数字。如果您错过了客户会立即意识到的一些重要细节，我将不愿意与您一起参与项目。如果你错过了愚蠢的特征 - 蠕变项目，这是更容易理解的。
为那些您不了解日常活动的客户编写软件是一个巨大的问题。可能是你的同事有一种直觉，就是花时间与你尚未拥有的顾客，因此他们的反应。
答案 3 :(得分：10)
这取决于。 Firefox有大约15000个错误，但它被认为是非常有用的。另一方面，我不想在我的起搏器中有一个错误。
答案 4 :(得分：7)
如果您仅在工作三个月后检查您的代码，那么我认为存在严重错误。
对于个人签入周期较短的项目，我认为每个bug都太多了。在编写新代码之前总是修复错误（Joel Test中的＃5）。
答案 5 :(得分：5)
相对而言，3个月的代码中的10个错误可能非常好。如果我做了一个花了3个月的项目，如果能找到200个bug，我不会感到惊讶。
当然，无论是大错误还是小错误，以及它们是否是您在编码时应该捕获的东西，它也会有所不同。如果这10个错误中的一个是一个值得注意的重要问题，那么也许那些其他人在他们的想法中有些合理。
答案 6 :(得分：4)
软件产品质量的感知在程序员和用户之间可能有很大差异。这部分是因为一个人从内部看到它，另一个人从外面看到它。
如果他们只是通过测试中发现的错误计数判断，那么这是不幸的，因为它与他们在实际使用产品时如何享受产品几乎无关。我认为这是对质量的真正考验。将它们放在产品前面，然后看看反应是什么。
作为一名程序员，从你的角度来看代码是美丽的，不幸的是（或幸运的，取决于你的观点）生活中的事实，软件将根据用户使用它的经验来判断。
答案 7 :(得分：3)
您可以参考ISO26262（http://en.wikipedia.org/wiki/ISO_26262）或IEC 61508等功能安全法规。 因为失败/错误的后果是人类生命的丧失 - 或者咖啡是否变冷，这会产生影响。
这些标准描述了必须采取降低风险的方法和情况。
失败次数也与复杂性有关。 （例如：http://www.cas.mcmaster.ca/~lawford/papers/SeparatingSafetyAndControl.pdf，ch 4.4）
DFSS（六西格玛设计）和公理设计是减少产品故障的工程概念。
答案 8 :(得分：3)
作为一个粗略的指标，一个为期三个月的项目是25,000-50,000行代码，因此您应该在内部测试中找到每1000行10个错误，因此通常会有100-500个错误。
如果您的内部测试部门报告0.2个错误/ 1000行听起来像是单独的努力（有人编码检查吗？），那么要么你很好，要么他们不够透彻。
答案 9 :(得分：3)
你应该多么担心取决于它们的类型。它们有多严重，你有多可能在测试者面前发现它们。
如果发票上的总净额和税金总额与总额不匹配，那么您应该担心。如果是两个人同时编辑同一张发票的情况会导致5次发生一次奇怪的事情，那么你可以减少麻烦。
答案 10 :(得分：2)
（不能用作借口）但是大型（非平凡）程序中的代码中的错误是游戏的一部分。这就是为什么我们有测试部门。即使是最好的程序员也会产生错误，因为在数学上不可能证明一块（非平凡的）软件没有任何错误。
http://amartester.blogspot.com/2007/04/bugs-per-lines-of-code.html
答案 11 :(得分：1)
我只是一个完美主义者，但我倾向于检查所有内容，并用我知道用来打破它的东西（以及我以前常用的东西）来测试它，以确保我的新代码能够修复我的旧问题（并且不会“解决”任何旧解决方案。我有一个习惯是挂断修复bug而不是添加我需要添加的东西。这可能是一件好事，但谁知道呢？
我假设你花了3个月写和发现错误，并且你工作3个月后的最终结果有10个错误。这没关系。我不一定说这是好还是坏 - 这取决于你修复bug的3个月中有多少。如果你只是吐出代码3个月然后检查它，1）你做错了，2）这真是太神奇了。但是，如果你花了3个月检查你的代码并确保它有效，我怀疑你是这样，我可能会建议花一点小更多的时间来检查它至少清除5个那10个错误。如果他们是只有错误的，不常见的输入组合发生的极端情况，那么这有点可以原谅，但如果它们相当普遍，你应该考虑花一点额外的时间来追踪它们。
不是说你的工作做得不好，但是如果每3个月你的团队其他成员必须追踪并修复你引入的10个错误以启动和运行你的功能，我可以理解他们有点恼火。
答案 12 :(得分：1)
这是非常主观的：一个人的琐碎错误可能是对其他人的阻挡，甚至是另一个人的特征。可能是需求不明确或不正确，并且反映在代码中并由测试人员提取。测试人员的质量也起着作用，他们找到的相关缺陷越多越好。
答案 13 :(得分：1)
如果其他人认为您的代码是错误的，那么它太多了。感知比现实更重要。如果你只有1个bug就没关系。被认为是错误的（即使它只有1个错误），这意味着你创造了一些相当明显的错误。
像其他人建议的那样，如果10个错误太多，我们无法确定您的情况，因为我们需要知道错误的类型。我建议您查看您正在创建的错误类型，看看是否有任何相似之处。你不明白这些要求吗？那里有很多错误吗？逻辑错误？等等......然后评估这些是否是您应该捕获的错误。如果是这样，请找出下次不注入这些类型的错误的方法。
逻辑/数学/处理错误几乎总是你应该抓住的情况。需求和界面错误更容易理解，因为无论你多么详细地写下来，单词对不同的人来说意味着不同的东西。但是，如果您了解该要求的含义并且仍然存在错误，那么该要求错误是不可理解的。
有人指出每个kSLOC有3个或4个错误是平均的，这对我来说似乎也很高，但我一直在做更糟糕的项目（也许不是）。但是，那些相同的项目也没有非常好的开发人员。 IMO，如果它不是一个模糊的错误或误解，那么错误不应该在代码中。如果是，那么你没有正确地完成你的工作。所以也许10太多了，也许不是，这取决于你正在创建的错误类型。
答案 14 :(得分：0)
从完美主义者的角度来看，1个错误太多了。完美主义观点的相关性恰好是非常主观的。
如果它是收缩包裹的代码，尽可能少的错误会更好，因为它会增加销售量（你不会口口相传它的错误）。
在高安全性应用中，零错误非常关键（起搏器，医院设备，核电站），但这些也往往使用正式语言指定，允许您正确分析设计，以及较长的试用期和更长的时间测试期间真正破坏测试你的代码。
在为特定客户编写的应用中，他们向您支付了多少错误？他们支付快速或高质量的费用吗？预算不足并急于投入生产的应用程序中存在严重错误。
此外，当测试人员测试预生产代码时，这10个错误是什么？如果是这样，那就相当不错了（我上次参与的最后一个项目，我有时会在一天内管理10个错误......但是第二天就把它们全部修好了，因为它们是我刚才没想过的小东西:)）。但是系统上线之前的错误计数几乎没有计算（除非它在发布前一周并且您遇到满足原始要求的问题）
答案 15 :(得分：0)
这是一个单一的比较点（我很想看到其他人）：一个快速的错误查询告诉我，在我去年的开发人员工作中，我修复了107个错误，并假设我修复的内容和内容之间存在粗略的对应关系我最初撰写，可能每三个月创建大约25个错误。
正如人们所说，找到这些数据的合理/有意义的解释有很多混淆（错误有多严重，你做什么样的系统/产品，......），但我会有兴趣看到五个或十个其他人贡献他们自己的“真实世界数据”，只是为了试图平均一些轶事证据。
答案 16 :(得分：0)
很难说有多少错误。我认为每Y行代码涉及X个错误的指标与使用代码行的任何指标一样有缺陷（例如：衡量生产率）。
我的观察是，开发人员和用户/业务人员对错误的含义有着截然不同的看法。对于开发人员而言，发现并修复的每个错误都会增加开发人员对代码的信心，因为您可以看到它变得越来越强大。对于用户，发现的每个错误（即使已修复）降低他们的信心。
它让我想起了我的本科软件工程课程中的一些问题：成功的测试不是通过但是失败的测试，因为它已成功检测到错误，因此将导致改进。以类似的方式成功的代码不成功，因为没有找到错误，但因为发现并修复了错误。如果在一个软件中发现很少/没有错误，我会认为它还没有经过充分的测试。
答案 17 :(得分：0)
有些人宁愿不在他们自己的代码中发现错误时进行宣传，特别是对于没有错误跟踪的初创公司。
我个人认为开发人员在软件中发现尽可能多的错误是一种积极的行为。当然，我说的是专业和有能力的开发人员 - 这样做不会留下错误来赚取布朗尼积分。但是，如果我为同样数量的代码得到1个错误而另一个开发人员发现了10个错误，那么我不会小看这个开发人员，特别是如果我们正在考虑“大”项目
答案 18 :(得分：0)
错误数量不如检测错误所需的时间长。识别错误所需的时间越长，追踪和修复的成本就越高，修复该错误的可能性就越大。经常测试和经常测试（TEATO？）是最好的方法。
答案 19 :(得分：0)
对错误进行分类的一种可能性是使用类似FMEA的方法。 FMEA (Failure mode and effects analysis)通常在设计阶段完成，而不是之后。但是，让缺陷具有可比性的重要性只是一个想法。
衡量缺陷有效“重要”的程度可以是RPN = S x O.
没有软件没有错误。开发人员自己永远不是最好的测试人员。这就是为什么QA的步骤总是必要的原因。那些责怪你的测试人员应该乐意在客户面前找到缺陷。当然还有糟糕的编程或糟糕的设计，但测试也很差......世界并不完美，但我们必须以适当的方式应对所有这些事情。如果您开发的软件用于医疗或军事环境，则使用更严格的软件开发流程。如果使用了所有软件质量工具：设计FMEA，静态代码检查，同行代码评审，单元测试，组件测试，系统测试...... ......没有人应该受到指责。