我应该记录一些小错误吗？

我在两个人的代码库中。而且，尽管我知道在程序数量大于或等于1的情况下，错误跟踪器很有用，但我并不太相信记录错误，更改和修补程序是微不足道的时间。当我发现一个简单的错误时，便会理解，修复并通过一些测试运行它。然后我意识到我需要对其进行记录。

从理论上讲，我知道应该在发现错误和修复错误之间的某个地方进行错误日志记录，但是如果修复它的速度比记录日志更快，那么这似乎很麻烦。在大型代码商店中，老板会注意谁在做什么，很高兴知道其他人在做什么。

我发现自己描述了已经解决的问题，然后立即将其关闭。我怀疑有人还会再看这个封闭的bug。是时候减少加工脂肪了吗？

您应该记录对系统所做的所有更改。在事件发生后对其进行记录没有任何问题-只要您将错误报告链接到变更号即可。

然后，如果发生任何错误，您可以追溯到该错误并找出做出更改的原因。

在大多数情况下，您是对的，没有人会再看这些。但是，在百分之一的情况下，如果出现问题，则此信息将非常宝贵-尤其是当问题仅在6个月后浮出水面时。

更新

显然，如果您仍在开发新功能并发现您认为已完成的功能的一部分中的错误，则无需将其记录为单独的更改。在这些情况下，我会将其记录在要求主要功能的项目上。

一旦与功能系统已传递到QA或客户，则有必要做我上面列出。

如果您使用源代码控制工具，则可以在提交描述中描述您修复的错误，通常这对于解决超小型，琐碎的错误是足够的文档。

此外，如果您使用与源代码控制和存储库完全集成的错误/功能跟踪器（如FogBugz和Kiln），则可以使用全局搜索工具查找这些错误修复程序，并查看您所做的代码更改容易。

另外，您可以为您的编程合作伙伴分配一个代码审阅，以便他可以审阅您所做的琐碎修正，但是我很忙。

从度量角度来看，它可能仍然很有用。

此信息可用于向老板显示一些信息：

• 我们需要更多的开发人员
• 该过程中的其他内容已被破坏（为什么有那么多错误？另一个家伙会生成大多数错误），也许表明您有太多错误。也许是某种原因造成的？你释放得太早了吗？完成足够的测试了吗？
• 奖励时间，这是您一直在努力的好清单。

话虽如此，这取决于您所谈论的错误。例如，您在添加新代码时偶然发现的一个衬套可能毫无意义。

无论大小如何，我都会尝试记录所有所做的更改。您永远都不知道什么时候您或其他人（未来或现在）需要回去看看这种变化是否是其他原因的可能原因。

跟踪很重要，但也要考虑另一种情况：何时需要进行审查。它可以亲自进行，也可以非正式地在没有您的情况下通过您的老板从错误跟踪器中提取报告来进行。

考虑他们最终会增加您的数字的“技巧”。毕竟，它们是您已修复的错误，即使它们是微不足道的修复，您也应该因其而闻名。

记录他们。

要回答这个问题实际上取决于您在过程中所处的位置。

这些可以应用于新项目或正在设计的新功能集。

初始设计 如果您发现我们在初始设计期间创建的代码中的错误，则无需为其创建错误跟踪。我建议对更改进行单独的提交，以便以后发现问题时可以轻松撤消它。

测试中

通常，在单元测试期间，代码仍然被认为是不重要的，因此，除非由不同的小组来完成，否则我会拒绝。如果单元测试是由错误跟踪程序以外的其他小组完成的，则是使测试过程正式化的好方法。

CSCI测试取决于。它是由另一个小组完成的吗？如果是这样，则是（请参见上文）。这是发布之前测试的最后一步吗？然后，是的，因为此时您的软件应被视为成熟。如果您对指标感兴趣，那么此时最好开始跟踪错误。

对于更高级别的测试，则应使用错误跟踪。在这些时候，您的软件应该被认为是成熟的，并且跟踪错误很重要。

发布

您应该始终跟踪发布的代码中的错误。这对于问责制很重要。

简化流程以适合您的需求也很重要。您是否真的需要一个庞大的错误跟踪系统？所有的领域对于两个人组成的团队真的重要吗？

是否有其他人可能会遇到该错误，也许是在已发布到外界的较旧版本的软件中？如果是这样，则记录错误和修复可能会很有用。

其他人则建议，如果记录此错误所需的时间比修复该错误所需的时间长，则不值得记录。我建议相关的时间跨度不是在发现错误和修复它之间，而是在引入该错误与发布该修复程序之间。

如果更改和发行历史记录表明该漏洞从未出现过，那么将其检入源代码管理时将其记录下来就足够了。

这与这个问题非常接近，但是我不确定它是否是重复的，因为这个问题侧重于琐碎的修复。

为什么您不应该跟踪错误，作者：乔恩·阿里德·托雷斯达尔（Jon Arid Torresdal） -改正它们。

1. 在开发过程中：您遇到功能缺陷。您添加了一个破坏构建的测试用例，然后针对该功能签入修复程序。

2. 发布后：记录行为。如果您打算发布更新，请转到1。如果您不负责该发布，则将test + fix保存在私有分支中。

在发布代码之后，可能还有其他优先级，并且虽然修复该错误可能是微不足道的，但是除非您进行连续部署，否则单独分发此修复程序可能并不经济。

取决于如何微不足道，我用这个措施：

如果记录它所需的时间比修复它所花费的时间长，那么就不值得记录它。