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

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

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

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

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

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)升級(jí)到3.2的時(shí)候這個(gè)ASSERT會(huì)跳出來，提醒你這里有問題，那時(shí)候如果時(shí)間寬裕可以去找出更優(yōu)雅的解決方案。