近日，包括新浪、腾讯、网易、搜狐在内的各大网站都报道了一则关于微软宣布修复安全漏洞19年的新闻。以腾讯科技为例，其标题是微软修复漏洞19年。对于一个软件制造业外的人来说，这是一个很受欢迎的消息，就像一个隐藏了19年的纳粹分子终于被抓住的消息一样轰动。但是作为一名程序员，当我听到这样的消息时，我感到非常困惑，甚至荒谬和有趣。从软件生产的角度来看，如果是一个bug能活19年，那它还是个人bug吗?
1.许多项目的寿命不超过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，还是顺其自然，不改为好。程序员朋友们，你们说呢？