英文原文：Fix That Code Immediately! ，編譯：外刊IT評論
你們正在開發一個新專案，你在一個地方看到一段有問題的程式碼。錯誤的處理方式是，“啊，別人寫的，我最好別碰它”，“我沒有時間去改它——我有自己的事要做”，“如果我修改它，肯定會改出問題”。
問題是——有問題的程式碼會越積越多。即使是很小的一段程式，經過一段時間的累積，你很快就能看到它成為一個“由一些菜鳥寫的、沒人願意去維護的 巨大的歷史遺留專案”。有人曾說，超過6個月的專案全是“歷史遺留”專案，因為裡面都會積累大量的有問題的程式碼，或用另外一個詞——技術債務。
這就是為什麼你要馬上修改它們的原因。當你看到一些有問題的程式碼，或一些不是好的寫法的東西——改掉它。立即。否則，當你再次注意到它時就已經 太晚了，因為其它的程式碼就開始依賴它，新的程式碼會模仿這種編寫風格(也許是拷貝/貼上而來)，修改這些東西將會變成你的噩夢。讓我們把上面錯誤的做法糾 正：
▲ “啊，別人寫的程式碼，我最好別動它”——什麼？你的專案團隊的一員，你有“權力”去修改它。如果有人把程式碼寫的很糟糕，他可能並沒有意識到自己的程式碼很爛——所以，他們不會改正它。不要認為改正這些程式碼會冒犯他們。他們也許會沒面子，但不是因為你。
▲ “我沒有時間去修改它——我有自己的事要做”——這就是你的事。你可以在你的缺陷跟蹤裡新增上一條任務，寫上“重構X”，寫上花費的時間。你也可以把它推遲到下一個sprint(如果是敏捷開發)。管理層堅持認為開發新東西比修改舊程式重要嗎？告訴他們去讀讀《重構》這本書或Spolsky的文章..或本文。(也許不管用，但不妨試一試)
▲ “如果我修改它，肯定會改出問題”——也許。但是，等一下，你們有單元測試用例，不是嗎？還有整合測試，確認測試。如果沒有——先把這些補齊了。這樣你就不用擔心把程式改壞了
程式碼審查是避免這樣的程式碼很重要的方法。如果提交的程式碼都經過了程式碼審查，未被察覺的有問題的程式碼會大幅度的減少。仍然會有，但會少的多。
對於這樣的做法唯一的問題是——如何確定一段程式碼是有問題、需要改進的？這就需要經驗了，需要你熟悉好的開發方法和模式。對這個問題我不能給出一個祕訣。但你需要在團隊裡有一群能明辨是非的程式設計師。如果沒有——讀一讀《程式碼大全(Code Complete)》(以及《Effective Java》，如果你們使用的語言是Java。)
所以——請馬上修改。這會省下你的時間，免去你的頭疼，讓你對這個專案更有自豪感，而不是“這爛專案是一些菜鳥寫的，我只是做了一些輔助的工作。”你不能這樣說——如果專案很爛，你難辭其咎。