如果你在開發一個新項目的時候，看到一段有問題的代碼，可能心里會想，“這是別人寫的，跟我沒關系”，“我沒有義務去改它——我自己的事情還忙不過來呢”，“如果我把它改好了，有可能會改出問題”。

　　如果每個人有這樣的想法的話，那么有問題的代碼會越積越多。即使是很小的一段程序，經過長時間的累計，問題也會漸漸的凸顯出來。有人曾說，超過6個月的項目全是“歷史遺留”項目，因為里面都會積累大量的有問題的代碼，或用另外一個詞——技術債務。

　　所以當你看到一些代碼有問題，或一些不是好的寫法的東西——請馬上改掉它。做事應該寧早勿晚，當你再次注意到它時也許就已經太晚了，很有可能其它的代碼就有一部分開始依賴它，新的代碼會模仿這種編寫風格(也許是拷貝/粘貼而來)，如果真的是這樣的話，那一旦項目出了問題，想要修改的話，就需要花費更多的時間了。讓我們把上面錯誤的做法糾正：

“不要修改別人的代碼”——通常情況下不要修改別人的代碼，如果你發現別人寫的代碼有問題，可以去跟原作者溝通，如果原作者已經離職了的話，那么，建議是你親自去修改他。

“我沒有時間去修改它——我有自己的事要做”——這就是你的事。你可以在你的缺陷跟蹤里添加上一條任務，寫上“重構”，寫上花費的時間。你也可以把它推遲到下一個sprint(如果是敏捷開發)。管理層堅持認為開發新東西比修改舊程序重要嗎？告訴他們去讀讀《重構》這本書或Spolsky的文章..或本文。(也許不管用，但不妨試一試)

“如果我修改它，肯定會改出問題”——也許。但是，等一下，你們有單元測試用例，不是嗎？還有集成測試，確認測試。如果沒有——先把這些補齊了。這樣你就不用擔心把程序改壞了。

　　代碼審查是避免這樣的代碼很重要的方法。如果提交的代碼都經過了代碼審查，未被察覺的有問題的代碼會大幅度的減少。仍然會有，但會少的多。

　　對于這樣的做法存在的問題是——如何確定一段代碼是有問題、需要改進的？這就需要經驗了，需要你熟悉好的開發方法和模式。對這個問題我不能給出一個秘訣。但你需要在團隊里有一群能明辨是非的程序員。如果沒有——讀一讀《Effective Java》

　　所以——請馬上修改。這會省下你的時間，免去你的頭疼，讓你對這個項目更有自豪感，而不是“這爛項目是一些菜鳥寫的，我只是做了一些輔助的工作。”你不能這樣說——如果項目很爛，你難辭其咎。