最近剛修復(fù)了一個(gè)存在長(zhǎng)達(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í)的開(kāi)發(fā)人員寫下了這么一段代碼，偽代碼如下：
if isVersion(3.1) then
process Data in 3.1 format
else
process Data in 3.0 format
endif
這樣的代碼，當(dāng)時(shí)工作很好，測(cè)試絕對(duì)沒(méi)有問(wèn)題，但是當(dāng)軟件版本繼續(xù)升級(jí)到3.2....4.0....5.0....
問(wèn)題就出來(lái)了，當(dāng)時(shí)的判斷是is 判斷，而不是比較大小，所以3.2以及以后版本都會(huì)當(dāng)作3.0處理，碰巧的是 Process data是另外開(kāi)發(fā)組開(kāi)發(fā)的，他們提供了一定的容錯(cuò)性，可以識(shí)別3.0版本的數(shù)據(jù)格式并處理，但是這樣會(huì)損失一點(diǎn)性能，大約20％左右，但是當(dāng)初數(shù)據(jù)量都不大所以測(cè)試中也沒(méi)人發(fā)現(xiàn)。直到了5.1版本，這時(shí)候數(shù)據(jù)量變得很大了，這點(diǎn)性能損失變得比較明顯了，因?yàn)檫@系統(tǒng)里數(shù)據(jù)處理涉及很多加密解碼壓縮校驗(yàn)以及遠(yuǎn)程調(diào)用等等。。。3年來(lái)浪費(fèi)了如此多資源都來(lái)源于當(dāng)初那個(gè)開(kāi)發(fā)人員的一念之差，如果他寫成 if versionGreatThan(3.0) 就一切OK。
我了解了一下歷史，那時(shí)候正是開(kāi)發(fā)很緊張的時(shí)候，進(jìn)度壓力很大，這個(gè)編碼估計(jì)也是臨時(shí)打的補(bǔ)丁，沒(méi)有深思熟慮。
現(xiàn)實(shí)中我們不可避免地要使用些暴力手段寫點(diǎn) hardcode來(lái)打補(bǔ)丁，有時(shí)候進(jìn)度壓力很大，沒(méi)辦法的，但是我覺(jué)得應(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ì)跳出來(lái)，提醒你這里有問(wèn)題，那時(shí)候如果時(shí)間寬裕可以去找出更優(yōu)雅的解決方案。