一個有趣的小 Bug 避免了一場大災難(2)

　　幸運的是，當我告知CTO bug的時候，他非常敏銳地認識到了問題的嚴重性，快速跑去驗證并解決問題。他證實了公司通過使用由一系列通用工具和模塊組成的平臺來創建軟件，這意味著他們會天然地復制組件，例如不同產品中的即時通訊系統，但他向我保證，所有的bug實例都會被修復。

　　由于這家公司通過重用模塊來創建軟件，因此在其產品中的任何一個問題都很有可能存在于其他很多產品中，作為缺陷代碼被重用。此外，事實證明該公司使用該平臺并不只是為學校教育構建了模擬軟件。他們還開發了為“世界各地的企業和政府機構”提供共享和可視化數據的軟件，并期望通過瀏覽他們網站的“案例”部分，許多他們面向業務的應用程序趨向于囊括用戶之間的消息功能。這意味著，我們課堂軟件中的那個低風險bug，可能會成為實時應用程序處理政府或企業的敏感數據時的高風險bug，導致消息系統易受攻擊。

　　每一個程序員都會犯錯，而且像這樣的跨站點腳本問題是不可避免的。質量保證流程可能會錯過類似于這樣的bug，原因或許是因為團隊正火燒眉毛地沖刺最后的截止時間，所以規避質量保證能為他們爭取時間，而且他們的代碼將在系統的低風險部分使用。但是，如果你正在構建軟件模塊化它，然而卻沒有重新測試缺陷組件，就把它用到了其他地方，從而讓其他地方也出現安全隱患，就可能會造成實實在在的災難。

　　當然，不要誤解我的意思，我并不是說重用代碼不好，重用代碼是一件了不起的事情，它能讓我們更快速地構建系統，而且通常正確率更高。這個真實的故事告訴我們，得益于重用代碼的巨大好處，因此幾乎我們使用的所有軟件都不可能存在于真空中，同時一個無聊游戲中的bug實際上可能也會導致嚴重的系統漏洞，防微杜漸，刻不容緩。

原文轉自：http://www.testwo.com/article/587