如何在一份垃圾代碼上修改出優秀代碼？

12-29

垃圾到如何程度？Major case 都走不通？一開就 crash？那還叫一份代碼嗎？

Major case 走的像模像樣？那就是一份寶。只有走通了 major case 的代碼才能越改越好。你見過寫的很漂亮但是沒法 run 的代碼嗎？那叫花架子。這樣的代碼只能往裡面加無數 debug，各種嘗試，然後越改越爛。

一開始就很漂亮還能 run major case？我沒見過。

很多系統開始時其實沒那麼爛，只是隨著時間推移，積累大量技術債務，加上開發人員水平參差不齊，最終會變得比較爛。

要償還這種技術債務，首先要看是哪種層次上的問題。

如果是設計上的問題，只能推倒重做。

如果設計還算合理，只是細節做的不好。把自動測試用例寫全，然後重構。

重構時不要一次改太多，要小步多次。步子太大容易扯到蛋。

以上。

重構自己的代碼叫重構，重構別人的代碼叫重寫

重寫吧

建議看一下《重構》這本著作

不存在的！

代碼在推倒重來之前只會越來越爛。只有靠嚴格的規範、監察和程序員的自我修養無限減緩其腐爛的速度。

從事實上看，如果代碼可以越改越好，為什麼世界上會有那麼多越來越爛的項目嘛。

一句"歷史遺留問題"蘊含了多少心酸無奈。

唯二的解決辦法：整個推倒重來，分階段地推倒重來

重寫。

垃圾代碼仍然在用，說明它很好的滿足了需求，按照需求重來一遍，再針對缺陷做一些改進，就很優秀了。

如果基本功能都不通

目前也不使用

時間也寬裕

那就推翻根據需求重來

否則的話從簡單功能開始梳理把調用鏈上的代碼摘出來整理好

一個個功能來最終完成重構

代碼跑起來賺錢才是第一要務，然後在自己能力下讓它們變得好看，加更多注釋優化規範，加更多用例，打磨久了就是好代碼。

推到重來就能寫出好代碼？推倒100次也沒有用，方向不知道那麼最好就別動，維護bug就好，代碼最重要的是能跑…

想多了！

改垃圾代碼讓它能夠高效穩定運行所花費的時間，我能用不同的姿勢從零開始寫三遍高效穩定的代碼！！！

寫一份更垃圾的代碼，這樣原來的代碼看起來就比較優秀了

PS：

在垃圾代碼上修改出優秀代碼不現實，到一定的程度後重構還不如重做

我就想問問上面一堆回答重寫重構的，你們真的有這樣的經歷嗎？

通常重寫之後，就會陷入一種矛盾！

那麼爛的代碼，跑起來居然沒有bug，重寫之後，居然有bug，那是不是自己連垃圾都不如？？？

ctrl+a del

優秀代碼？

不存在的。。。

大多情況下，你的工作就是在這種上古項目中加功能，然後維護他......

一開始信心滿滿，寫著寫著心態爆炸，最後放棄治療，自己也瞎『j』『b』寫了。

好代碼都是不斷重構才出來的，垃圾代碼...直接重寫吧。

我一般選擇刪了重寫

所以這就是你malt項目寫了十幾次的原因么（逃

垃圾代碼也要分情況，完全垃圾不能運行或不能大道需求的重寫，結果會很好。但是垃圾代碼卻能跑起來，完全不知道怎麼改，改了還要承擔功能不完全的責任，還是沒法改

首先要分析這代碼有如何垃圾，是否值得修改，如果不值得花時間耗精力去修改它，那即使改出優秀的又能怎樣。

世上無難事只怕有心人，加油吧！

很多時候重寫更省心

修改嗎？別逗我了，重寫要快的多。修改造先讀懂他怎麼想的，然後再想怎麼改，重寫只要想明白怎麼寫就夠了。少年別浪費精力了。 @孫明琦童鞋說的很對，重構自己的代碼才能叫重構，別人的就算了