本节书摘来自华章出版社《Effective Debugging:软件和系统调试的66个有效方法》一书中的第1章,第1.8节,作[希]迪欧米迪斯·斯宾奈里斯(Diomidis Spinellis),更多章节内容可以访问云栖社区“华章计算机”公众号查看
第8条:把工作焦点放在最为重要的问题上
许多大型软件系统都含有数量极其众多的bug(有一些是已知的bug,还有一些则尚未发现)。要想高效地进行调试,就必须把应该受到关注的bug与可以忽略的bug明智地区分开。这样做不是为了单纯地缩减事务清单中的未决事务,而是为了帮助我们开发出稳定、易用、可维护而且效率较高的软件,毕竟这才是公司给我们支付薪水的原因。为此,我们要通过事务追踪系统来设定各项事务的优先级(参见第1条),从而使自己能够把工作重心汇聚在优先级较高的那些事务上,并把优先级较低的事务忽略掉。下面给出一些与排定事务优先级有关的建议。
下列几类问题应该赋予较高的优先级。
数据丢失:数据之所以会丢失,可能是因为本身受到了损坏,也可能因为程序在可用性方面遇到了问题。用户把他们的数据托付给你的软件,你就应该维系这份信任感。如果数据丢失,那你就违背了他们的信任,要想再重新获得其信任,是很困难的。
数据安全:这种问题可能会影响软件数据的保密性与完整性,也可能会影响软件所在系统的完整性,或软件所提供服务的可用性。此类问题通常是由于恶意人士对软件进行攻击而引发的,它会给公司带来巨大的资金和名誉损失,此外,还会引来监管机构的注意,或招致勒索。因此,安全问题必须尽快解决。
服务的可用性降低:如果软件是用来提供某种服务的,那么当这项服务无法使用时,公司就会遭受资金损失(有时甚至是以百万元为单位的损失),此外,还会令公司失去信誉、迫使经理在半夜愤怒地打电话给你,而且也会使服务人员忙得不可开交。这些都是应该尽量避免的事情。
使用安全:此类问题可能导致用户伤亡,使财产丢失或受损,或令环境遭到破坏。前面那几类问题所造成的后果,同样有可能出现在这一类问题上面。如果软件可能会在这一方面发生故障,那就应该用一种比这份清单更加严谨的流程来指导你的行动。
程序崩溃或冻结:这可能导致数据丢失或服务下线,而且此类问题可能与底层的安全问题有关。在程序崩溃或失去响应之后,我们通常可以通过事后分析技术(参见第35条)来对其进行调试。这种问题自然不应该赋予较低的优先级。
代码质量(code hygiene):我们要把编译器所给出的警告信息和断言失败信息,以及未处理的异常与内存泄漏等问题清理干净。总之,由于各种低质量的代码会滋生并掩藏一些严重的bug,因此,我们不能允许这类问题继续存在并积累下去(参见第20条)。
下面几类问题的优先级可以设置得低一些。这并不是说它们本身不重要或不值得关注,而是说为了解决更为紧迫的问题,我们可以把这些问题先放在一边。
对遗留事物的支持:能够支持过时的硬件、API或文件格式,这固然是好的,然而从商业角度来看,这样做不会有太大意义,因为使用这些东西的人已经越来越少了。
向后兼容:这一类问题的优先级没有较为明确的结论。如果你在软件的发展过程中,总是把原来的用户抛开不管,那就会失去顾客对你的信赖。有些公司,如Nikon,通过对向后兼容性的维护而获得了良好的口碑,他们的新产品能够与很多代之前的旧产品相兼容,例如,当前的高端Nikon相机,依然那可以使用20世纪70年代的Nikkor(尼克尔)镜头。与之相对,某些成功的软件公司以其决绝的做法而知名,他们毫不犹豫地放弃对旧软件与旧服务的支持。有时我们确实应该停止对旧特性的支持,以便把精力更好地放在未来的发展上面。
美观问题:这些问题很难处理得十分恰当,而且经常容易遭人忽视。例如,就算弹出式帮助信息没有完整地显示出来,客户也不太可能因为这个而抛弃你的产品,可是当你要修复这个小问题的时候,却会发现它处理起来相当麻烦,因为你得根据屏幕的分辨率设置来动态地调整帮助面板的尺寸。
已经有了临时解决方案的问题:有些bug调试起来比较复杂,为了避免在这些问题上面消耗时间,我们可以先给用户提供一种临时的解决方案,以便暂时绕过这些问题。例如,笔者在打开自己家的电视之后,想试着用电视的遥控器去操作媒体播放机,然而却看到了一条提示信息:“请再试一次”。我怀疑这个小问题修复起来相当麻烦,于是厂商就先给出了这个权宜的办法。
很少有人会用到的特性:当软件中的某一个较为奇怪,而且很少有人用到的特性出了问题时,我们与其花时间去解决这个问题,还不如直接把该特性删掉(并把由此引发的一些小状况处理好)。通过收集软件的使用数据,我们可以更为容易地确定出这些罕用的特性,并据此做出决策。
请注意,如果你决定忽略某个优先级比较低的问题,那就应该把这个态度明确地表达出来。你可以在事务追踪系统里面表明自己“不打算解决”该问题,并将其关闭。这样做可以把自己的决策记录下来,使得其他人以后不会再提出类似的问题,从而减轻管理方面的工作量。
要点
并不是所有的问题都值得解决。
修复优先级较低的问题可能会耽误你的时间,使你无法拿出更多时间去处理那些更为紧迫的事务。