本节书摘来自华章出版社《Effective Debugging：软件和系统调试的66个有效方法》一书中的第1章，第1.1节，作［希］迪欧米迪斯·斯宾奈里斯（Diomidis Spinellis），更多章节内容可以访问云栖社区“华章计算机”公众号查看

第1条：通过事务追踪系统处理所有的问题

请想象这样一种场景：George在电话里朝你大吼，说你开发的那个应用程序“运行不了”，于是你赶紧把问题写在便签上，然后把它贴在显示器旁边，显示器周围还有很多类似的纸条。现在你开始回想，自己到底有没有把新版程序所需的最新库文件发给George。实际上，我们不应该这样来处理问题，而是应该改用下面的办法。
首先，要保证有一套事务追踪系统（issue-tracking system）可供使用。很多开源软件库，如GitHub和GitLab等，都提供基本的事务追踪系统，该系统与它们所提供的其他功能是集成在一起的。有些组织使用一种名为JIRA的专有系统，这种系统要复杂得多，它可以在企业内部运行，也可以作为服务来运行。还有一些组织使用开源替代品，如Bugzilla、Launchpad、OTRS、Redmine或者Trac。选择哪个系统并不重要，重要的是必须保证所有的事务都记录在这个系统里面。
如果某个问题没有记录在事务追踪系统中，那我们就拒绝处理该问题。坚持使用这样的系统，能够带来下面几个好处：
可以看见调试工作所取得的进展。
可以对软件的发行进行追踪与规划。
帮助我们确定各种工作项（work item）之间的优先次序。
帮助我们把常见的事务及其解决方案整理成文档。
防止我们遗漏某些问题。
可以自动生成发行说明（release note）。
可以用作知识库，使我们对软件中的缺陷进行估量及反思，并从中总结经验。
对于公司里面那些不必亲自汇报问题的高层员工来说，你可以代他们汇报问题。如果某个问题是你自己发现的，那你也可以自己把这个问题提交到系统里面。有一些公司规定：在修改代码之前，必须先指明这次修改所涉及的事务。
我们还要保证的是：每一项事务都能够精确地描述问题的重现方式。最好能在其中给出一个简短（short）、自足（self-contained）且正确（correct，也就是可以正确编译并运行）的例子（example），即SSCCE。我们可以把这个例子直接剪下来，粘贴到应用程序中，以便重现它所要说明的问题（参见第10条）。为了使大家能够写出有效的错误报告（bug report），我们应该制订一份规范，并劝说所有人都认真遵照这份规范来撰写报告。（我看到有一家公司把这些规范贴在厕所门上。）
此外，错误报告还必须具备精确的标题（precise title），并写明bug的优先级（priority）、严重程度（severity）、受影响的利益相关者（stakeholder），以及该bug的发生情境（environment）。在填写这些内容时，要注意以下几点：
精准的标题使我们能够在事务汇总报告中迅速找出这个bug。用“程序崩溃”这几个字做标题是很糟糕的，应该改成“正在保存时单击刷新按钮，会使程序崩溃”。
严重程度能够帮助我们判断bug的优先级。与数据丢失有关的问题当然是很严重的，而另外一些无关紧要的问题，或是可以用某种明确的方式来绕过的问题，则显得不那么严重。团队可以根据bug的严重程度来对清单里面的各项事务进行分类，以决定哪些事务需要立刻解决，哪些可以稍后解决，哪些应该忽略。
对事务进行分类并排定其次序之后，就可以把结果填写在优先级这一栏中了，这使得我们能够据此安排各项事务的处理顺序（参见第8条）。在很多项目中，bug的优先级是由开发者或项目主管来设置的，如果允许终端用户来设置，那么他们总是会把自己提交的所有bug都设置成最高优先级。虽说管理人员、客户代表、其他团队的开发者以及销售人员都宣称自己提交的事务应该最先得到处理，但我们还是应该根据实际情况来设置优先级。
在事务中指出受到影响的利益相关者，可以帮助团队获知与该事务有关的其他一些信息，并帮助产品拥有者来决定事务的优先次序。有些公司甚至会在利益相关者后面标注他们给公司带来的年度收入。（例如，“由Acme所提交，该客户给公司带来的年度收入是25万元。”）
对于某些难以捕获的bug来说，情境描述可以提供线索，使得我们能够重现这种bug。不要强迫用户填写过多的信息，例如，PC的序列号、BIOS的日期，以及系统中每一个程序库的版本等，这样做会令用户觉得非常麻烦，从而跳过这些内容。我们只应该询问与bug密切相关的那些细节，对于Web应用程序来说，浏览器的信息自然是相当重要的，而对于移动应用程序来说，我们或许想知道设备的制造商及型号。如果能够通过软件来自动提交这些信息，那就更好了。
使用事务追踪系统时，我们一定要通过它来记录进度。大部分追踪系统都允许用户在每个事务后面持续追加各种形式的评论。这些文档可以把调查及修复bug时所经历的步骤记录下来，其中也可以包括修复bug时所遇到的困境。这样做可以使公司内的工作更加透明。我们应该精确地写出记录或追踪程序行为时所执行的各种命令，这样做很有用，因为明天你可能就要重新执行这些命令，你或你的同事也有可能要在一年之后寻找一个类似的bug。当你辛苦地完成了为期一周的bug搜寻工作之后，这些笔记可以帮助你回顾工作内容，使你能够更好地把这些天所做的事情解释给团队或管理者听。
要点
通过事务追踪系统来处理所有的问题。
确保每项事务都能够以短小、自足而又正确的范例（SSCCE），精确地描述出该问题的重现方式。
对事务进行分类，并根据每项事务的优先级与严重程度来安排工作。
通过事务追踪系统来记录进度。