能存活19年的bug，還是個bug嗎？
近日，各大網站，包括新浪、騰訊、網易、搜狐都報道了一則關于微軟宣布修復了一個存在了19年的安全漏洞的新聞，以騰訊科技為例，它的標題是《微軟修復已存在19年的漏洞》。 對于一個軟件制造界外的人來說，這是一個大快人心的消息，就跟一個隱藏了19年的納粹分子終于被抓住的新聞一樣轟動。但以程序員為職業(yè)的我，聽到這樣一個消息，卻有一種非常不解、甚至是荒謬、搞笑的感覺。從軟件生產的角度講，如果一個bug能存活19年，那它還是個bug嗎?
一、很多項目生命期不超過19年
我在很多國企開發(fā)過項目，這些項目幾乎每過幾年都會重新開發(fā)一回，老項目或者廢棄、或者推倒重來，遇到領導換班子或上級政策方向的改變，更容易發(fā)生這種事情。事實上，有大量的軟件存活不到19年，都很短命。這一方面是技術的原因，更重要的一方面是國情的因素。如果在這樣的一個項目里有一個bug，當 這個軟件幾年后被遺棄時，從來沒有被人發(fā)現——更符合軟件科學的說，沒有給用戶帶來任何煩惱。這樣的bug對于用戶來說是不可見、不可知、根本不存在的。 我們沒有必要、也不應該將這樣的bug稱作bug，更不應該為這樣的bug大驚小怪。
二、修改bug有風險
我記得有一個非常有趣的關于bug段子，說的是：
代碼中有99個小bug，
99個小bug，
修復了一個，
現在，代碼中的有117個小bug。
雖然是個笑話，但作為程序員，我一點都笑不出來，因為這種事情在我們項目的開發(fā)過程中經常的會遇到。由于糾正接口中一個bug而導致其它程序調用這個接口時出現了另外的問題。你可能會嘲笑說這是測試程序寫的不夠周全，但很多時候，復雜的軟件內部關聯是很難讓加班加點的程序員考慮周全的。
所以，在一個復雜的軟件里，特別是對于老項目，最早開發(fā)這個項目的人已經流失，而項目文檔又寫的不夠清晰，如果一個bug不是特別嚴重、不影響核心業(yè)務，如果能說服客戶不修改，那就優(yōu)先考慮不修改，如果非要修改，那必須要深思熟慮、準備充足的測試用例，并想好回退方案，以防萬一。
三、是bug?還是設計的功能特征?
之前就有一篇很好的文章指出，Bash里一個所謂的bug實際上是25年專門設計的功能，只是時過境遷，現在的使用環(huán)境發(fā)生了很大的變化，人們并沒有及時的調整過去的老代碼，或者現在的新環(huán)境并沒有照顧過去的老接口。
所以，我們今天看到的一個愚蠢的bug，也許在歷史上的某一天，是一個有意而為之的神奇特性。我們應該思考的不僅僅是這一刻的bug 或者安全隱患本身，而是在軟件開發(fā)這個***創(chuàng)新的活動中，如何有效的保證某個特意設計的功能不會變成bug。
總之，一個19年的bug，一直默默無聞，沒有被人發(fā)現、沒有給用戶帶來麻煩、造成損失。我想，時間證明了這個bug是個善良的bug，是個好bug，我寧愿將它升級成一個功能。即使不能如此，使用用戶在這些年的使用中也早就適應了這個bug，能夠很好的與它和睦相處，已經不把它當成危險的敵人 了。事實上，在用戶的心里，它已經升級進化，蛻掉了bug的外殼。這樣的bug，還是應該順其自然，不改為好。程序員朋友們，你說呢?
