最近剛修復了一個存在長達3年多的bug，是這樣的
軟件從3.0 升級到3.1的時候，某個數據結構不再兼容了，但是一個數據處理的代碼需要兼容以前3.0的數據結構。
于是當時的開發人員寫下了這么一段代碼，偽代碼如下：
if isVersion(3.1) then
process Data in 3.1 format
else
process Data in 3.0 format
endif
這樣的代碼，當時工作很好，測試絕對沒有問題，但是當軟件版本繼續升級到3.2....4.0....5.0....
問題就出來了，當時的判斷是is 判斷，而不是比較大小，所以3.2以及以后版本都會當作3.0處理，碰巧的是 Process data是另外開發組開發的，他們提供了一定的容錯性，可以識別3.0版本的數據格式并處理，但是這樣會損失一點性能，大約20％左右，但是當初數據量都不大所以測試中也沒人發現。直到了5.1版本，這時候數據量變得很大了，這點性能損失變得比較明顯了，因為這系統里數據處理涉及很多加密解碼壓縮校驗以及遠程調用等等。。。3年來浪費了如此多資源都來源于當初那個開發人員的一念之差，如果他寫成 if versionGreatThan(3.0) 就一切OK。
我了解了一下歷史，那時候正是開發很緊張的時候，進度壓力很大，這個編碼估計也是臨時打的補丁，沒有深思熟慮。
現實中我們不可避免地要使用些暴力手段寫點 hardcode來打補丁，有時候進度壓力很大，沒辦法的，但是我覺得應該有養成良好的習慣，在做這樣的事情的時候盡量縮小影響的范圍，比如可以寫成這樣：
if isVersion(3.1) then
process Data in 3.1 format
else if isVersion(3.0)
process Data in 3.0 format
else
ASSERT(FALSE)
endif
這樣的話，當系統升級到3.2的時候這個ASSERT會跳出來，提醒你這里有問題，那時候如果時間寬裕可以去找出更優雅的解決方案。