软件调试修炼之道之——特殊案例

特殊案例之一就是修补已经发布的软件，诊断这种缺陷与其他缺陷并没有什么不同，但修复的目标通常是要修复错误的根源，而对已经发布的软件要进行修补时，他只是在最大程度降低风险。

如果缺陷出现在用户已经使用的软件中，那么需要考虑向后兼容的问题。首先需要确定正在进行的修复是否可能引起兼容问题，此时，我们能做的就是对整体了解的基础上思考，将确定兼容性问题加入到缺陷修复的检查列表中，一旦确定有兼容性问题，该如何解决呢？

1. 提供迁移的方法：给用户提供一些方法来修改其现有数据，代码等东西，以适应新的规则。

2. 实现一个兼容模式：比如office word 2010打开word 2003版本显示如下：

这不是一个能被轻易采用的方法，因为它的成本非常高。从用户的角度来看，兼容模式让人困惑，他们必须知道软件支持两种不同的行为，它们的不同之处是什么，什么时候用哪种模式，只有付出的成本合理时才会用这种模式。

3. 提供预警：只有当你能长时间延长修复以使你的用户能够迁移，并且知道用户是否真的迁移的情况下才有效。

4. 不修复缺陷：当然，这不是一个好的解决方案，只是，极少数情况下，它是一个务实的选择。

并发软件是难以重现、难以诊断以及难以修复的主要问题来源。这些软件的缺陷具有很大的不确定性，它们之间存在微妙并且难以理解的相互作用，并且受很多不明原因的失效模式影响。

可以在并发软件中添加很多东西帮你调试，两个关键的要素就是简单和控制。

简单是任何软件设计的关键要素之一，但是它在处理并发问题时尤其重要。保持独立线程的直接相互作用，尽可能将它们限制在一些小的代码区内等。

一个简单的设计不仅可以使你的软件更容易理解，并且从一开始就会减少缺陷的产生，而且更容易控制。

当你要修复并发软件中产生的缺陷的时候，要记住一个关键的要素——让它们尽可能少发生不是可取的修复办法。

修复并发缺陷时，要避免使用sleep()方法，虽然它在强迫缺陷可靠重现的时候是一种极其有用的手段。

海森堡缺陷，一个当你开始寻找的时候就会“消失”的缺陷，也被称为观察者效应。

海森堡缺陷依赖于软件的某些不确定因素，这本身可以成为一个有用的线索。之前我们说过，导致不确定性因素的原因是非常有限的，所以意味着这个缺陷一定会被这些原因中的一个所影响。你应该进行的最快最容易的尝试是从一个收集信息的方法转换到另一个方法，如果不行，则要找到某种方法来收集你所需要的信息，这种方法对软件的影响极小，保证不会改变它的行为，而日志记录是改变时序的一个主要原因。你可以利用对不确定性区域的理解，来避免影响这些区域。

如何确定海森堡缺陷被修复了呢？唯一的办法就是要比平时更仔细，确保你真正的了解潜藏的根本原因。

性能缺陷：如同任何种类的缺陷，解决性能问题的关键是确定问题产生的根本原因。十之八九，这意味着你将去寻找瓶颈——代码的某个特定区限制了整体性能，按照从运行的软件中收集的数据运行，这是唯一确定的解决方法。因此，主要关注点是保证生成的性能分析文档能够准确反映软件的真实行为。

准确的性能分析：你要分析的构建应该尽可能接近产品版本，运行的环境要尽可能与软件的最终目标运行环境相同，使用具有代表性的数据运行软件。

如果没有瓶颈呢？如果没有性能瓶颈，但是软件运行很慢，那么主要的原因可能有：资源耗尽（是否存在内存或资源泄露）、垃圾收集（软件是否分配很多短生命周期的对象让GC频繁运行）、缓存（遇到大量缓存丢失？）。

嵌入式软件：调试嵌入式软件的棘手并不在于它的错综复杂，而是因为它的运行环境，此时，你需要一些调试工具帮助你。

第三方软件缺陷：第三方的代码只是代码，而且，如同任何代码，它也包含缺陷，所以，很可能你要追踪的问题不是你自己造成的。但是，不要轻易埋怨别人。带着怀疑的眼光对待自己的代码，首先假设你的代码是有缺陷的。当你用尽了方法证明自己的代码正确，再去埋怨三方的代码。如何处理三方代码中的缺陷呢？提交报告等待三方负责人修复缺陷，当然，你可以尝试找到问题的解决方法，并在缺陷报告上详细说明，可能的话，与三方负责人进行沟通，而最好的解决办法通常是在短期内搁置问题。

一种非常重要的第三方代码是开源代码：只要给予足够的关注，所有的缺陷都是浅显的，但是开源并不意味着传统调试的结束。开源的本质意味着你不能以中心化的方式构建软件。开源社区可以提供很大的帮助，在这里，可以得到完全免费的高质量软件，而高质量的技术支持也是免费的，但是，有效的寻求帮助是一门艺术：

首先，做你应该做的，检查文档，经常提出问题，搜索邮件列表和博客条目，看看是否其他人也遇到过同样的问题。

尽可能多的给出信息。

记住：帮助你的人是自愿的。

如果你修复了缺陷，之后可将修复程序提交回中央进行处理。