能存活19年的bug不算bug——感觉微软宣布修复存在19年的安全漏洞修复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，我宁愿把它升级成feature。即便不是这样，用户在这些年的使用中也已经适应了这个bug，可以和它相处融洽，不再把它当成危险的敌人。事实上，在用户心中，它已经升级进化，脱去??了bug的外壳。对于这样的bug，还是顺其自然，不要去改变。程序员朋友们，你们怎么看？
