为什么在补丁说明中引用错误ID会被视为不良做法？

根据评论以及随后的Bug重新打开vs. new的意见：

在补丁说明中引用错误ID只是..非常不友好。–克雷普

似乎至少有人觉得在补丁说明中引用错误ID不是一个好主意。我是一个经验不足的开发人员，所以我想知道为什么会这样。

我认为，这是一个好习惯，假设您的用户对您的错误数据库具有读取权限。很多时候，人们在等待修复某个错误以决定何时升级。

我认为皱眉只是引用错误ID而已。您还应该始终提供易于理解的描述，而无需访问Bug跟踪器。这也使您将来可以切换错误跟踪器，而不会完全使以前的发行说明无效。

如引用的评论中所述，...不友好。

对自己不友善

想象以下情况。您正在查看源代码管理中的日志。您想知道提交更改了什么。它没有用简单的英语解释，而是告诉您：

已解决＃1307

您运行错误跟踪系统，希望对您有所帮助。错误1307报告为已解决。在描述中，您将看到：

与＃1284相同的错误

谢谢，它非常有帮助。现在，您必须导航到错误报告＃1284，以读取它是错误＃1113的重复，该错误涉及错误＃1112，＃1065和＃1067。

五分钟后，您一开始不知道要搜索什么。

一个更有用的版本控制日志消息将是：

通过删除对数据访问层应用与网站本身相同的密码长度策略，解决了用户无法使用长度超过25个字符的密码登录的问题（请参阅＃1307）。

以同样的方式，在错误跟踪系统中，报告＃1307可能更不言自明，回想一下错误报告＃1284的含义，以及新报告与旧报告有何不同。

对客户不友好

这不是唯一的友好问题。

第二个问题是，通过过多引用而没有其他信息，您会使补丁说明/版本控制日志/错误跟踪系统报告对不太熟悉这些系统的人无法使用。每天使用Bug跟踪系统时，您就会知道如何快速浏览报告，并排查看多个报告等。如果您是没有技术背景的客户，则很容易迷失方向。

同样，在这里，更详细的消息不仅仅是参考。请注意，您仍然想保留引用：没有什么比与两周前遇到的错误相同的错误更错了，但是不要记得它的ID。

需要注意的是，在许多司法管辖区都存在相同的问题。以法国为例，立法提及多个来源并不罕见，但同时可能会发生变化。这意味着，为了完全理解它，您有时必须在图书馆中花费数小时，搜索数十个引用的文本，每个文本都有自己对其他文本的引用。

如果用户可以阅读所引用的问题，则在补丁说明中引用问题编号没有任何问题。如果您的错误数据库允许任何人阅读，则引用错误编号确实非常有用。（一个更好的方法是，如果补丁说明的格式允许链接，则使那些问题ID成为所讨论问题的链接。）这并不意味着您应该将所有问题公开给公众；笼罩着那些仍然很有用（例如，在其中输入实时密码的地方！）

引用一个问题编号，使人们无法阅读并查找错误的详细信息和历史记录，这非常不友好。指出没有问题ID的此类问题并不是更友好。

显然，这取决于将阅读补丁说明的人员以及软件的目标用户。

但是在大多数情况下，绝大多数用户根本不关心错误ID是什么。他们不在乎它为什么被破坏，修复了什么或其他任何东西-他们只想知道非常简短的文本描述中发生了什么更改，而不必每次更改都转到另一个页面。

引用错误ID会让我停下来思考，而我-作为用户-不想思考。这是一个可用性问题。

以Visual Assist X的更改日志为例。所有这些链接的错误ID只是噪音，使我无法了解更改的内容。这是针对Visual Studio的针对程序员的附加组件。我是一名程序员。如果这让我感到困扰，请想象甚至不知道错误跟踪器是什么的普通用户。

PS：我是引发这个问题的评论的作者

错误ID 对于参考点是必需的。原因：

• 防止歧义：两个或多个错误可能具有相似的描述。因此，需要一些锚点来区分它们。
• 便利性：与客户或在内部讨论错误时，错误ID通常被用作简短形式。如果补丁说明中省略了ID，则将很难讨论它们：

3052已修复，仍在3077上工作

比：

修复了“应用按钮上的应用程序崩溃”的问题，该问题仍然适用于“单击更改用户时出现NullReferenceException”

我会说这取决于您的系统：幸运的是，我使用的 那个会自动在提交消息中检测到此类引用，并向存储在bug跟踪器中的票证添加链接，因此这不是问题。

但是，如果我使用的系统不可用，我仍然会提及票证ID（这样，您就可以按票证ID快速搜索日志），并简要说明该错误是什么。