作為 100offer 程式員拍賣的營運，我們常常和使用者交流讨論，有一個話題經久不衰：程式員入職新公司後接手已有的代碼，怎麼處理？
程式員都有一顆工程師的心，是以當他們到一片新的場地想做的第一件事就是，将舊的一切推倒重來。是的，他們決不會滿足于簡單的增量勞動。
或許這種微妙的心理定位可以解釋：為什麼程式員進入新項目組後甯願丢掉舊代碼重新寫，也不願意修修補補，他們認為舊代碼簡直一團糟。
但是，事實上真是這樣嗎？你之是以認為舊代碼一團糟，其實是由程式設計的一個基本定律決定的，那就是：寫代碼容易，讀代碼難。
為什麼你覺得舊代碼異常混亂？因為讀代碼更難
這大概就是代碼reuse難以實作的原因，也可以解釋為什麼你組裡的每個人都喜歡用不同的功能将分割的字元串轉換成一個數組。比起猜測舊的功能是怎樣實作的，重新寫一個自己的功能要簡單和有趣多了。
作為這個公理的推論，你可以問問身邊的程式員他們正在奮戰的代碼怎麼樣？“簡直是一塌糊塗！”他們肯定會這樣說。“我簡直想推倒重來！”
為什麼認為代碼這麼糟糕呢？“額，看看這個功能，竟然有兩頁長！完全不知道這些東西為什麼在這裡！完全不知道這些api是幹什麼的。”他們會這樣回答你。
漫畫：讀别人代碼是一種怎樣的體驗？
曾經，borland的創始人 philippe kahn當初就是向記者們吹噓：quattro pro會比microsoft excel要好用得多，因為它是從頭開始編寫的，全部都是新的源代碼！
但是，認為新代碼比舊代碼好簡直就是荒謬。舊代碼是已經運作過的，測試過的。無數的bug在被發現前都上線運作過，發現之後程式員們可能在花了好些日子才修複了這些bug。這種修複可能是一行代碼，也可能是幾個字元，無數的時間和精力都花在了這些bug修複上。
當你決定抛棄這些舊代碼從零開始的時候，你也丢掉全部前任努力的結果。
新代碼一定比舊代碼好？no，重寫可能會帶來更大的風險
對技術上司者來說，重寫項目的代碼也是一個異常艱難的決定。因為從公司層面說，重制代碼甚至會威脅産品的市場競争力。一旦決定重寫代碼，那麼與競品相比，你可能落後了2~3年——在軟體行業，這時間可夠長的。
你理想中的新代碼會帶來産品功能的提升▼
但事實上，即便重寫的新代碼可以實作舊代碼的所有功能和需求，但是為産品帶來的市場競争力隻有邊際提升。因為重寫用的新技術、新語言、新架構并沒有給産品帶來質的飛躍。
更不用說在重寫的漫長過程中可能會遇到一些意外情況，比如：
1、缺錢：資金鍊的斷裂
2、缺人：核心程式員離職
最終導緻效果不佳：達不到原産品應有的所有功能和需求，白白浪費了時間和金錢，也丢掉了市場競争力。
是以重寫代碼意味着，你在把自己置身于非常危險的境地，可能幾年後你也寫不出比以前更好的代碼。你隻是花了一大筆錢把已經存在的代碼又寫了一遍。
當你覺得眼前的舊代碼很爛時，該怎麼辦？
你覺得舊代碼寫的很爛，那又怎樣呢？它們已經上線，已經在實際運作中經受住了考驗。是以當你發現前任留下的代碼亂七八糟的時候，不妨冷靜下來，從以下三個方面入手了解代碼、改善代碼：
1、代碼的結構有問題
如 果一段網絡代碼突然彈出了自己的對話框，應該是ui代碼需要被處理。這些問題可以被解決掉，你要一次次小心地移動代碼，重構，改變接口。還需要一位細心的 工程師立馬仔細地檢查這些改變是否有問題，進而不打擾到其他人。事實上，甚至比較大的結構變化也可以不扔掉代碼來完成。
大牛程式員joel spolsky回憶說，曾經在某個項目中，他和他的團隊花了好幾個月重新架構在一點上：把代碼動來動去、清理、建立有意義的基類，并建立了子產品之間的完美接口。但是他們始終非常小心翼翼，并沒有産生新的bug，也沒有丢掉任何舊代碼。
2、代碼的效率不高
曾經，netscape的渲染代碼被傳非常緩慢。但事實上，這隻會影響該項目的一小部分，這部分是你可以優化甚至重寫的。你完全不必重寫全部代碼。優化速度的1％工作量，會讓你獲得99％的爆炸性提高。
3、代碼寫得很醜
有些代碼真的寫的很醜，比如joel曾參與一個項目，開始用下劃線做開始的成員變量約定，但後來改用更标準的“m_”。是以一半的功能用“_”開始，一半用“m”開始，這看起來真的很醜陋。但這個問題5分鐘就能解決，而不用從頭開始寫全部的代碼。
最後，你要記住，從頭開始再寫一遍并不意味着你會寫出比以前更好的代碼。因為你沒有參與到上一個版本的建立，是以你其實根本就不算有經驗。一旦你準備推倒重寫，你可能會再犯一遍版本一犯過的錯，甚至會産生更多的新問題。
總結
面對糟糕的舊代碼，keep calm & carry on!
在大型商業項目中，推倒重來是非常危險的行為。當然，如果你是在做實驗，想到新算法可以随時重寫。如果你跳槽、或剛接手一個新項目，面對看上去異常混亂的舊代碼，請冷靜下來，忍住推倒重寫的沖動，想想上面這些經驗之談。