能存活19年的bug不是bug——有感於微軟宣佈修復了一個存在了19年的安全漏洞

近日，各大網站，包括新浪、騰訊、網易、搜狐都報道了一則關於微軟宣佈修復了一個存在了19年的安全漏洞的新聞，以騰訊科技爲例，它的標題是《微軟修復已存在19年的漏洞》。對於一個軟件製造界外的人來講，這是一個大快人心的消息，就跟一個隱藏了19年的納粹分子終於被抓住的新聞同樣轟動。但以程序員爲職業的我，聽到這樣一個消息，卻有一種很是不解、甚至是荒謬、搞笑的感受。從軟件生產的角度講，若是一個bug能存活19年，那它仍是個bug嗎？

1、不少項目生命期不超過19年

我在不少國企開發過項目，這些項目幾乎每過幾年都會從新開發一回，老項目或者廢棄、或者推倒重來，遇到領導換班子或上級政策方向的改變，更容易發生這種事情。事實上，有大量的軟件存活不到19年，都很短命。這一方面是技術的緣由，更重要的一方面是國情的因素。若是在這樣的一個項目裏有一個bug，當這個軟件幾年後被遺棄時，歷來沒有被人發現——更符合軟件科學的說，沒有給用戶帶來任何煩惱。這樣的bug對於用戶來講是不可見、不可知、根本不存在的。咱們沒有必要、也不該該將這樣的bug稱做bug，更不該該爲這樣的bug大驚小怪。

2、修改bug有風險

我記得有一個很是有趣的關於bug段子，說的是：

代碼中有99個小bug，
99個小bug，
修復了一個，
如今，代碼中的有117個小bug。

雖然是個笑話，但做爲程序員，我一點都笑不出來，由於這種事情在咱們項目的開發過程當中常常的會遇到。因爲糾正接口中一個bug而致使其它程序調用這個接口時出現了另外的問題。你可能會嘲笑說這是測試程序寫的不夠周全，但不少時候，複雜的軟件內部關聯是很難讓加班加點的程序員考慮周全的。

因此，在一個複雜的軟件裏，特別是對於老項目，最先開發這個項目的人已經流失，而項目文檔又寫的不夠清晰，若是一個bug不是特別嚴重、不影響核心業務，若是能說服客戶不修改，那就優先考慮不修改，若是非要修改，那必需要深思熟慮、準備充足的測試用例，並想好回退方案，以防萬一。

3、是bug？仍是設計的功能特徵？

以前就有一篇很好的文章指出，Bash裏一個所謂的bug其實是25年專門設計的功能，只是時過境遷，如今的使用環境發生了很大的變化，人們並無及時的調整過去的老代碼，或者如今的新環境並無照顧過去的老接口。

因此，咱們今天看到的一個愚蠢的 bug，也許在歷史上的某一天，是一個有意而爲之的神奇特性。咱們應該思考的不只僅是這一刻的 bug 或者安全隱患自己，而是在軟件開發這個極具創新的活動中，如何有效的保證某個特地設計的功能不會變成 bug。

總之，一個19年的bug，一直默默無聞，沒有被人發現、沒有給用戶帶來麻煩、形成損失。我想，時間證實了這個bug是個善良的bug，是個好bug，我寧願將它升級成一個功能。即便不能如此，使用用戶在這些年的使用中也早就適應了這個bug，可以很好的與它和氣相處，已經不把它當成危險的敵人了。事實上，在用戶的內心，它已經升級進化，蛻掉了bug的外殼。這樣的bug，仍是應該順其天然，不改成好。程序員朋友們，你說呢？