将bugfix修复注释保留在代码中好吗？

Question

我的团队正在使用透明案例作为版本控制。我正在工作的这个项目不是在7-8年前开始的.在整个项目的整个生命周期中，我们有几个版本，bug修复，service等等。这些问题是使用bug跟踪系统来跟踪的，并且大多数处理bug的人都遵循一个例行公事，在开始/结束块中将注释与日期、作者、bug-id等放在一起。

我觉得这是非常不相关的，使代码变得杂乱无章，难以维护，这些都是签入注释/标签等的一部分，我们可以保存工作产品的其他生命周期信息。

要遵循的最佳做法是什么？

代码的一些审阅者坚持说出了关于这个错误的评论，并进行了修正，以缓解他们的生活。据我理解，他们必须通过将文件映射到视图来检查文件，并获取分支的更改日志并对其进行检查。如果我能得到一些关于提交更新代码以供评审的最佳实践，这将是有帮助的。

Answer 1

将full作为注释添加到代码中的问题是，您没有得到完整的说明。如果我看到一段非常好的代码，上面写着“这是对bug的修正”，我的第一反应就是说“那又怎样？”密码在那里，它起作用了。维护代码唯一需要知道的是一条注释，它告诉我它是做什么的。

更好的做法是在SCM提交日志中添加be修复引用。这样，您就可以看到bug是什么，它是在哪里引入的，以及它是如何修复的。此外，当发布的时间到来时，您可以简单地提取SCM日志，并添加一个要点，说明有一个bug，并且它是固定的。如果另一个分支或版本引入了相同的bug，那么很容易找到修复程序，如果它确实是相同的，则可以重新应用。

说了这些之后，我也同意查尔斯的回答。如果编写一段代码的原因并不明显，那么一定要告诉维护人员，代码存在是有原因的，应该谨慎对待。

Answer 2

大部分都是糟糕的练习。我不会说永远不应该做的。偶尔，您会遇到一些类似于外部API中的bug的情况，您必须解决这些问题。如果你不知道潜在的缺陷，这种解决方案可能会让你的大脑完全瘫痪。在这种情况下，将错误记录在代码中可能是个好主意，这样同事或以后的自己就不会试图“修复”明显脑死亡的代码。

Answer 3

练习不好。注释会过时，代码会变得杂乱不堪。如果需要，该信息仍可在SCC系统的版本历史记录中获得。