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

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

　一、很多專案生命期不超過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，還是應該順其自然，不改為好。程式設計師朋友們，你說呢？