最近剛修復(fù)了一個存在長達3年多的bug，是這樣的

軟件從3.0 升級到3.1的時候，某個數(shù)據(jù)結(jié)構(gòu)不再兼容了，但是一個數(shù)據(jù)處理的代碼需要兼容以前3.0的數(shù)據(jù)結(jié)構(gòu)。
于是當(dāng)時的開發(fā)人員寫下了這么一段代碼，偽代碼如下：

if isVersion(3.1) then
       process Data in 3.1 format
else
       process Data in 3.0 format
endif

這樣的代碼，當(dāng)時工作很好，測試絕對沒有問題，但是當(dāng)軟件版本繼續(xù)升級到3.2....4.0....5.0....
問題就出來了，當(dāng)時的判斷是is 判斷，而不是比較大小，所以3.2以及以后版本都會當(dāng)作3.0處理，碰巧的是 Process data是另外開發(fā)組開發(fā)的，他們提供了一定的容錯性，可以識別3.0版本的數(shù)據(jù)格式并處理，但是這樣會損失一點性能，大約20％左右，但是當(dāng)初數(shù)據(jù)量都不大所以測試中也沒人發(fā)現(xiàn)。直到了5.1版本，這時候數(shù)據(jù)量變得很大了，這點性能損失變得比較明顯了，因為這系統(tǒng)里數(shù)據(jù)處理涉及很多加密解碼壓縮校驗以及遠程調(diào)用等等。。。3年來浪費了如此多資源都來源于當(dāng)初那個開發(fā)人員的一念之差，如果他寫成 if versionGreatThan(3.0) 就一切OK。

我了解了一下歷史，那時候正是開發(fā)很緊張的時候，進度壓力很大，這個編碼估計也是臨時打的補丁，沒有深思熟慮。
現(xiàn)實中我們不可避免地要使用些暴力手段寫點 hardcode來打補丁，有時候進度壓力很大，沒辦法的，但是我覺得應(yīng)該有養(yǎng)成良好的習(xí)慣，在做這樣的事情的時候盡量縮小影響的范圍，比如可以寫成這樣：

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

這樣的話，當(dāng)系統(tǒng)升級到3.2的時候這個ASSERT會跳出來，提醒你這里有問題，那時候如果時間寬裕可以去找出更優(yōu)雅的解決方案。