当你的系统依赖于某个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。
最新文章
- 5. web前端开发分享-css,js深化篇
- openmp 的使用
- UE4 在C++ 动态生成几何、BSP体、Brush ---- Mesh_Generation
- 编码中常用的SQL语法
- 异步FIFO为什么用格雷码
- HDOJ2007平方和与立方和
- Android 连接 SQL Server （jtds方式）——下
- 导出可执行的jar
- java学习——集合框架(Collection,List,Set)
- js对表单设置了readonly和disabled后的区别
- js获取菲波那契数列的第N个元素
- Django with uWSGI and nginx
- git 远程仓库管理
- CCF CSP 201312-1 出现次数最多的数
- 学习笔记TF037:实现强化学习策略网络
- 如何在framegroup各个frame和window之间共享数据
- 基于Azure的软件部署和开发系列沙龙
- Oracle12c 在 Ubuntu 12.04 ~ 18.04 的安装注意事项
- Elasticsearch 学习之 Marvel概念
- 孤岛营救问题(BFS+状压DP)