想要推倒舊代碼，

重寫(xiě)代碼的程序員們，

請(qǐng)注意：

保持冷靜，繼續(xù)前行!

程序員都有一顆工程師的心，所以當(dāng)他們到一片新的場(chǎng)地想做的第一件事就是，將舊的一切推倒重來(lái)。是的，他們決不會(huì)滿足于簡(jiǎn)單的增量勞動(dòng)。

或許這種微妙的心理定位可以解釋：為什么程序員進(jìn)入新項(xiàng)目組后寧愿丟掉舊代碼重新寫(xiě)，也不愿意修修補(bǔ)補(bǔ)。他們認(rèn)為舊代碼簡(jiǎn)直一團(tuán)糟。

但是，事實(shí)上真是這樣嗎?你之所以認(rèn)為舊代碼一團(tuán)糟，其實(shí)是由編程的一個(gè)基本定律決定的，那就是：寫(xiě)代碼容易，讀代碼難。

為什么你覺(jué)得舊代碼異?；靵y?因?yàn)樽x代碼更難。

這大概就是代碼Reuse難以實(shí)現(xiàn)的原因。 這就是你組里的每個(gè)人都喜歡用不同的功能將分割的字符串轉(zhuǎn)換成一個(gè)數(shù)組。比起猜測(cè)舊的功能是怎樣實(shí)現(xiàn)的，重新寫(xiě)一個(gè)自己的功能要簡(jiǎn)單和有趣多了。

作為這個(gè)公理的推論，你可以問(wèn)問(wèn)身邊的程序員他們正在奮戰(zhàn)的代碼怎么樣?「簡(jiǎn)直是一塌糊涂!」他們肯定會(huì)這樣說(shuō)?！肝液?jiǎn)直想推倒重來(lái)!」

為什么認(rèn)為代碼這么糟糕呢?「額，看看這個(gè)功能，竟然有兩頁(yè)長(zhǎng)!完全不知道這些東西為什么在這里!完全不知道這些API是干什么的?！顾麄儠?huì)這樣回答你。

曾經(jīng)，Borland的創(chuàng)始人 Philippe Kahn當(dāng)初就是向記者們吹噓：Quattro Pro會(huì)比Microsoft Excel要好用得多，因?yàn)樗菑念^開(kāi)始編寫(xiě)的，全部都是新的源代碼!

但是，認(rèn)為新代碼比舊代碼好簡(jiǎn)直就是荒謬。舊代碼是已經(jīng)運(yùn)行過(guò)的，測(cè)試過(guò)的。無(wú)數(shù)的bug在被發(fā)現(xiàn)前都上線運(yùn)行過(guò)，發(fā)現(xiàn)之后程序員們可能在花了好些日子才修復(fù)了這些bug。這種修復(fù)可能是一行代碼，也可能是幾個(gè)字符，無(wú)數(shù)的時(shí)間和精力都花在了這些bug修復(fù)上。

當(dāng)你決定拋棄這些舊代碼從零開(kāi)始的時(shí)候，你也丟掉全部前任努力的結(jié)果。

新代碼一定比舊代碼的好嗎?NO，NO，NO重寫(xiě)可能會(huì)帶來(lái)更大的風(fēng)險(xiǎn)。

對(duì)技術(shù)領(lǐng)導(dǎo)者來(lái)說(shuō)，重寫(xiě)項(xiàng)目的代碼也是一個(gè)異常艱難的決定。因?yàn)閺墓緦用嬲f(shuō)，重現(xiàn)代碼甚至?xí){產(chǎn)品的市場(chǎng)競(jìng)爭(zhēng)力。一旦決定重寫(xiě)代碼，那么與競(jìng)品相比，你可能落后了2~3年——在軟件行業(yè)，這時(shí)間可夠長(zhǎng)的。

你理想中的新代碼會(huì)帶來(lái)產(chǎn)品功能的提升

但事實(shí)上，即便重寫(xiě)的新代碼可以實(shí)現(xiàn)舊代碼的所有功能和需求，但是為產(chǎn)品帶來(lái)的市場(chǎng)競(jìng)爭(zhēng)力只有邊際提升。因?yàn)橹貙?xiě)用的新技術(shù)、新語(yǔ)言、新框架并沒(méi)有給產(chǎn)品帶來(lái)質(zhì)的飛躍。

更不用說(shuō)在重寫(xiě)的漫長(zhǎng)過(guò)程中可能會(huì)遇到一些意外情況，比如：

缺錢：資金鏈的斷裂

缺人：核心程序員離職

最終導(dǎo)致效果不佳：達(dá)不到原產(chǎn)品應(yīng)有的所有功能和需求，白白浪費(fèi)了時(shí)間和金錢，也丟掉了市場(chǎng)競(jìng)爭(zhēng)力。

所以重寫(xiě)代碼意味著，你在把自己置身于非常危險(xiǎn)的境地，可能幾年后你也寫(xiě)不出比以前更好的代碼。你只是花了一大筆錢把已經(jīng)存在的代碼又寫(xiě)了一遍。

當(dāng)你覺(jué)得眼前的舊代碼很爛時(shí)，該怎么辦?

你覺(jué)得舊代碼寫(xiě)的很爛，那又怎樣呢?它們已經(jīng)上線，已經(jīng)在實(shí)際運(yùn)行中經(jīng)受住了考驗(yàn)。所以當(dāng)你發(fā)現(xiàn)前任留下的代碼亂七八糟的時(shí)候，不妨冷靜下來(lái)，從以下三個(gè)方面入手理解代碼、改善代碼：

1代碼的機(jī)構(gòu)有問(wèn)題

如果一段網(wǎng)絡(luò)代碼突然彈出了自己的對(duì)話框，應(yīng)該是UI代碼需要被處理。這些問(wèn)題可以被解決掉，你要一次次小心地移動(dòng)代碼，重構(gòu)，改變接口。還需要一位細(xì)心的工程師立馬仔細(xì)地檢查這些改變是否有問(wèn)題，從而不打擾到其他人。事實(shí)上，甚至比較大的結(jié)構(gòu)變化也可以不扔掉代碼來(lái)完成。

大牛程序員回憶說(shuō)，曾經(jīng)在某個(gè)項(xiàng)目中，他和他的團(tuán)隊(duì)花了好幾個(gè)月重新架構(gòu)在一點(diǎn)上：把代碼動(dòng)來(lái)動(dòng)去、清理、創(chuàng)建有意義的基類，并創(chuàng)建了模塊之間的完美接口。但是他們始終非常小心翼翼，并沒(méi)有產(chǎn)生新的bug、也沒(méi)有丟掉任何舊代碼。

2代碼的效率不高

曾經(jīng)，Netscape的渲染代碼被傳非常緩慢。但事實(shí)上，這只會(huì)影響該項(xiàng)目的一小部分，這部分是你可以優(yōu)化甚至重寫(xiě)的。你完全不必重寫(xiě)全部代碼。優(yōu)化速度的1%工作量，會(huì)讓你獲得99%的爆炸性提高。

3代碼寫(xiě)得很丑

有些代碼真的寫(xiě)的很丑，比如Joel曾參與一個(gè)項(xiàng)目，開(kāi)始用下劃線做開(kāi)始的成員變量約定，但后來(lái)改用更標(biāo)準(zhǔn)的「M_」。所以一半的功能用「_」開(kāi)始，一半用「M」開(kāi)始，這看起來(lái)真的很丑陋。但這個(gè)問(wèn)題5分鐘就能解決，而不用從頭開(kāi)始寫(xiě)全部的代碼。

最后，你要記住，從頭開(kāi)始再寫(xiě)一遍并不意味著你會(huì)寫(xiě)出比以前更好的代碼。因?yàn)槟銢](méi)有參與到上一個(gè)版本的創(chuàng)建，所以你其實(shí)根本就不算有經(jīng)驗(yàn)。一旦你準(zhǔn)備推倒重寫(xiě)，你可能會(huì)再犯一遍版本一犯過(guò)的錯(cuò)，甚至?xí)a(chǎn)生更多的新問(wèn)題。

面對(duì)糟糕的舊代碼，Keep Calm & Carry On !

在大型商業(yè)項(xiàng)目中，推倒重來(lái)是非常危險(xiǎn)的行為。當(dāng)然，如果你是在做實(shí)驗(yàn)，想到新算法可以隨時(shí)重寫(xiě)。

如果你跳槽、或剛接手一個(gè)新項(xiàng)目，面對(duì)看上去異?；靵y的舊代碼，請(qǐng)冷靜下來(lái)，忍住推倒重寫(xiě)的沖動(dòng)，想想上面這些經(jīng)驗(yàn)之談。