作者 | Raymond
出品 | CSDN（ID：CSDNnews）
在 Windows 团队中，缺陷跟踪的历史可以追溯到 Windows 1.0，当时他们把缺陷记录到一个文本文件中。
在 Windows 1.01 发布后，应用部门的一群人聚在一起，组建了一个 bug 跟踪数据库。
这个名字是在团队中通过投票选出的，被选中的名字是 RAID，这是一个杀虫剂品牌，其在美国的广告中使用的标语是 “干掉 bug” ，于是自然而然地就把一罐杀虫剂的图案当做这个程序的图标。
RAID 是“Reporting and Incidents Database（报告和事故数据库）”的首字母缩写，但没有人知道或关心这一点。
在构建了 bug 查询之后，可以将其保存以备将来使用，文件扩展名为 `. rdq ` 是“ RAID Query（查询）”的缩写。
RAID 这个名称在语言学上很有用，因为你可以“ RAID 一个 bug” ，意思是“在项目的 RAID 数据库中存储一个 bug”。`.rdq` 也可以当名词来用，意思是查询文件。“你能把明天要复盘的 bug 相关的 .rdq 发给我吗？”
这个数据库是在 16 位计算的时代编写的，所以最多支持 32,767 个 bug。多年来这已经足够了，但是最终产品遇到了记录限制，不得不“切换” 到新的数据库，所有来自旧数据库的尚未关闭的 bug 都被复制到新数据库 (并接收新的记录编号) ，旧数据库被置于只读模式。
当你阅读一些代码的时候，当你看到类似 “ 修复了 3141 号 bug” 的注释时就会很困惑，因为它没有指出 bug 号属于哪个 bug 数据库。
Windows 95 在其生命周期中就经历了三个 RAID 数据库。
RAID 的最初作者并不知道他们的小 bug 跟踪数据库工具会成为微软几十年来主要的缺陷跟踪工具。如果他们知道，他们可能会因为害怕而不敢写。当回顾 RAID 的起源时，一位最初的开发人员承认，“它真的不能服务那么长时间。对不起! ”
另一个可扩展性问题是，当 Windows XP 项目进展顺利的时候，会遇到这样的情况: 有太多的人同时使用 RAID，以至于服务器不再接受新的连接。当在"船坞"（会议室） 开会讨论 Windows 项目的状态时，他们有时不得不呼叫操作系统开发小组，要求他们切断一些与后端 RAID 数据库的活动连接，以便"船坞"的人能够连接到 RAID。
很明显，RAID 的能力远远超出最初设计的范围。于是出现了新的缺陷跟踪系统，该系统被被命名为 Product Studio，因为当时将应用命名为某某 Studio 是很流行的。
没有 32767 条记录的限制。它使用了三层架构来提高可靠性和灵活性，并且支持文件附件！
Product Studio 多年来一直是主要的 bug 跟踪数据库。但是即使改进过架构，还是经常会遇到这样的情况: 应用程序停止响应，只是简单地告诉你“连接中间层时出错了”。
我喜欢开玩笑说，我们应该干掉中间层， 因为它总是那个引起麻烦的人。
Product Studio 一直延续到 Windows 8，这时 Windows 切换到本地的 Team Foundation Services 进行工作项跟踪。
最近一次是在 Windows 10 中，当时 Windows 团队切换到 Visual Studio Online，用于工作项跟踪数据库。请注意，这并不意味着一切都很稳定，因为光服务的名称就从 Visual Studio Online 改成了 Visual Studio Team Services，然后又改成了 Azure DevOps Services。
Azure DevOps 也还不够强大，无法容纳所有的 Windows 工作项。旧的工作项要定期归档并移到另一个项目中[^1]。但至少其余的工作项没有重新编号。谢天谢地，他们保留了原来的编号。
[^1]: 不幸的是，归档项目重新编译了工作项。幸运的是，在标题中记住了最初的工作项，因此您可以搜索 originalid: 3141 来查找编号为 3141 的旧工作项。
原文链接：
https://devblogs.microsoft.com/oldnewthing/20200317-00/?p=103566
本文为CSDN翻译文章，转载请注明出处。
閱讀更多 CSDN 的文章
