文章来源：外刊IT评论
近日，各大网站，包括新浪、腾讯、网易、搜狐都报道了一则关于微软宣布修复了一个存在了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，还是应该顺其自然，不改为好。程序员朋友们，你说呢？
引用来自“strwei”的评论
不开源就是这样，微软那几个员工比不过全世界的程序猿一个Bug隐藏十几年，也算不上很稀奇吧？毕竟是一个闭源软件。
至于是否别有用心，只有MS知道。质疑微软很正常，但搞不懂那些一口咬定微软的，哪来的底气
引用来自“eechen”的评论
能存活 19 年的 bug 当然不是 bug，而是微软为NSA流行的 backdoor。引用来自“kchr”的评论
如果别人反击说 bash 的 Shellshock 问题已经有 22 年了，kernel 也有存在了 14 年的 bug，你怎么回答?你黑之前要想好对策啊。
另外Bash和OpenSSL的漏洞也主要是针对服务器，而微软的这个bug的受众是Windows用户（包括企业使用的Windows服务器），这个广泛性程序不可同日而语。当然开源软件也要防范NSA攻击，比如NSA开发的SELinux这个安装模块就要仔细进行代码审核。NSA甚至买通RSA在加密算法里植入后门，要完全防范NSA窃取信息，任重道远。
一个可以让黑客远程操控电脑的bug时间久了就不算bug了？只能说明此bug隐藏较深不易发现，你怎么证明没技术狂人早发现了并一直在利用？……被人爽了10几年还帮着洗白
引用来自“noonoo”的评论
住了十九年，才发现卧室被安装了摄像头。呜，想想，是去掉他，还是升级为盗摄现场吧！