遗留物理模型的Bug跟踪

Question

我是一个开发物理模型的团队中唯一的软件工程师(大约3万行代码)。研究小组的其他成员包括科学家，他们已经开发了大约20年的密码库。我的工作流程是这样的：

1. 科学家要求一个新的特征
2. 我执行它
3. 通过测试和验证，我在数字中发现了一个严重的问题。
4. 科学家要求一个新的特性(没有修复#3中指出的问题)。

我们的问题似乎是，错误跟踪是通过电子邮件和张贴它的笔记。繁忙的工作日程让窃听器在几个月甚至几个月的时间里被忽视。我认为一些形式化的bug跟踪器(如Trac、Redmine、Jira、FogBugz等)能帮到我们。以下特点是必不可少的：

• 难以置信的容易使用
• 与版本控制软件集成(我们使用Subversion)

有很多帖子建议哪个窃听器是“最好的”？..。但我想我更感兴趣的是：

• 你在窃听器的开销上有什么经验？
• 你如何说服一个物理学家(他遵循70年代糟糕的软件工程“最佳实践”)，一个bug跟踪器值得额外的费用？
• 我有一种感觉，如果我安装了一个bug跟踪器，我将是唯一的用户。还有其他人经历过吗？它还有用吗？似乎团队需要一定数量的“买进”才能使bug跟踪器值得额外的开销。

Answer 1

我建议看看这个Joel关于软件文章中的策略2。他基本上认为，如果你的公司不使用bug跟踪软件，你应该自己开始使用它，并演示它如何帮助完成任务。还要求其他人使用它来提交bug，这样他们就可以看到使用它是多么容易。

Answer 2

Bug跟踪器绝对值得这么做，部分原因在于它们将实现新特性和修复Bug所需的工作流正式化。您总是有一个工作负载的中心位置(“我的bug”、“我的任务”等等)。在过去的几年里，我工作过的几乎每一个环境都有某种类型的buy跟踪器，所以我不知道在购买方面应该推荐什么。您有不止一个科学家来找您进行特性请求/bug修复吗？如果是这样的话，那么也许您可以使用bug跟踪器作为冲突解决系统。你有老板/经理吗？那么，拥有一个bug跟踪系统将为你的老板提供很多洞察力。

一般来说，作为一名软件开发人员，bug跟踪器非常有用。我的建议是想出一种方法，一个窃听器可以提高你和你的同事的生活。或者做个简单的演示。

HTH。

Answer 3

根据我的经验，错误跟踪器的开销是显而易见的，但绝对值得！问题是，如果您决定使用bug跟踪器，它只能在每个人都使用它的情况下才能成功。作为这样一个系统的唯一用户并不是那么有用。

话虽如此，即使我是唯一的用户(这往往会发生很多)，我仍然安装lot跟踪器(通常是trac)。如果您虔诚地使用它(以错误的形式输入通过不同方式传入的每一件东西，并且总是在您的回复中引用bug# )，团队通常会随着时间的推移来收集它。

输入里程碑(或任何您选择的跟踪器称之为里程碑)，并将bug链接到它们。每当有人问起某件事的进展情况时，打电话给里程碑报告或类似的报告，并向他们展示。这有助于人们将bug跟踪器视为一种讨厌的东西，从而认识到它可以成为宝贵信息的来源。