我应该记录我发现并修补的错误吗？

我认为这是一种常见情况：我测试一些代码，发现错误，对其进行修复，然后将错误修复提交到存储库。假设有很多人从事该项目，我应该首先创建一个错误报告，将其分配给我自己，然后在提交消息中引用它（例如“修复错误#XYZ。该错误是由于X和Y引起的。 Q和R“）？或者，我可以跳过错误报告并提交一条消息，例如“修复了在B时导致A的错误。该错误是由于X和Y引起的。由Q和R修复了该错误”。

什么是更好的做法？

这取决于错误报告的受众。

如果仅由开发人员在内部查看它，以了解需要解决的问题，那么就不必理会。那只是噪音。

无论如何，非详尽的原因清单：

• 发行说明包括有关已修复的错误的信息（达到此错误所能达到的某个阈值）-尤其是如果此错误暴露了一个漏洞
• 管理层希望使用“花费在错误修复上的时间” /“检测到的错误计数”等概念。
• 客户可以查看Bugtracker的当前状态（以查看他们的问题是否已知等）。
• 测试人员获得有关应测试的变更的信息。

我会说，这取决于您的产品是否与错误一起发布。

如果它是与您发现的错误一起发布的，那么可以，创建一个错误报告。发布周期通常可能很长，并且您不希望已修复错误的情况下将其报告为新问题。

如果您的错误尚未发布，那么我不会遵循相同的路径。现在，您将有一些人尝试重新创建您的错误，因为他们尚未发布，因此无法这样做，这实际上是在浪费时间。

如果它是客户可能已报告的错误，则应执行此操作。最坏的情况：您修复了该错误，但没人知道。客户报告该错误。您的同事试图修复该错误，但无论如何都无法重现（因为您已经修复了该错误）。这就是为什么您想要记录该错误的原因。

如果您进行代码审查，这也很有用，通常情况下，将为某些任务编写代码然后进行审查。在这种情况下，最好隔离该错误修复程序，这可能需要在任务列表中放入一些内容，然后再进行所有工作。

这取决于几个因素。

Pieter B和Caleth都在他们的答案中列出了一些：

• 该错误是否已成为正式版本的一部分？
• 是否专门跟踪了错误/花费在错误上的时间？

也可以遵循内部程序，通常以认证要求为后盾。对于某些证书，必须将每次代码更改都可追溯到问题跟踪器中的记录。

此外，有时即使是看起来很琐碎的错误修复也不如它们初次出现时那样琐碎和无辜。如果您将这样的错误修正默默地捆绑到一个不相关的问题的交付中，而该错误修正后来被证明是有问题的，这将使查找更加困难，更不用说隔离或还原了。

这个问题只能由您的项目负责人或负责“票务流程”的人来回答。

但是，让我以另一种方式问：为什么不记录已修补的错误？

我看到的唯一可理解的原因是，提交错误报告，提交该错误报告并关闭该报告的工作要比修复该错误的时间大几个数量级。

在这种情况下，问题不在于该错误是否易于修复，而是文书工作花费的时间太长。确实不应该。对我而言，创建Jira票证的开销是紧迫的c，然后输入简短的1行摘要，然后按下Enter。该描述甚至没有开销，因为我可以将其与发行号一起剪切并粘贴到提交消息中。最后，. c <Enter>问题已解决。归结为5次按键开销。

我不了解您，但这还不足以使其成为小型项目的一项策略，以这种方式记录每个错误修正。

好处是显而易见的-有很多人可以轻松使用Jira这样的票务系统，但不能使用源代码。也有从票务系统生成的报告，但不是源。您肯定希望在其中修复错误，以了解可能的发展，例如不断增加的小型1行错误修正的涌入，这可能使您对流程问题或其他问题有所了解。例如，为什么您必须经常进行此类小错误修复（假设它经常发生）？可能是您的测试不够好吗？错误修正是域更改还是代码错误？等等。

我遵循的规则是，如果您正在处理的部分从未发布过，甚至还没有运行，并且还没有用户见过，请迅速修复您看到的每个小错误并继续进行。该软件发布并投入生产并被某些用户看到后，您看到的每个错误都会得到一个错误报告并得到审查。

我发现我认为是错误的是其他人的功能。通过不检查这些错误就修复错误，我可能正在创建一个错误而不是对其进行修复。在错误报告中放入您将更改的行以修复该错误以及有关应如何修复的计划。

简介：如果从未生产过该模块，请快速修复您看到的每个错误并遵循规范。如果该模块已经投入生产，则在修复之前将每个错误报告为要检查的错误报告。

是的。

已经有一些答案揭示了值得创建错误报告的情况。一些答案。他们不同。

唯一的答案是没人知道。不同的人，在不同的时间，对此事会有不同的看法。

因此，现在，遇到错误时，您有两种解决方案：

• 考虑是否值得打开错误报告，也许要问同事的意见……然后，在某些情况下，后悔您没有因为有人在问这个问题而感到遗憾，并且您是否已经有了报告，就可以只是指出他们
• 只需创建报告

创建报告的速度更快，如果不是，则...将其自动化。

如何使其自动化？假设您的跟踪器支持脚本编写，只需创建一个可以调用的脚本，该脚本将使用提交消息（标题和正文）提交错误报告，并立即以“已实施”的方式关闭该报告，并提交与修订相关的跟踪信息。

我将同意其他所有答案都提供了很好的经验法则，甚至有一些人在这一点上都提到了这一点，但是我认为这里只有真正肯定的答案。

只是问问你的经理。好吧，您的经理或项目主管或Scrum Master等取决于您的团队的结构。

关于好坏实践，有很多不同的系统，但是要知道自己在为团队做正确的事情的唯一方法就是问。

在一分钟的走廊对话中，可以做一些事情：“嘿（老板），如果我修复了一个仅需几分钟的小错误，是否值得为此买票，还是我应该在提交消息中提及它？ ” 您将肯定知道。如果这种方法惹恼了您的团队和经理，那么世界上所有的良好实践都是没有用的。