近日,各大网站,包括新浪、腾讯、网易、搜狐都报道了一则关于微软宣布修复了一个存在了19年的安全漏洞的新闻,以腾讯科技为例,它的标题是《微软修复已存在19年的漏洞》。对于一个软件制造界外的人来说,这是一个大快人心的消息,就跟一个隐藏了19年的纳粹分子终于被抓住的新闻一样轰动。但以程序员为职业的我,听到这样一个消息,却有一种非常不解、甚至是荒谬、搞笑的感觉。从软件生产的角度讲,如果一个bug能存活19年,那它还是个bug吗?
一、很多项目生命期不超过19年
我在很多国企开发过项目,这些项目几乎每过几年都会重新开发一回,老项目或者废弃、或者推倒重来,遇到领导换班子或上级政策方向的改变,更容易发生这种事情。事实上,有大量的软件存活不到19年,都很短命。这一方面是技术的原因,更重要的一方面是国情的因素。如果在这样的一个项目里有一个bug,当这个软件几年后被遗弃时,从来没有被人发现——更符合软件科学的说,没有给用户带来任何烦恼。这样的bug对于用户来说是不可见、不可知、根本不存在的。我们没有必要、也不应该将这样的bug称作bug,更不应该为这样的bug大惊小怪。
二、修改bug有风险
我记得有一个非常有趣的关于bug段子,说的是:
代码中有99个小bug,
99个小bug,
修复了一个,
现在,代码中的有117个小bug。
虽然是个笑话,但作为程序员,我一点都笑不出来,因为这种事情在我们项目的开发过程中经常的会遇到。由于纠正接口中一个bug而导致其它程序调用这个接口时出现了另外的问题。你可能会嘲笑说这是测试程序写的不够周全,但很多时候,复杂的软件内部关联是很难让加班加点的程序员考虑周全的。
所以,在一个复杂的软件里,特别是对于老项目,最早开发这个项目的人已经流失,而项目文档又写的不够清晰,如果一个bug不是特别严重、不影响核心业务,如果能说服客户不修改,那就优先考虑不修改,如果非要修改,那必须要深思熟虑、准备充足的测试用例,并想好回退方案,以防万一。
三、是bug?还是设计的功能特征?
之前就有一篇很好的文章指出,Bash里一个所谓的bug实际上是25年专门设计的功能,只是时过境迁,现在的使用环境发生了很大的变化,人们并没有及时的调整过去的老代码,或者现在的新环境并没有照顾过去的老接口。
所以,我们今天看到的一个愚蠢的 bug,也许在历史上的某一天,是一个有意而为之的神奇特性。我们应该思考的不仅仅是这一刻的 bug 或者安全隐患本身,而是在软件开发这个极具创新的活动中,如何有效的保证某个特意设计的功能不会变成 bug。
总之,一个19年的bug,一直默默无闻,没有被人发现、没有给用户带来麻烦、造成损失。我想,时间证明了这个bug是个善良的bug,是个好bug,我宁愿将它升级成一个功能。即使不能如此,使用用户在这些年的使用中也早就适应了这个bug,能够很好的与它和睦相处,已经不把它当成危险的敌人了。事实上,在用户的心里,它已经升级进化,蜕掉了bug的外壳。这样的bug,还是应该顺其自然,不改为好。程序员朋友们,你说呢?
贵站决大部分帖子都非常好.但本文实在是太扯太装逼.
人家这是负责,你怎么知道这个bug没有害处不影响用户?
讲得不错
明明是安全漏洞还要找这些借口
还国企?哈哈。。没往下看
说的有一定的道理。但是 Bug 就是 Bug … . ….。如果把时间限制在 100 年也许是合适的。100 年也发现不了的 Bug, 就不算是 Bug 吧。10 年没发现的 Bug 叫小 Bug。20 年没有发现的 Bug 叫大 Bug。30 年没发现的 Bug 可以叫 Bug … . …. 如果 Bug 无法避免和被发现并且及时纠正,可以对 Bug 进行分类管理:这样才更科学性。
说的有道理,上一个项目在拼命的改问题单在加班,这对程序员真的很累人,
感觉说的很对
唉,无语
太扯淡了
妖有了人性就不再是妖,是人妖
哗众取宠
不知道你怎么想的
你能把缺陷看成 好坏两种东西。
不知道你是怎么想的
BUG没有好坏之分。
只分 被利用的BUG
和没被利用的BUG
你能保证19年这个BUG没被人用过吗
垃圾文
说垃圾的,肯定编码没没超过三年,而且绝对没有维护过老系统,做的而且都是小系统,什么办公OA啊,什么XX管理系统啊,之类的!
只有真正经历过的人,才会有这样的感受!
只可惜,垃圾太多,真是可惜了这篇好文!
bug就是错误,换个名词你在读一遍
爱过,就不后悔。快乐过,就不悲伤。哭泣过,就知道泪水的味道。心碎过,就知道难受的滋味。分手过,就知道寂寞的空虚。再遇到,才懂得如何珍惜