这是关于软件缺陷跟踪器的一些观点和建议。

• 引言：作者从事软件工作，对不同的缺陷跟踪器有意见，认为问题在于数据表示而非用户界面，在本文中将提出抱怨并描述理想的“关注点分离”原则。

  • 个人经验与免责声明：所有抱怨基于作者使用过的缺陷跟踪器，不代表所有缺陷跟踪器的情况，也希望听到已有符合要求的免费软件缺陷跟踪器。

• 一些抱怨：

  • 统一的“修复版本”字段：在 Jira 中，“修复版本”字段结合了过去的事实、现在的事实和未来的意图，导致查询特定属性困难，理想情况是有“目标版本”和“已修复版本”字段。
  • 双层状态和解决方案字段：许多缺陷跟踪器将状态分为“打开”和“关闭”，关闭时用“解决”字段表示关闭方式，难以区分代码中的事实和未来的意图，“Won't Fix”状态也很尴尬。
  • 用于其他待办事项的假 bug：通常将 bug 列表作为待办事项列表的一部分，但这会导致一些问题，如将功能工作建模为“反 bug”不合适，跟踪进度困难，以及与系统外工作的不匹配等。

• 关注点分离：

  • 事实与计划分离：建议缺陷跟踪器明确分离事实和计划，事实表记录关于 bug 的实际信息，计划表记录计划和意图，两者可相互引用，需同时更新以保持一致性。
  • 事实与源控制链接，计划与时间段链接：事实侧关注源代码的状态，不局限于“发布”粒度，可记录引入和修复 bug 的提交；计划侧主要关注时间周期，如发布周期。
  • 功能请求只是计划，直到实现：将功能请求视为计划而非事实，新添加功能的事实记录应表示功能的存在，而不是其缺失。
  • 各司其职：计划者更新计划，开发者更新事实：若组织有明确的计划和开发角色，计划者在计划表工作，开发者在事实表工作，可避免冲突。
  • 计划表可清理，事实性 bug 记录保持开放：计划者可关闭无关的计划记录，而不影响事实性 bug 记录，可独立衡量计划健康和代码质量。
  • 时间计为计划，而非 bug：时间核算应与计划相关，若 bug 与计划混淆，在边缘情况下会导致尴尬，分离后时间计为计划。
  • 可以没有计划：一些软件项目不需要计划，对于这类项目，没有计划表的缺陷跟踪器更合适，只需记录事实。
• 为什么不自己写这个缺陷跟踪器？：作者虽有想法写一个更好的缺陷跟踪器，但目前不会行动，因为设计尚未完善，还有很多未描述的细节需要考虑，且可能因超出自己的技能范围而导致系统不实用。