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

12-29

是時候祭出這兩張圖啦！

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

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

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

拋開程序員的完美主義情懷，理性地看待分析舊代碼，問自己幾個問題：

是不是繼續維護的成本真的比重新開發還要高？

是不是新的團隊在設計開發能力上比原有團隊上了一個台階？

是不是有一些硬需求在舊代碼上無論如何都無法做到？

是不是沒有競爭對手在窮追不捨而不能停止更新維護？

是不是重寫能提供些殺手級功能壓制競爭對手？

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

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

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

個人認為，如果我上面問的五個問題至少三個問題的答案是「是」，SWOT分析的結果里至少三項是有利於重寫的，那麼可以說也許緣分來了。

慢慢改，一塊一塊慢慢重寫，最終整個重寫掉了。

重寫

從畢業到現在5年時間，接觸公司各種以前的N手代碼（無任何什麼文檔），練就一身閱讀代碼神功，首先大家不要想著怎麼去重寫之前人寫的代碼，有些看起來不是特別美觀代碼，通常都是各種業務妥協的結果。

重構之前請自己掂量一下時間和自己的能力,沒準下一個程序員就想著怎麼重構你的代碼。

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

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

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

我恐怕是沒有足夠的勇氣告訴他，我這「代碼需要重寫」的主張是錯誤的。不錯，我認為這代碼寫的很亂。但是，據過去歷次的經驗，我感覺大部分的程序員
看著別人寫的程序時都會想：這代碼寫的真爛。事實上，當一個程序員數年後再看自己寫過的程序時也會想：這代碼寫的真爛。也許他們想的是對的；這代碼確實很
爛。
但是，如果你認為代碼需要重寫，你將犯下一個低級錯誤。
公司里有一些想當然的看法會讓你可能現在不能認識到這點。大量的不成文的想當然的觀點可能會讓你無法解釋清楚。
我喜歡Joel Spolsky說的關於這種事情的話，有些事情你永遠不要去做：

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

有一種不可捉摸的原因讓程序員們總是希望丟掉這些代碼、重新再寫。原因是他們認為老的代碼是混亂的。可是，你會觀察到一種非常有趣的現象：他們的判斷通常是錯的。他們之所以會認為老的代碼很爛的原因來自於一個重要的、基本的編程定律：
讀代碼比寫代碼要難。
這就是為什麼代碼很難重用的原因。這就是為什麼每個團隊喜歡用自己不同的函數來做把字元串拆分成數組操作的原因。他們要寫自己的方法，這更容易，更有趣，不需要弄清楚老的函數的工作原理。
根據這種定律必然得出這樣的一個結論，你現在可以問一問任何一個程序員，問他們對正在寫的程序感覺如何。「亂的不能再亂了，」他們會這樣告訴你。「我寧願把它們都刪了重新再寫。」

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

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

先看懂，一段很難看的代碼可能是編程水平問題，也可能是為了避開某個坑所做的妥協，要有耐心，不懂就不動。

看明白了，再根據現有需求做決定，設計上有問題，不能滿足需求，那就重寫，不要妥協。需求能滿足，沒嚴重bug，就是代碼亂，那就不要輕易動它，寧可在外邊加個wrapper，把它包起來。

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

然後我給拆成了7個分管不同功能的源代碼，有的函數直接重寫，改變數名，根據全局變數的範圍調作用域，最後都改成了static的文件作用域，加訪問介面，順便中途還被傻x編譯器坑了一個多小時

然後發現還不如我自己重新寫一個

關鍵看這堆代碼是不是可以穩定運行。

魯棒性如何。

如果可以穩定運行，不要去管它。否則，先分解，再重寫。

剛畢業的時候，接手了一個項目，有十幾萬行代碼，大概每運行一小時就崩潰一次。

裡面五百行以上的函數到處都是，還有幾個三千多行的。

於是乎我買了一本代碼大全。

每天閱讀，然後對照著重構，重寫，或者分解。

半年以後，刪掉了幾萬行代碼，穩定性提高到一周崩潰一次。

現在回想起來，那是我工作期間最充實的時光之一。

其實『我』只有兩種選擇，一是快快改，二是快快重寫，工作這麼些年，還沒有哪個業務環境真的允許『我』慢慢改，更別提慢慢看了。慢慢搞就是不搞，這也算行業潛規則吧。

所謂代碼很亂也有千奇百怪的亂法，有時因為前面的碼農偷懶搞混陪女朋友，有時是業務邏輯複雜不清晰，在不清晰的時候產生的代碼架構成了後來的負擔，亂代碼一點點往上堆直到有人受不了了問這個問題『我TM是不是該重寫啊』；後者情況多。

但我還是回答不了你的問題，因為真的要分情況，況且代碼亂永遠不只是代碼亂的問題，審視一下你所在組織的管理情況先

先在心裡咒罵，完了改一點，如果實在生氣就刪了重寫

如果沒有切實的必要性，如BUG很多，無法支持新需求，性能很差。否則不會去動它，也不應該去動它。除非你有很多覆蓋率很足夠的單元測試可以保證你改的任何一個單詞不會引起新的BUG。

if( lines &> 30k )

慢慢看，慢慢改

else

還是重寫吧

很難忍受難看的代碼，如果不是很麻煩的話就重構吧

不知道樓主編碼幾年，每個人都是從爛代碼走過來的，保持學習的每個月都會發現自己代碼的質量有一定提高。換個說法就是每過一個月，你都會發現一個月前寫的代碼多多少少有些問題。

遇到爛代碼，要麼是你自己寫的，要麼是別人留下的。改是必然的，只是要結合實際，如果項目時間不允許，可以在二期或者維護階段重構。

重構代碼是一件工作量很大的事，尤其是在你不明白代碼在做什麼的時候，在你沒搞清楚前，最好別動。因為在你不了解的情況下，重構可能會帶來很多bug。

寫代碼是一件跟藝術的事，美的代碼就是藝術品。

以前是花大整天大整天去調試去跟蹤去理解，現在直接還是重寫吧。

一般來說是重寫。看下輸入輸出，大概就明白是幹嘛的了，人家寫了100行，覺得自己90行搞定就不管了，覺得30行能搞定，果斷注釋掉重寫

如果有人能告訴我這段代碼明確的作用域，我覺得不管是改還是重寫都不是太大的問題。

反之都挺煩人的。

別人的代碼，慢慢改，

感覺這是一種對別人的尊重。

自己的代碼，重寫。

「評審不靠譜的代碼，編輯看不懂的譯稿，實在是痛苦，恨不得自己重寫算了。」

我向XXX大牛抱怨。他冷笑了一下，說，快拉倒吧，遇到街上的丑孩子，你還能把他們的都媽拉過來fuxk一遍，生一次？累死你不說，就你這長相，怎麼確保生再出來的不會更丑？

給錢多就重新寫，不然就改。

因為推倒重寫比改要簡單的多，雖然可能更花費時間。