面對很亂的代碼，你會慢慢看，慢慢改，還是重寫？

回複內容：

是時候祭出這兩張圖啦！ 也許你有很強的編程能力，能駕馭1000行，5000行甚至10000行代碼的重寫，短時間內可以完成，並且bug不多，但是10萬行呢，100萬行呢，甚至數千萬行呢？個人的能力總是有極限的。

團隊的力量呢？2-3個人或許好找，但是去哪裡找50-100個願意去重寫代碼的人，並且還能保證品質呢？

更難的是，到哪裡找到經理或老闆願意等你半年甚至一年不響應需求，不改bug，而是去重寫代碼，去用一套新程式碼完成和老代碼一樣的功能，甚至可能更多的bug。

拋開程式員的完美主義情懷，理性地看待分析舊代碼，問自己幾個問題：
是不是繼續維護的成本真的比重新開發還要高？
是不是新的團隊在設計開發能力上比原有團隊上了一個台階？
是不是有一些硬需求在舊代碼上無論如何都無法做到？
是不是沒有競爭者在窮追不捨而不能停止更新維護？
是不是重寫能提供些殺手級功能壓制競爭者？

分別對舊代碼和新架構做下 SWOT分析，看看優勢，劣勢，機會，威脅都是什麼。

舊代碼或許在架構，介面設計，變數命名和縮排風格上不如人意，但是它是可以工作的，可以工作的代碼意味著解決了很多問題，而這些問題在新重寫的代碼裡並不會因為代碼寫得漂亮就自動得到解決，仍然要把前輩們踩的坑再踩一遍。

那麼是不是就不能重寫代碼呢？不是，要等機會，看緣分的。

個人認為，如果我上面問的五個問題至少三個問題的答案是“是”，SWOT分析的結果裡至少三項是有利於重寫的，那麼可以說也許緣分來了。先看懂，一段很難看的代碼可能是編程水平問題，也可能是為了避開某個坑所做的妥協，要有耐心，不懂就不動。

看明白了，再根據現有需求做決定，設計上有問題，不能滿足需求，那就重寫，不要妥協。需求能滿足，沒嚴重bug，就是代碼亂，那就不要輕易動它，寧可在外邊加個wrapper，把它包起來。從畢業到現在5年時間，接觸公司各種以前的N手代碼（無任何什麼文檔），練就一身閱讀代碼神功，首先大家不要想著怎麼去重寫之前人寫的代碼， 有些看起來不是特別美觀代碼，通常都是各種業務妥協的結果。
重構之前請自己掂量一下時間和自己的能力,沒準下一個程式員就想著怎麼重構你的代碼。

沒想到有一篇文章想法和我一樣《抵制代碼重寫 》

昨天，一位老上級邀請我一起吃午餐。當坐在哪裡等待上菜時，我們緬懷起早期這個公司的往事。他有一句話讓我心裡一虛：

啊，你這個判官…我記得當你看到Dan(公司的第一位程式員)寫的代碼時的樣子。你說：“這代碼寫的真爛，需要重寫！”

我恐怕是沒有足夠的勇氣告訴他，我這“代碼需要重寫”的主張是錯誤的。不錯，我認為這代碼寫的很亂。但是，據過去曆次的經驗，我感覺大部分的程式員看著別人寫的程式時都會想：這代碼寫的真爛。事實上，當一個程式員數年後再看自己寫過的程式時也會想：這代碼寫的真爛。也許他們想的是對的；這代碼確實很爛。

但是，如果你認為代碼需要重寫，你將犯下一個低級錯誤。

公司裡有一些想當然的看法會讓你可能現在不能認識到這點。大量的不成文的想當然的觀點可能會讓你無法解釋清楚。

我喜歡Joel Spolsky說的關於這種事情的話，有些事情你永遠不要去做：

我們是程式員。程式員，在他們自己的心裡，是建築師，當他們來到一個地點，第一件想要做的事情就是：把這地方推平，蓋上輝煌的建築。他們對慢慢的修繕沒有興趣：小修小補，改善，培植花草。

有一種不可捉摸的原因讓程式員們總是希望丟掉這些代碼、重新再寫。原因是他們認為老的代碼是混亂的。可是，你會觀察到一種非常有趣的現象：他們的判斷通常是錯的。他們之所以會認為老的代碼很爛的原因來自於一個重要的、基本的編程定律：

讀代碼比寫代碼要難。

這就是為什麼代碼很難重用的原因。這就是為什麼每個團隊喜歡用自己不同的函數來做把字串拆分成數組操作的原因。他們要寫自己的方法，這更容易，更有趣，不需要弄清楚老的函數的工作原理。

根據這種定律必然得出這樣的一個結論，你現在可以問一問任何一個程式員，問他們對正在寫的程式感覺如何。“亂的不能再亂了，”他們會這樣告訴你。“我寧願把它們都刪了重新再寫。”

當你招募來了一個程式員，如果他想重寫看來工作的不錯的程式，你要抵制。他也許會說Java過時了，太慢，Ruby on Rails如何的酷。也許他會向你拋了一大堆專業名稱術語。不管他如何做，你要三思而行。

你覺得呢？

1. 為什麼千萬不要重寫代碼？
2. 抵制代碼重寫

上上周改了一個500行左右的小代碼，C語言，全都塞在一個檔案裡，一堆全域變數，代碼重複一大堆（之前那個人不會用sprintf，一份自己實現的atoi複製了三份），功能互相交織，變數名各種一個字母的

然後我給拆成了7個分管不同功能的原始碼，有的函數直接重寫，改變數名，根據全域變數的範圍調範圍，最後都改成了static的檔案範圍，加提供者，順便中途還被傻x編譯器坑了一個多小時

然後發現還不如我自己重新寫一個重寫或者辭職。。慢慢改，一塊一塊慢慢重寫，最終整個重寫掉了。重寫一般是立刻重寫，然後一堆bug，解決完發現又是一坨需要重寫的爛代碼，然後突然明白了它為什麼一開始這麼爛一般來說是重寫。看下輸入輸出，大概就明白是幹嘛的了，人家寫了100行，覺得自己90行搞定就不管了，覺得30行能搞定，果斷注釋掉重寫

