开发人员是否应将错误输入错误跟踪系统？

在开发（功能或错误修复）时，有时我会偶然发现与我正在研究的内容不直接相关的错误。在那种情况下我该怎么办。修好吗？试着记得以后再修复它吗？写下来吗？还是将其输入错误跟踪系统？

我通常将其输入到Bug跟踪系统中，然后让过程进行自我显示（例如，分类，分配等）。但是，我几乎从未见过其他开发人员输入错误。（这是为什么？）

如果您发现了错误，无论您是否要修复它，我都不会想到没有任何理由不将其输入到错误跟踪系统中。毕竟，这就是错误跟踪系统的用途。

在某些情况下，将其报告给具有更多系统处理经验的质量检查人员可能更有意义，但无论如何都应跟踪该错误。

开发人员不应该输入错误，这可能是出于某种原因（无论是否有效）。一个可能的原因可能是外部人员可以看到该错误跟踪系统，并且报告的错误太多，这看起来很糟糕。这是一个非常糟糕的原因，应该以其他方式解决该问题，从而仍然可以跟踪错误。问你老板

（当然，如果您仍在处理代码中的错误，并且未在已发布的任何内容中显示该错误，则无需在系统中对其进行跟踪，尽管源代码中的TODO注释可能是举个极端的例子，“此代码无法编译，因为我尚未在此行的结尾键入分号”，这不是可报告的错误。）

至于为什么其他开发人员不输入错误，则需要询问他们。他们可能应该。

在两种情况下，您都必须在错误跟踪系统中输入错误：

• 当错误直接与您正在处理的代码有关时，

• 当错误涉及您现在不使用的代码或其他开发人员正在使用的部分时。

这是必不可少的，因为漏洞跟踪系统用于跟踪漏洞。每个错误。如果发现错误，请不要修复它。通过错误跟踪系统对其进行记录。稍后，运行旧版软件的客户将报告一个完全相同的错误，您可以将其链接到您的报告。如果没有任何可链接的内容，您将浪费时间（或您的同事）在以前的版本中搜索错误，然后尝试解决它，最后发现该错误已经神奇地解决了。

这也解释了为什么自由职业者必须同时使用版本控制和错误跟踪系统：这两个工具不仅适用于团队。

没有正当理由不将缺陷输入缺陷跟踪系统。我看到不进行跟踪而应用错误修复的唯一地方是因为该过程从根本上被破坏了。在这种情况下，请修复该过程。

不参加的原因是：

• 该过程基于缺陷报告进行度量和惩罚-不报告，不受到惩罚。在这种情况下，请离开组织
• 该过程是一个负担-花费太多的精力和时间来修复缺陷并达到修复的目的。应该更改流程，以允许开发人员通过分类/接受/修复流程快速跟踪轻量级错误。
• 有些开发人员是懒惰/草率/黑客，他们不在乎他们所做的事情会对其他人产生什么影响。招聘专业开发人员。
• 我是一个单人乐队，看不到重点。去一个2人乐队工作，你会...

立即修复该错误可能不是一个好主意。首先，其他人可能正在进行相同的修复，从而导致重复的工作，而且，根据您所遵循的开发方法，确定下一个工作的优先级（修复错误或实现新功能）更多是管理决策，然后是开发决策。

该决定不明确，涉及权衡。

（一些）PRO

错误跟踪对于沟通至关重要，特别是在大型团队中。多看代码的最大好处之一就是能够及早发现问题，如果在开发过程中未记录或跟踪错误，那么这种好处就会丢失。

• 通常，在您已经了解一部分代码的情况下，很容易修复它们。
• 即使在较小的团队中，通过能够列出错误并在修复错误方面取得进展，在士气方面也有很多好处-有时，即使在一个人的项目中，士气收益也至关重要。
• 事后进行准确的错误检测可能非常困难-看到代码中的错误可以节省很多以后的工作，以侦探角色，从而找出问题的最初出处。
• 作为开发人员的一般开发人员，请注意所看到的错误，并养成认真地改进/清理/阅读代码的习惯，这对您有好处

一般来说，记录错误是一个好习惯。

（一些）缺点

将错误输入到错误跟踪系统可能会很麻烦，很耗时，并且确实会对开发工作造成破坏-在大型团队中工作时更是如此。您可能会期望：

• 在输入之前检查您的输入是否重复（这甚至可能是隐式的，不建议仅将其关闭而将错误输入队列）
• 为您的报告提供可重复的测试用例
• 接受以后有关错误详细信息的问题的打扰，在编写时接受/验证修复程序
• 考虑经常在错误跟踪系统中收集的不相关信息，例如，受影响最大的产品，错误的优先级等。

有时，错误跟踪并不是最有效地利用您的时间。

这是两个很难平衡的通用原则-找到一个好的策略有点技巧。在这种情况下，我认为最好采用灵活的启发式方法，根据给定的项目，团队，工作环境和您的一般技能进行调整。我的策略通常遵循以下大致模式：

• 一整天都记录日志，一整天都在某个地方。可能是粘性的，也可能是侧面的文件。也许您只记录一个文件名和行号，甚至更多。不要让问题过多地干扰您当前的思路。

• 在每个新工作日的开始时要花一些时间，作为工作热身的一部分，以处理胶粘物。从前一天开始，我需要10到15分钟来浏览检测到的问题列表，然后执行以下最快的操作：

  • 修复并提交问题（可能是一种衬纸修复或拼写错误）。如果不允许您在没有错误报告的情况下进行提交，请为小的提交创建一个辅助项目。当在副项目中积累了足够多的修复程序时，需要花费几个小时来记录它们并提交。
  • 将问题记录在错误跟踪系统中（对于明显的问题，需要更长的时间解决，但不会造成繁重的开销）
  • 将问题记录在“要在不忙时查看”文档中（我通常会在源代码中添加“ // TODO-这看起来很糟，请修复它”）。定期花一天的时间（我每月尝试一次）浏览并适当记录下来-功能请求，错误报告，与经理讨论等。

随着时间的流逝，我发现各种调整都是有用的。例如：

• 在更严格的环境中，我可能只是将错误报告工作交给测试团队-让测试人员不时与我见面一个小时，将问题列表交给他们，然后让他们进行日志记录。在测井测试非常重要的环境中，通常测试人员会很乐意免费提高他们的生产率。
• 一些团队拒绝允许任何没有客户错误报告的修复程序。我会保留一个充满修复程序的项目，并在客户报告相关问题时立即提交它们，以获取免费的布朗尼分数。
• 一些团队要求“拥有”一段代码的人是执行修复的人。我会将代码“所有者”视为测试负责人，并举行非正式会议以偶尔解决问题

我发现，通常，当您遵循这种策略时，越来越多的同行和其他公司成员将开始尊重您的工作和对质量的承诺。经过足够的时间后，您将具有根据自己的喜好优化整个过程所需的尊重和权威。留意此类机会，并酌情把握。

我相信，如果一个开发人员遇到不涉及他们在做什么，他们不会被修复bug，就应该将其输入到系统只是有一些它的记录。这样，当质量检查人员开始测试时（并且仍未得到修复），您可以将此错误列表称为“已知缺陷”，这样他们就不会开始报告相同的错误了。

也许其他发现错误的开发人员如果计划修复它，他们自己会对其进行跟踪，但是在那种情况下，他们冒着2个开发人员独立查找和修复同一错误的风险。

我还要补充一点，即使该错误已得到修复（在问题跟踪器中记录该错误之前也不应该发生），跟踪它也是一个好主意。

这样，如果该问题将来会再次出现（发生回归！），相对容易地将问题识别为“已处理”并阅读如何第一次解决。

这是为什么？因为大多数开发人员都在研究他们必须提出的问题以及他们必须编写的代码，然后才更容易理解。

但是，这是否正确取决于您的过程。您有质量检查小组吗？您认为他们介意您是否只是更改无法跟踪的代码？那代码审查呢？它会跳过那个裂缝吗？那生意呢 他们是否需要知道您已修复错误，以便以后不再提出相同的错误？

那其他开发者呢？如果他们同时以不同的方式修复该怎么办？如果他们以后发现类似的错误，而您所能做的就是说：“哦，该死，我知道我们以前有过这样的事情-现在是什么？”

在错误跟踪系统中记录错误的原因大约有百万。如果您确定自己没有遇到任何问题，那么一定不要打扰。但是，即使您完全不确定，也应该记录下来，即使大多数人没有。

从根本上说，编程是一项复杂的工作。错误很复杂。所以我以前通过两个因素来评估错误：

1. 以后，这类错误多久会再次出现？无论此估计是否正确，请继续进行估计。
2. 当此类错误再次出现时，是否易于理解？当您分析此错误并修复它时，这是准确的。

我将错误归类为以下类型之一：

1. 将来可能再次出现，并且易于理解
2. 将来可能再次出现，但很难理解
3. 以后很少再次出现，并且易于理解
4. 以后很少再出现，但是很难理解

在情况1中，食谱或FAQ是团队将来修复此类错误的好工具。

在第2种情况下，对团队来说，详尽而可理解的记录是必要的，因为如果另一个程序员再次忍受此类错误，那将是一种浪费。例如：内存泄漏。

在情况3中，我认为没有什么可记录的，没什么大不了的，因为您不会花费太多时间来修复一个简单的错误。例如，HTML中元素ID的错字。

在情况4中，此类错误会造成两难选择。需要花费一些时间来编写详尽且易于理解的记录来描述此类错误。但是此记录将来很少使用。但是，如果没有记录，出现此类错误将再次变得困难。例如，此类错误是由于某人计算机中的计算机病毒而出现的。

当然，您应该输入它。如果那是您的正常流程，或者至少将其报告给质量检查人员。

即使您只是自己修复该错误，也需要记录更改，以便可以对其进行测试以确保该修复程序确实有效并且没有退步。用户也有可能在某个时候报告该错误，如果该错误已在系统中并标记为已修复，则您的支持人员可以告诉他们已解决此错误。

确实，您应该将它们记录在系统中，并且如果不进行练习，那么开始是个不错的选择。

在过去，我是产品团队的一员，当时我们处于新产品的Beta版发布中，有时我们偶尔会发现一些错误，这些错误在那时我们用来记录下来并邮寄给处理模块的相应人员（一个错误跟踪系统，但我们没有想到将其推送到此处）。后来，随着时间的流逝，由于其他优先事项，邮件中的项目开始被忽略，最终导致一些不眠之夜。

然后，轰天，涅rv！即使您发现了似乎是一个错误的东西，也有可能不是它（您对流程的想法是错误的/有缺陷的），我们为什么不使用错误跟踪器？它至少构成可以进行测试的列表，并且在所有反馈中最重要的是，为什么它很关键，或者在另一方面，它是完美的，并且由于1 ... 2 ...的原因，它应该如何工作。 。

现在，您有了清单，对于那些误解了应用程序某些部分的人，他们将得到反馈，他们可以根据这些反馈来澄清自己的想法。双赢。

假设它已经过测试（尤其是发布的话）的代码是绝对的。

有许多的原因：

内存 -任何给定的开发人员都可能真正忘记该错误。

指标 -发现，关闭的错误数量以及所花费的时间可以作为易于捕获的良好指标，以告诉您代码质量如何提高

紧急性 -对于开发人员来说，这似乎是世界上最重要的事情，但是，解决此问题所花费的时间可能会花在最终用户首先想要的事情上（请参见内存）。

复制 -可能已经被发现并且正在接受其他人的检查/修复。或者，它可能已经违反了紧急性规则并被推迟了。当然，您再次发现它的事实不仅意味着它不应该执行，而且可能意味着（随着它的不断出现）现在更加迫切需要修复。

根本原因分析 -最容易修复的错误是从未存在的错误。团队可能应该在研究此错误以找出其产生原因。这样做不是要惩罚负责任的人（永远没有帮助），而是要找出将来如何避免这种情况。

更广泛的影响分析 -最便宜的错误是发现之前发现的错误。通过查看此错误（尤其是在进行了根本原因分析之后），可以很快清楚地知道此问题可能存在于代码的其他位置。结果，团队可以选择在更尴尬的时刻抬起丑陋的头之前找到它。

花在这些代码（如果有）上的时间在很大程度上取决于代码的成熟度和质量级别。对于进行演示代码工作的小型团队而言，根本原因分析可能是过大的，但是从事业务关键开发的大型团队可能需要有效地学习课程。

根据经验，开发人员避免使用该工具有两个主要原因：

1. 错误处理工具和/或过程被认为对于开发而言过于繁重
2. 开发人员发现，解决该错误的精神挑战比他们当前正在研究的东西更有趣。

项目1暗示可能需要一个更好/更简单的系统；或者可能需要对现有系统进行更具说服力的辩护。

第2项应该是对当前任务分配的开发线索的有用警告标志。

我大体上同意FrustratedWithFormsDesign，但我认为将整个问题分为两个方面更加清楚：

• 错误报告。
• 错误修复。

这些通常被视为相同，将它们分开几乎可以肯定会有所帮助。

可以通过以下方式处理这些问题：错误报告：-像大家所说的那样，将其放入系统中。

错误修复：-每隔一两个星期（根据您的开发进度等），每个人都会聚在一起讨论项目，并确定应该修复的内容，由谁进行修复等。每个人都在同一页面上，可以看到需要解决的问题完成。在敏捷开发中，这是Sprint规划会议。

人们想要使用的一个好的工具也有很大的不同。我喜欢Pivotal Tracker，当我开始使用它时，它通过了我的“非常有用的工具”测试，目的只是为了跟踪我想做的事情或在自己的私人项目中修复！

如果看到什么，那就说些什么！

我什至输入有关自己模块的错误报告，因为我不想中断当前的任务。而且我可以确保包括所有复制步骤：-)

而且，当其他人看到您将某物列为已知错误时，这种方法会更好。他们想知道别人也找到了它。

我认为这更多是政治问题，而不是最佳实践问题。

• 错误输入会责怪他人吗？
• 客户可以阅读错误条目并看到存在附加错误。这是贵公司的声誉问题吗？
• 这真的是您不知道的错误或功能吗？
• 谁将支付错误修正？

在我看来，将非微不足道的错误添加到跟踪器系统中是一个好习惯，但是管理层必须决定如何应对。

对于非平凡的情况，您不应在未咨询他人的情况下解决此问题

• 这真的是一个错误，而不是功能
• 其他人可以测试此修复程序，并确保该修复程序不会引入其他错误（回归）