配置管理-代码注释中的历史记录
在提出我的问题之前，让我先介绍一下背景信息：
我最近加入了一个新的软件开发小组，该小组使用Rational工具进行配置管理，包括源代码控制和变更管理系统。除了这些工具之外，该团队还有一个标准实践，即在代码中记录任何代码更改作为注释，例如：
///<history>
[mt] 3/15/2009 Made abc changes to fix xyz
///</history>注释标准的官方目的是“注释提供了从需求到代码修改的可追溯性”。
我准备提出一个论点，认为这种做法是不必要的和多余的；团队应该立即摆脱这个标准。
也就是说，变更管理系统是构建从需求到代码修改的可追溯性的地方，源代码控制可以通过在不同版本之间执行差异来提供详细的变更历史。签入源代码时，会注意到对应的变更管理工单。在解析CM票证时，我们会记录哪些源代码文件被修改。我相信这为期望的可追溯性提供了足够的交叉引用。
我想知道是否有人不同意我的观点。我是不是错过了更改管理和源代码控制系统无法提供的注释源代码历史记录的一些好处？
回答 6
Stack Overflow用户
发布于 2009-03-16 01:59:25
对于我自己来说，我总是发现这样的注释比它们的价值更麻烦:它们可能会导致合并冲突，当你试图隔离两个版本之间的差异时，它们可能会显示为“假阳性”，并且可能会引用后来被更改所过时的代码更改。
经常(并非总是，但经常)可以在不丢失元数据的情况下更改版本控制系统。如果您要将代码移动到不支持的系统，那么在转换之前编写一个脚本将更改历史记录转换为注释并不难。
Stack Overflow用户
发布于 2009-03-16 01:44:11
注释允许您在相关的代码中找到所有更改及其原因，而不必深入研究差异和版本控制系统的复杂性。此外，如果您决定更改版本控制系统，评论将保留。
我在一个大型项目中工作，有类似的做法，但两次更改了源代码控制系统。没有一天我不高兴听到这些评论。
它是多余的吗？是。这是不必要的吗？不是的。
Stack Overflow用户
发布于 2009-03-16 08:08:37
我一直认为代码当然应该在版本控制之下，并且当前源代码(你今天可以打开和阅读的那个)应该只在现在时态中有效。
如果一个报表在过去可以有3个轴，并且上个月你更新了它以支持最多6个轴，这并不重要。如果你扩展了一些功能或者修复了一些bug，这并不重要，只要当前版本易于理解即可。修复bug时，只需保留已修复的代码即可。
不过，有一个例外。如果(且仅当)修复后的代码看起来不像以前不正确的代码那么直观；如果您觉得明天可能会有人来，并且仅仅通过阅读代码，就想把它改回“看起来更正确”的，那么最好添加一条注释：“这样做是为了避免……诸如此类的事情。”此外，如果背后的问题是团队文化中臭名昭著的战争故事，或者如果由于某种原因，错误报告数据库包含关于这部分代码的非常有趣的信息，我不会发现在解释注释中添加“(请参阅bug Id 10005)”是不正确的。
https://stackoverflow.com/questions/648972
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号