《Effective Debugging：軟體和系統調試的66個有效方法》——第14條：考慮對軟體進行更新

本節書摘來自華章計算機《effective debugging：軟體和系統調試的66個有效方法》一書中的第2章，第14節，作者［希］迪歐米迪斯·斯賓奈裡斯（diomidis spinellis），愛飛翔 譯，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

接下來，筆者要說幾個很多人都意想不到的bug來源。并非所有錯誤都是由于你自己所寫的代碼而造成的，用來處理這些代碼的編譯器或解釋器、你所使用的程式庫、你所依賴的資料庫和應用程式伺服器，以及上述工具所在的作業系統，也有可能要對程式中的bug負有責任。筆者編寫本書時，linux的源代碼裡面包含2700多條帶有xxx字樣的注釋，該标記通常意味着可疑的内容，這其中有一些肯定是bug。

于是，有些bug就可以通過更新軟體來解決。如果你要釋出的打包應用程式裡面出現了隐晦的bug，那麼使用新版的編譯器或程式庫或許能夠幫助你修複這個bug。如果你要釋出基于軟體的服務，那麼對中間件、資料庫及作業系統進行更新也是很有好處的。至少應該嘗試用最新的版本來建構、連結或運作程式代碼，以盡量消除因第三方元件而引入bug的機率。然而，有時采用稍微保守一些的更新政策也是很有道理的，這就是說，盡管我們知道舊版軟體不太完美，但是基于某些原因，我們還是決定繼續使用這些軟體。有很多中間件本身編寫得就有錯誤，或是向後相容性不太好，是以，有經驗的使用者通常會較為謹慎地進行更新，他們會更新到能夠解決其問題，而且釋出時間第二早的那個bug修複版本上面（如6.4.3版）。此外，新版軟體也會引入新的bug與相容性問題，是以在更新的時候至少要給自己留一條退路，也就是要拟定一套明智的後退計劃，如果更新失敗，或是更新到的版本無法解決你所面對的bug，那麼可以根據該方案退回原有的版本。我們可以在沙盒中更新第三方的代碼，例如，可以對虛拟機進行複制，在複制出來的鏡像裡面進行更新，如果更新後的效果不好，那麼直接把這份鏡像丢掉就行了，這是一種可靠且較為簡便的辦法。盡管更新軟體對解決bug确實有一定的幫助，但無論如何都不要對此抱有過高的期望。

除非你能夠證明外部代碼确實有錯，否則最好是先假設它們正确無誤。有些bug看上去好像是由第三方代碼所引發的，然而在大多數情況下，其實是由于你自己的問題而造成的。30年的調試曆程中，筆者在自己的代碼裡面修複了數以千計的bug，與之相對，由于某款流行的商業編譯器生成了錯誤的代碼而導緻的bug隻出現了一次，由于程式庫而導緻的bug隻出現了幾次，由于作業系統的功能不穩定而導緻的bug隻出現了一次，由于描述系統調用的文檔有錯而導緻的bug隻出現了幾次，由于工具和其他系統軟體而導緻的bug也隻出現了幾十次。是以，對軟體進行更新的最大意義，就在于給我們提供一個新的起點，令我們可以下定決心來好好清理自己的代碼。

在更新之後的環境裡面重新嘗試你所編寫的代碼，看看這次會不會出錯。

不要對更新軟體所帶來的效果抱有過高的期望。

要考慮因第三方元件而引發bug的可能性。