近日，新浪、腾讯、网易、搜狐等各大网站都报道了微软宣布修复一个存在了19年的安全漏洞的消息。以腾讯科技为例，它的标题是《微软修复已存在19年的漏洞》。对于软件制造世界之外的人来说，这是个好消息，就像一个隐藏了19年的纳粹终于被捕的消息一样轰动。但是作为一个职业程序员，听到这样的消息，我感到很不解，甚至很荒唐，也很可笑。从软件生产的角度来看，如果一个bug能存活19年，它还是bug吗？1.许多项目的寿命不超过19年。我在很多国企开发过项目，这些项目几乎每隔几年就会重新开发。曾经，老项目不是废弃就是推倒重来，这种事情在领导换届或者上级政策方向改变的时候比较容易发生。事实上，有大量的软件存活不到19年，这是非常短暂的。这方面是技术的原因，更重要的是国情的原因。如果在这样的项目中存在错误，当软件在几年后被放弃时，它永远不会被发现——更科学的软件，不会对用户造成任何困扰。此类错误对用户来说是不可见的、不可知的和不存在的。我们不需要也不应该把这样的bug称为bug，更不要为这样的bug做文章。2、修改bug存在风险。记得有一段讲bug很有意思，里面说：代码有99个小bug，99个小bug，修复一个。现在，代码中有117个小错误。虽然是个玩笑，但是作为一个程序员，我是一点也笑不出来的，因为这种事情在我们项目开发的过程中经常遇到。另一个问题出现在其他程序调用这个接口时，由于修复了接口中的一个错误。说到这里你可能会笑说测试程序写得不好，但很多时候，加班加点的程序员很难考虑到软件复杂的内部关联。所以，在复杂的软件中，尤其是老项目，第一个开发项目的人已经丢失，项目文档写得不够清楚。如果一个bug不是特别严重，不影响核心业务，如果能说服客户不要修改，那就优先不修改。如果一定要修改，一定要慎重考虑，准备足够的测试用例，想好后备方案，以防万一。3.是bug吗？或者它是一个设计的功能？之前一篇不错的文章指出，所谓Bash中的一个bug，其实是专门设计了25年的一个功能，只是时过境迁，现在的使用环境发生了很大的变化，人们没有及时调整旧代码，或者新环境没有照顾过去的旧界面。因此，我们今天看到的一个愚蠢的错误可能在历史的某一天成为一个有意的神奇功能。此时此刻我们应该思考的不仅仅是bug或安全风险本身，而是在软件开发最具创新性的活动中，如何有效保证一个专门设计的功能不会成为bug。总之，一个19年的bug一直不为人知，没有被发现，没有给用户带来麻烦和损失。我想，时间已经证明这个错误是一个好错误，一个好错误，我宁愿将它升级为一个功能。即便不是这样，用户在这些年的使用中也已经适应了这个bug，可以和它相处融洽，不再把它当成危险的敌人。事实上，在用户心中，它已经升级进化，脱去??了bug的外壳。对于这样的bug，还是顺其自然，不要去改变。程序员朋友，你说呢？
