重寫程式碼消耗了12個月！

我們從頭開始重寫程式碼浪費的時間。你能想象在軟體行業，12個月的時間沒有任何新產品推出，沒有任何新版本更新嗎？

真的，我不由自主地問自己這個問題：

在這個快速發展的世界裡，12月的時間能讓我們做多少事情？

“2015年1月20日，星期二，下午5:10，AntiMalware軟體終於進入了第一次公測。”

經過幾十個小時的不眠不休後，第一個版本的軟體說明書終於釋出到了網站上，這標誌著我們的新旅程的開始。

我在一家為企業和終端使用者提供安全軟體的小型網路安全公司工作。我們開發的軟體保護使用者免受惡意軟體的侵害。如果使用者的電腦被惡意軟體感染，我們的軟體會幫助他們清理。AntiMalware就是其中一個軟體。

第一個測試版收到的反饋令人鼓舞。我們有四個開發人員為這個產品工作，不斷地修復Bug, 改進產品功能，推出新版本。

為什麼你覺得舊程式碼異常混亂？因為讀程式碼更難

這大概就是程式碼Reuse難以實現的原因，也可以解釋為什麼你組裡的每個人都喜歡用不同的功能將分割的字串轉換成一個陣列。比起猜測舊的功能是怎樣實現的，重新寫一個自己的功能要簡單和有趣多了。

作為這個公理的推論，你可以問問身邊的程式設計師他們正在奮戰的程式碼怎麼樣？“簡直是一塌糊塗！”他們肯定會這樣說。“我簡直想推倒重來！”

為什麼認為程式碼這麼糟糕呢？“額，看看這個功能，竟然有兩頁長！完全不知道這些東西為什麼在這裡！完全不知道這些API是幹什麼的。”他們會這樣回答你。

重構是避免不了的，程式設計師永遠需要在好的架構和不停變更的需求中做取捨，透過不斷重構消化掉髒程式碼。你需要避免的是程式碼徹底超出掌控之後完全重構這個過程。

簡單，別省錢，別找外包，找牛逼一些的程式設計師，最好招一隊人馬。

反正你要的又不是好程式碼，只是一個結果，程式碼的好壞你也不在意對不對，所以沒責任心也沒能力的程式設計師把事情搞砸再正常不過，這個便宜可不好佔。

我見過把好程式碼重構成垃圾的，也見過垃圾程式碼維護不下去只能重構的，全看拿工資的人是不是有品味。

不過老闆們大約也不用擔心，花錢從高階一點的公司裡邊挖人，由靠譜的人來把關就好了。

所以當你發現前任留下的程式碼亂七八糟的時候，不妨冷靜下來，從以下三個方面入手理解程式碼、改善程式碼：

1、程式碼的結構有問題

如果一段網路程式碼突然彈出了自己的對話方塊，應該是UI程式碼需要被處理。這些問題可以被解決掉，你要一次次小心地移動程式碼，重構，改變介面。

還需要一位細心的工程師立馬仔細地檢查這些改變是否有問題，從而不打擾到其他人。事實上，甚至比較大的結構變化也可以不扔掉程式碼來完成。

大牛程式設計師Joel Spolsky回憶說，曾經在某個專案中，他和他的團隊花了好幾個月重新架構在一點上：

把程式碼動來動去、清理、建立有意義的基類，並建立了模組之間的完美介面。但是他們始終非常小心翼翼，並沒有產生新的bug、也沒有丟掉任何舊程式碼。

2、程式碼的效率不高

曾經，Netscape的渲染程式碼被傳非常緩慢。但事實上，這隻會影響該專案的一小部分，這部分是你可以最佳化甚至重寫的。你完全不必重寫全部程式碼。

最佳化速度的1%工作量，會讓你獲得99%的爆炸性提高。

3、程式碼寫得很醜

有些程式碼真的寫的很醜，比如Joel曾參與一個專案，開始用下劃線做開始的成員變數約定，但後來改用更標準的「M_」。

所以一半的功能用「_」開始，一半用「M」開始，這看起來真的很醜陋。但這個問題5分鐘就能解決，而不用從頭開始寫全部的程式碼。

最後，你要記住，從頭開始再寫一遍並不意味著你會寫出比以前更好的程式碼。因為你沒有參與到上一個版本的建立，所以你其實根本就不算有經驗。

一旦你準備推倒重寫，你可能會再犯一遍版本一犯過的錯，甚至會產生更多的新問題。