你們正在開發(fā)一個(gè)新項(xiàng)目，你在一個(gè)地方看到一段有問題的代碼。錯(cuò)誤的處理方式是，“啊，別人寫的，我最好別碰它”，“我沒有時(shí)間去改它——我有自己的事要做”，“如果我修改它，肯定會(huì)改出問題”。

　　問題是——有問題的代碼會(huì)越積越多。即使是很小的一段程序，經(jīng)過一段時(shí)間的累計(jì)，你很快就能看到它成為一個(gè)“由一些菜鳥寫的、沒人愿意去維護(hù)的巨大的歷史遺留項(xiàng)目”。有人曾說，超過6個(gè)月的項(xiàng)目全是“歷史遺留”項(xiàng)目，因?yàn)槔锩娑紩?huì)積累大量的有問題的代碼，或用另外一個(gè)詞——技術(shù)債務(wù)。

　　這就是為什么你要馬上修改它們的原因。當(dāng)你看到一些有問題的代碼，或一些不是好的寫法的東西——改掉它。立即。否則，當(dāng)你再次注意到它時(shí)就已經(jīng)太晚了，因?yàn)槠渌拇a就開始依賴它，新的代碼會(huì)模仿這種編寫風(fēng)格(也許是拷貝/粘貼而來)，修改這些東西將會(huì)變成你的噩夢。讓我們把上面錯(cuò)誤的做法糾正：

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

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

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

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

原文鏈接：http://www.aqee.net/fix-that-code-immediately/

【編輯推薦】

1. 初學(xué)者必看:如何為代碼編寫基本的文檔
2. 程序代碼里的幽默精神
3. 讀書百遍其義自見 好代碼你需要寫兩遍
4. Dart語言慣用語——Dart中特有的代碼味道
5. 自己動(dòng)手開發(fā)最好的代碼編輯器