记录和跟踪编程错误的有效方法是什么？

Question

有时我听到人们讨论了跟踪编程错误的好处，如果没有其他原因，它会增加对常见错误的认识。我已经开始记录我在代码中找到的错误列表，以及可能导致它们的错误。我的主要问题是：

• 我应该保留哪些与我的错误有关的信息 追踪，以便我可以改善 程序员？

以及与此相关的其他几个问题：

• 我开始记录错误后如何使用此信息？
• 追踪错误真的有益吗？

Answer 1

这仅在您实际上对跟踪和审核保持警惕时才有用。当我在一个团队工作时，无论有多少记录，例如我们的生产环境中的服务器都是自然的，并且每隔6个月就无法解析自己的域名或公共IP地址，我会接到一个电话凌晨4点，新开发人员负责的部署团队或开发团队，他们忘记了或者没有意识到。

我记得有一位特别的工程师负责部署并且他有纸质清单，我们建立了部署工具，强迫他记录他的清单，但他总是忘记设置连接字符串（导致凌晨4点的电话）。如果你要警惕地使用它，那就是值得的。

我发现使用它的最佳方法是将规则实现到像fxcop这样的代码分析器中。

Answer 2

我认为比记录个别错误更有用的是确保你真正理解为什么它首先是一个错误。大多数错误源于对某一方面缺乏了解，纠正这种理解并消除了未来的一系列潜在错误。如果我记录任何东西，那将是我从之前不知道的经验中学到的东西，而不是那些错误的具体细节，当你稍后回顾它时可能会产生有限的用途。

Answer 3

• 错误是什么
• 如何避免

将后者添加到适当的清单中，并在适当的时候经常引用

Answer 4

我认为跟踪错误可能值得，但根据我的经验，在某种程度上对它们进行分类会有很大帮助。

每个程序员都会在他们的职业生涯中犯下足够的错误来填补百科全书。如果你从所有这些清单中制作了一份巨大的清单，那么你永远不会完成任何编码，因为你最终会花费你所有的时间来检查清单。所以：以某种对你有意义的方式对你的错误进行分类，这样你就可以在你的列表中查看你目前正在处理的代码中最重要的错误。

另外，就收集内容添加上述内容：

• 错误的症状是什么（所以你以后可以找到）
• 你是如何解决它的

Answer 5

是的，追踪您的个人错误是有益的。有关多个数据点（SEI随机一个），请参阅here's。其中一种方法是Personal Software Process (PSP)。进入这里太长了，但是here's a book about it。 PSP上还有this free SEI publication。

如果你对SEI犹豫不决并认为敏捷是可行的方法，你可能会从像Clean Code: A Handbook of Agile Software Craftsmanship (publisher website)这样的书中获得更好的里程。

底线：纪律严明的开发人员=优秀，没有纪律的开发人员=糟糕。

Answer 6

我还想问一个问题，即准确跟踪错误需要多长时间，以及是否可以更好地直接用于改进软件。如果您可以在最短的时间内完成此操作并且能够回顾您的记录以防止将来出现错误，那么它可能很有价值。从长远来看，我认为最好坚持一个绝对高级别的常见错误列表。

Answer 7

我会寻找趋势或类似类型的错误。一旦你意识到你所犯错误的类型，你就可以对它们保持警觉，或者你可以改变你的编码风格来避免它们。

作为一个例子，我在以前的生活中与我的办公室伙伴密切合作。有一次，我在第一句话的中途解释了一些奇怪的行为，他打断了，“增加你的柜台。”我今天仍然仔细检查我的循环计数器！

Answer 8

不是记录未来的错误，也许您可​​以查看您的错误跟踪记录，并尝试查找常见的错误类型。

我很有启发，我想我会尝试这个tommorow。

Answer 9

“我应该跟踪哪些与我的错误相关的信息，以便我可以作为程序员进行改进？”

阅读其他人的博客。写你自己的。您不必发布它。但你必须将每个错误变成一个故事。

不要将其淹没在元数据中。这不适用于数据库甚至是bug跟踪器。一个错误是一个人做出错误选择并从中恢复过来的故事。

这是你的大纲。

• 上下文。发生了什么事。
• 情况。你试图解决的问题。
• 你做了什么。为什么会这么糟糕。
• 你应该做什么。为什么它更好。
• 改变了什么。你学到了什么。

您还应该以几乎相同的形式记录您的成功。

• 上下文。发生了什么事。
• 情况。你试图解决的问题。
• 你做了什么。为什么它很好。
• 你学到了什么。

如有疑问，请观看电影。认真。角色面临选择，犯错并从错误中恢复过来。故事情节是戏剧的本质。错误是一回事。

Answer 10

小心记录的内容。并非每一个糟糕的情况都是错误的。有些情况是不可避免的，或者到目前为止无法控制，无法对此采取任何措施。

对其他人的错误计划让你陷入恐慌模式不是你的错。你可以仔细记录其他人的错误，但有什么意义呢？如果您正在追踪其他人在做什么，您应该寻求治疗。

糟糕的计划提供了不充分的预算，时间表或有关变更的沟通可能是一个复杂的问题。

1. 您没有预先提供足够的计划信息。
2. 在争夺应对中，你犯了另一个错误，导致问题解决和恢复。

事后看来（总是20/20）你可以看到一个错误的决定。但是，当时，它基于最佳可用信息。这不是一个错误。任何开头的句子“如果我们知道X ......”对于错误分析是没用的。您可以尝试编写下次做出决定时需要知道的所有事项的清单。但是下一次，你不会做出那个决定，而其他一些信息将会丢失。

• 永远不要打电话给别人的行为错误。
• 找出根本原因。当这是你无法控制的事情时，这是一个根本原因。
• 不要追溯性地调用丢失错误的信息。

Answer 11

我一直在想同样的事情。暂时我保留一个带有错误的小电子表格我是正确的。这样做的目的是让我自己意识到更常见的错误。

希望我会开始看到模式并避免一遍又一遍地犯错误。

我发现这使我的工作更有趣，可能是因为我是一个喜欢以结构化方式收集数据和信息的分析人员。

您应该尝试将错误与不适当的工具，习惯，方法或知识联系起来。在大多数情况下，您会发现有一些方法可以更早地捕获错误。我想到了类型安全，单元测试，代码审查，编码标准，更好的API设计，更好的文档和工作环境等事情。

Answer 12

我将JIRA与自定义工作流程结合使用。对于错误，问题关闭前的最后一步是允许我选择“根本原因”的屏幕。我已经记录了我构建的最后3个系统中发生的每个错误的根本原因。