請修改這段程序，立刻！

本文是從 Fix That Code Immediately! 這篇文章翻譯而來。

你們正在開發一個新項目，你在一個地方看到一段有問題的代碼。錯誤的處理方式是，“啊，別人寫的，我最好別碰它”，“我沒有時間去改它——我有自己的事要做”，“如果我修改它，肯定會改出問題”。

問題是——有問題的代碼會越積越多。即使是很小的一段程序，經過一段時間的累計，你很快就能看到它成為一個“由一些菜鳥寫的、沒人愿意去維護的 巨大的歷史遺留項目”。有人曾說，超過6個月的項目全是“歷史遺留”項目，因為里面都會積累大量的有問題的代碼，或用另外一個詞——技術債務。

這就是為什么你要馬上修改它們的原因。當你看到一些有問題的代碼，或一些不是好的寫法的東西——改掉它。立即。否則，當你再次注意到它時就已經 太晚了，因為其它的代碼就開始依賴它，新的代碼會模仿這種編寫風格(也許是拷貝/粘貼而來)，修改這些東西將會變成你的噩夢。讓我們把上面錯誤的做法糾 正：

• “啊，別人寫的代碼，我最好別動它”——什么？你的項目團隊的一員，你有“權力”去修改它。如果有人把代碼寫的很糟糕，他可能并沒有意識到自己的代碼很爛——所以，他們不會改正它。不要認為改正這些代碼會冒犯他們。他們也許會沒面子，但不是因為你。
• “我沒有時間去修改它——我有自己的事要做”——這就是你的事。你可以在你的缺陷跟蹤里添加上一條任務，寫上“重構X”，寫上花費的時間。你也可以把它推遲到下一個sprint(如果是敏捷開發)。管理層堅持認為開發新東西比修改舊程序重要嗎？告訴他們去讀讀《重構》這本書或Spolsky的文章..或本文。(也許不管用，但不妨試一試)
• “如果我修改它，肯定會改出問題”——也許。但是，等一下，你們有單元測試用例，不是嗎？還有集成測試，確認測試。如果沒有——先把這些補齊了。這樣你就不用擔心把程序改壞了。

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

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

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