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