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

Posted Learn and think ^_^

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了当你的系统依赖于某个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。

以上是关于当你的系统依赖于某个bug...的主要内容,如果未能解决你的问题,请参考以下文章

小心你的 WiFi 被禁用,iPhone 又出新Bug,附方法

Cargo使用文档-指定依赖项

九 DIP 依赖倒置原则

计划任务

Gem简介

linux系统操作审计-让history内容更丰富