程序員，你應(yīng)該立馬修改有問題的代碼
你們正在開發(fā)一個新項目，你在一個地方看到一段有問題的代碼。錯誤的處理方式是，“啊，別人寫的，我最好別碰它”，“我沒有時間去改它——我有自己的事要做”，“如果我修改它，肯定會改出問題”。
問題是——有問題的代碼會越積越多。即使是很小的一段程序，經(jīng)過一段時間的累計，你很快就能看到它成為一個“由一些菜鳥寫的、沒人愿意去維護(hù)的巨大的歷史遺留項目”。有人曾說，超過6個月的項目全是“歷史遺留”項目，因為里面都會積累大量的有問題的代碼，或用另外一個詞——技術(shù)債務(wù)。
這就是為什么你要馬上修改它們的原因。當(dāng)你看到一些有問題的代碼，或一些不是好的寫法的東西——改掉它。立即。否則，當(dāng)你再次注意到它時就已經(jīng)太晚了，因為其它的代碼就開始依賴它，新的代碼會模仿這種編寫風(fēng)格(也許是拷貝/粘貼而來)，修改這些東西將會變成你的噩夢。讓我們把上面錯誤的做法糾正：
“啊，別人寫的代碼，我最好別動它”——什么？你的項目團隊的一員，你有“權(quán)力”去修改它。如果有人把代碼寫的很糟糕，他可能并沒有意識到自己的代碼很爛——所以，他們不會改正它。不要認(rèn)為改正這些代碼會冒犯他們。他們也許會沒面子，但不是因為你。“我沒有時間去修改它——我有自己的事要做”——這就是你的事。你可以在你的缺陷跟蹤里添加上一條任務(wù)，寫上“重構(gòu)X”，寫上花費的時間。你也可以把它推遲到下一個sprint(如果是敏捷開發(fā))。管理層堅持認(rèn)為開發(fā)新東西比修改舊程序重要嗎？告訴他們?nèi)プx讀《重構(gòu)》這本書或Spolsky的文章..或本文。(也許不管用，但不妨試一試)“如果我修改它，肯定會改出問題”——也許。但是，等一下，你們有單元測試用例，不是嗎？還有集成測試，確認(rèn)測試。如果沒有——先把這些補齊了。這樣你就不用擔(dān)心把程序改壞了。
代碼審查是避免這樣的代碼很重要的方法。如果提交的代碼都經(jīng)過了代碼審查，未被察覺的有問題的代碼會大幅度的減少。仍然會有，但會少的多。
對于這樣的做法唯一的問題是——如何確定一段代碼是有問題、需要改進(jìn)的？這就需要經(jīng)驗了，需要你熟悉好的開發(fā)方法和模式。對這個問題我不能給出一個秘訣。但你需要在團隊里有一群能明辨是非的程序員。如果沒有——讀一讀《代碼大全(Code Complete)》(以及《Effective Java》，如果你們使用的語言是Java。)
所以——請馬上修改。這會省下你的時間，免去你的頭疼，讓你對這個項目更有自豪感，而不是“這爛項目是一些菜鳥寫的，我只是做了一些輔助的工作。”你不能這樣說——如果項目很爛，你難辭其咎。
原文鏈接：http://www.aqee.net/fix-that-code-immediately/
【編輯推薦】
