更新时间:2022-10-01 23:16:44
本节书摘来自华章计算机《Effective Debugging:软件和系统调试的66个有效方法》一书中的第1章,第1节,作者[希]迪欧米迪斯·斯宾奈里斯(Diomidis Spinellis),爱飞翔 译,更多章节内容可以访问云栖社区“华章计算机”公众号查看。
要想解决问题,就必须先选定***的策略,这样才可以事半功倍。如果当前的策略无法奏效,那就应该立刻改用成功率第二高的办法。
请想象这样一种场景:George在电话里朝你大吼,说你开发的那个应用程序“运行不了”,于是你赶紧把问题写在便签上,然后把它贴在显示器旁边,显示器周围还有很多类似的纸条。现在你开始回想,自己到底有没有把新版程序所需的最新库文件发给George。实际上,我们不应该这样来处理问题,而是应该改用下面的办法。
首先,要保证有一套事务追踪系统(issue-tracking system)可供使用。很多开源软件库,如GitHub和GitLab等,都提供基本的事务追踪系统,该系统与它们所提供的其他功能是集成在一起的。有些组织使用一种名为JIRA的专有系统,这种系统要复杂得多,它可以在企业内部运行,也可以作为服务来运行。还有一些组织使用开源替代品,如Bugzilla、Launchpad、OTRS、Redmine或者Trac。选择哪个系统并不重要,重要的是必须保证所有的事务都记录在这个系统里面。
如果某个问题没有记录在事务追踪系统中,那我们就拒绝处理该问题。坚持使用这样的系统,能够带来下面几个好处:
对于公司里面那些不必亲自汇报问题的高层员工来说,你可以代他们汇报问题。如果某个问题是你自己发现的,那你也可以自己把这个问题提交到系统里面。有一些公司规定:在修改代码之前,必须先指明这次修改所涉及的事务。
我们还要保证的是:每一项事务都能够精确地描述问题的重现方式。***能在其中给出一个简短(short)、自足(self-contained)且正确(correct,也就是可以正确编译并运行)的例子(example),即SSCCE。我们可以把这个例子直接剪下来,粘贴到应用程序中,以便重现它所要说明的问题(参见第10条)。为了使大家能够写出有效的错误报告(bug report),我们应该制订一份规范,并劝说所有人都认真遵照这份规范来撰写报告。(我看到有一家公司把这些规范贴在厕所门上。)
此外,错误报告还必须具备精确的标题(precise title),并写明bug的优先级(priority)、严重程度(severity)、受影响的利益相关者(stakeholder),以及该bug的发生情境(environment)。在填写这些内容时,要注意以下几点:
使用事务追踪系统时,我们一定要通过它来记录进度。大部分追踪系统都允许用户在每个事务后面持续追加各种形式的评论。这些文档可以把调查及修复bug时所经历的步骤记录下来,其中也可以包括修复bug时所遇到的困境。这样做可以使公司内的工作更加透明。我们应该精确地写出记录或追踪程序行为时所执行的各种命令,这样做很有用,因为明天你可能就要重新执行这些命令,你或你的同事也有可能要在一年之后寻找一个类似的bug。当你辛苦地完成了为期一周的bug搜寻工作之后,这些笔记可以帮助你回顾工作内容,使你能够更好地把这些天所做的事情解释给团队或管理者听。