当你的系统依赖于某个bug...

标题粗略看是有点违反常识的，bug通常是指某些代码存在问题导致系统没有按照期望方式工作，应该是需要尽可能被修复的，这样系统才会正常工作。但是，开发实践中会发现在某些情况下，本来功能没有问题，在你信心满满的修复了某个bug之后，某项功能反倒变成有问题了。这是怎么回事呢？在bug fix本身没有问题的情况，最可能的原因是你的某些上层模块依赖于这个被修复bug的行为，当bug修复之后，这个被依赖的bug行为不存在了，所以导致这些上层模块不工作。下面举一个来自实践中的真实的案例。

有一个函数isdigitstring，它负责检查输入字符串是否是数字字符串。我们在对这个函数做单元测试的时候，发现它存在一个明显的bug。如果输入字符串为空，这个函数会判断这个空字符串为数字字符串，很明显这个判断是不正确的。在单元测试中发现这种bug是非常鼓舞人心的，而且解决这个bug是非常容易的，只需要在函数里面增加一个空字符串的判断处理即可。像预料的那样，我们接下来应该是立即修复这个bug, 然后自豪的宣称代码质量又得到了极大的改善。

意外的是某个资深的软件工程师对此提出一个奇怪而强烈的意见，这个bug现在不能被修复！什么？这是一个毫无疑问的低级错误，修复它看起来完全不存在side effect, 因为它看起来是如此的简单和直接。作为合格的软件工程师来说，我们的职责难道不是尽可能的发现bug和修复bug? 这位提出意见的工程师随即解释了他的理由，原来这个bug在不久前已经被发现，但是同时也发现存在这个bug的函数在代码中被大量使用，代码里所有的现有调用者都已经假定空字符串就是一个数字字符串！所以，如果我们修复了这个bug, 所有调用这个函数的地方都会有问题（因为它们都依赖于这个错误的假定）。这个项目已经临近结束，我们可以修复isdigitstring的bug, 但是我们基本上已经不能负担修改此函数的caller代码的时间成本。也就是说，我们暂时最好的决定居然是不修复这个bug。很明显在新的项目代码里，我们必然会修复这个bug和修复所有的caller代码（不再依赖于错误的假定）。但是对一个低级错误bug的解决方案是"won't fix", 的确会令一个热情的软件工程师内心感觉到挫败。

那么经验教训是什么呢？在项目早期就必须开始单元测试，否则在后期修复一个简单bug的成本可能都会变得非常巨大；低层&公用的代码的修复成本通常会比较高；整体系统工作正常并不一定表示局部模块不存在bug。