【发布时间】：2010-09-22 19:23:02
【问题描述】：
有时我听到人们讨论跟踪编程错误的好处，如果不是为了提高对常见错误的认识的话。我已经开始保留我在代码中发现的错误列表，以及可能导致这些错误的原因。我的主要问题是：
- 我应该保留哪些与我的错误相关的信息 跟踪，以便我可以提高 程序员？
还有一些与此相关的其他问题：
- 我开始记录错误后如何使用这些信息？
- 跟踪错误真的有用吗？
【问题讨论】：
标签： tracking
【发布时间】：2010-09-22 19:23:02
【问题描述】：
这仅在您对跟踪和审查保持警惕时才有用。当我在一个团队工作时，无论有多少记录，例如我们在生产环境中的服务器被 nat，无法解析自己的域名或公共 IP 地址，每 6 个月，我都会接到一个电话凌晨 4 点，来自新开发人员负责的部署团队或开发团队，他们要么忘记了，要么不知道。
我记得一位负责部署的工程师，他有纸质清单，我们为他构建了部署工具，迫使他记录清单，但他总是忘记设置连接字符串（导致凌晨 4 点的电话）。关键是只有当你要小心使用它时才值得。
我发现使用它的最佳方法是将您的规则实施到 fxcop 之类的代码分析器中。
【讨论】：
-
我认为他们在凌晨 4 点给你打电话是因为这种情况有点不合适。
-
我完全同意；但是，当您正在部署一个有 20,000 名付费客户预计将在三个小时内启动并运行的站点时，您可以尽其所能。随着时间的推移，我们改进了流程（尝试尽可能多地消除人为因素）
我认为，比记录单个错误更有用的是确保您一开始就真正理解了错误的原因。大多数错误源于对一件事或另一件事缺乏理解，纠正这种理解，你就可以消除未来的一整套潜在错误。如果我要记录任何内容，那将是我从以前不知道的经验中学到的东西，而不是所犯错误的细节，当你稍后回顾它时，它的用处可能有限。
【讨论】：
- 出了什么问题
- 如何避免
将后者添加到适当的清单中，并根据需要经常引用它
【讨论】：
我认为跟踪错误可能是值得的，但根据我的经验，在某种程度上对它们进行分类很有帮助。
每个程序员在其职业生涯中都会犯足够多的错误，足以填满一本百科全书。如果您从所有这些清单中制作出一个巨大的清单，那么您将永远无法完成任何编码，因为您最终将花费所有时间来查看清单。所以：以某种对你有意义的方式对你的错误进行分类，这样你就可以浏览你的列表，查看你当前正在处理的代码中最重要的错误。
此外，就收集的内容而言，添加到上述内容：
- 错误的症状是什么（以便您以后找到）
- 你是如何实际解决的
【讨论】：
是的，跟踪您的个人错误是有益的。参考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) 这样的书中获得更好的成果。
底线：有纪律的开发人员 = 好，没有纪律的开发人员 = 坏。
【讨论】：
我还想问一个问题，准确跟踪错误需要多少时间，以及是否可以更好地将这些时间直接用于改进软件。如果您可以在最短的时间内完成此操作，并且能够回顾您的记录以防止将来出现错误，那么它可能很有价值。但从长远来看，我认为最好坚持列出您所犯的常见错误的绝对高级列表。
【讨论】：
我会寻找趋势或倾向于重复出现的类似类型的错误。一旦您意识到自己犯的错误的类型，您就可以对它们保持警惕，或者您可以改变您的编码风格来避免它们。
例如，我在前世与我的办公室同事密切合作。有一次，我解释了一些奇怪的行为的第一句话讲到一半，他打断了“增加你的计数器”。我仍然今天仔细检查了我的循环计数器！
【讨论】：
也许您可以查看您的错误跟踪器历史记录，而不是记录未来的错误，并尝试找出不断发生的常见错误类型。
我很受启发，我想我明天会试试这个。
【讨论】：
“我应该跟踪哪些与我的错误相关的信息，以便我作为一名程序员可以提高？”
阅读其他人的博客。写你自己的。您不必发布它。但是你必须把每个错误变成一个故事。
不要淹没在元数据中。这不适用于数据库甚至错误跟踪器。错误是指某人做出了错误的选择并从中恢复过来的故事。
这是你的大纲。
- 上下文。发生了什么事。
- 情况。您试图解决的问题。
- 你做了什么。为什么不好。
- 你应该做的。为什么会更好。
- 发生了什么变化。你学到了什么。
您还应该以几乎相同的形式记录您的成功。
- 上下文。发生了什么事。
- 情况。您试图解决的问题。
- 你做了什么。为什么很好。
- 你学到了什么。
如有疑问，请观看电影。严重地。角色面临选择，犯错误并从错误中恢复。那个故事情节是戏剧的精髓。错误是一样的。
【讨论】：
小心你记录的内容。并非所有糟糕的情况都是错误的。有些情况是不可避免的，或者远远超出您的控制范围，以至于无能为力。
其他人的错误计划让您陷入恐慌模式并不是您的错误。你可以一丝不苟地记录其他人的错误，但有什么意义呢？如果您正在跟踪其他人在做什么，您应该寻求治疗。
提供不充分的预算、时间表或关于变更的沟通的糟糕计划可能是一个复杂的问题。
- 您没有预先提供足够的规划信息。
- 在争先恐后的应对中，您又犯了一个错误，导致问题得到解决和恢复。
事后看来（总是 20/20），您可以看到一个错误的决定。然而，当时，它是基于最佳可用信息。这不是一个错误。任何以“如果我们知道 X...”开头的句子对于错误分析都是无用的。您可以尝试编写一份清单，列出您下次做出该决定时需要了解的所有事项。但是下一次，您将不会做出完全正确的决定，并且会丢失一些其他信息。
- 永远不要说别人的行为是错误的。
- 找到根本原因。当它是你无法控制的事情时，它是一个根本原因。
- 不要追溯调用出现错误的信息。
【讨论】：
我一直在想同样的事情。目前我保留了一个小电子表格，其中包含我纠正的错误。这样做的目的是让自己意识到更常见的错误。
希望我能开始看到规律，避免一遍又一遍地犯常见错误。
我发现这让我的工作更有趣，可能是因为我是一个喜欢以结构化方式收集数据和信息的分析人员。
您应该尝试将错误与使用不适当的工具、习惯、方法或知识联系起来。在大多数情况下，您会发现有一些方法可以更早地捕获错误。我想到了诸如类型安全、单元测试、代码审查、编码标准、更好的 API 设计、更好的文档和工作环境之类的东西。
【讨论】：
我将 JIRA 与自定义工作流程一起使用。对于错误，关闭问题之前的最后一步是允许我选择“根本原因”的屏幕。我对我最近构建的 3 个系统中发生的每个错误的根本原因都有历史记录。
【讨论】：