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