0. 值得清理么？

第一件你需要問問自己的事情就是代碼值得清理么。我不是說當問到是否要清理代碼時，你一定要回答是或者一定回答不是。是你對代碼負有責任，也是你需要一直面對它們直到最終寫出的代碼是你樂意維護的，也是你很自豪的放入代碼庫的。

如果你覺得就算代碼看起來很可怕，也不值得浪費你本來就很緊張的時間來修復它們。所以你僅僅做了最最微小的調整解救燃眉之急。

換句話說，你也可以將代碼看作自己的，也可以看作是別人的。

兩種情況都有優缺點。優秀的程序員看到爛代碼時會覺得很難受。他們會拿出火把和叉子并且高呼：“太亂了，太亂了”。這是一種優秀的品質。

但是清理代碼是一個繁雜的工作。很容易就低估了時間。甚至有時候和從頭開始寫代碼一樣的耗時。并且短期并沒有帶來任何的短期效應。兩個星期的時間清理代碼并不會帶來任何新的功能，但有可能引入一些新的錯誤。

另一方面，如果長時間不清理代碼可能會帶來災難性的毀滅?；靵y是代碼的殺手。

所以，這并不是一個容易做出的決定。需要考慮一些事情：

● 你期望對這段代碼做多少改變？你是希望僅僅修改這個小錯誤呢，還是這段代碼還要使用多次，所以你希望將它“調教”的好些，并且加上新的功能。如果僅僅是修復一個錯誤，那么最好是別打草驚蛇。然而，如果這個模塊你需要長期折騰的話，那么現在開始花點時間來清理它吧，之后會省掉很多煩惱。

● 你需要或者是你想引入上游的更新嗎？它是一個正在開發當中的開源項目嗎？如果是的話，并且你想做改變的是上游的代碼，那么你不能對代碼有大的改動否則當你每次pull代碼的時候都會經歷一場merge的噩夢。所以你需要做一個友好的團隊合作者，接受這個錯誤，將帶有你修正的代碼補丁發給代碼的維護者。

● 要做多少工作？你一天內實際上能清理多少行代碼？我們估計多于100行，少于1000行，好，我們假設是1000行。所以如果一個模塊有30,000行代碼的話，你可能需要一個月的時間。你有那么多時間嗎?值得這么做么？

● 它是你核心的功能嗎？如果這個模塊只是邊緣的模塊，譬如字體渲染或者圖像渲染，你可能并不在意它是否是亂七八糟的。你可能全盤不要，將來用另外的東西來代替，誰知道呢。如果這段代碼關乎核心的性能，你需要慎重對待。

● 這段代碼有多糟糕？如果代碼僅僅有一點點糟糕，那么可能你還是可以忍受的。如果它是不可理喻的，令人崩潰的話，那么我們就必須對它下手了。

1. 建立測試用例

要認真清理一段代碼意味著花一段時間來徹底清理它。你可能會毀壞它們。

如果你有一個比較好的測試用例，有一定的覆蓋率，你將會很容易知道什么已經損壞了，并且你能夠很快的知道你犯了什么愚蠢的錯誤。想要節省建立測試用例的時間在整個的清理代碼的過程中是可笑的。建立測試用例吧。這是你第一件需要做的事情。

單元測試是最好的，但是所有的代碼并不適應單元測試。如果單元測試過于繁瑣，就換用集成測試吧。譬如，一個游戲關卡中需要一個人物完成一系列的動作和你清理的代碼有關。

這樣的測試更加耗時，所以不可能在每一次更改之后都測試一次，雖然這是最理想的情況。因為你將每一次改變都放到了版本控制系統中，所以情況還不是那么糟糕。所以每一段時間（比如，五個更改）就測試一次。當你發現了一個問題時，你可以通過二進制搜尋最近的幾次commit中找到什么地方導致了問題的發生。

如果你發現了測試沒有發現的問題，確保將這個也加入到測試中，以便將來可以測試它。

2. 使用代碼版本控制系統

還有人需要被告知要使用代碼版本控制系統嗎？我希望沒有。

清理工作是很關鍵的。你可能要做很多很多小的修改。如果什么地方出錯了，你想回顧版本歷史，你可能找到它錯在哪。

如果你和我一樣，你可能有時重構（清理愚蠢的類）的時候會出錯，并且后來意識到這并不是個好的點子，或者這是個好點子，但是如果先做了什么之后所有的一切會變得更簡單。所以你想快速的恢復一切到原狀并且重新開始。

你的公司應該已經有代碼控制系統了，你可以在不同的分支進行修改，在不打擾別人的情況下隨意的commit。

就算情況不是這樣的，你也應該使用版本控制。下載Mercurial(或Git)，創建新的倉庫，將代碼從你們公司的愚蠢的系統中簽出并放在這里。在庫中commit你的更改。當你完成了之后你可以將所有的一切merge到那愚蠢的系統中。

拷貝庫到一個代碼控制系統中僅僅需要幾分鐘。很值得這么做。如果你不懂Mercurial，花一個小時學習它。你會為你這么做感到高興的。如果你愿意的話，花30個小時學習下Git(我是開玩笑的！并不用這么久?，F在是“nerd”戰斗的時候了！)

3. 每次僅僅做一個小小的改動

有兩種方法改進壞的代碼：革命和改革。革命是用火把一切都燒掉，從新寫一遍。改革是在不破壞的基礎上每次只進行一點小小的改變。

這篇文章是關于改革的方法。我不是說革命的方法從來不是必要的。有時代碼太糟糕了，需要用革命的方法。但是那些覺得改革的進度太慢的人們往往會鼓勵改革，然而經常沒有意識到問題的復雜性，并最終并沒有比現存的系統更好。

Joel Spolsky寫過一篇經典的文章，他沒有掉入到這個緊張的爭論的陷阱中。

改革的最好的方法就是一次只做一個小的改變，測試它，并且commit它。當一個改變很小時，它更容易理解改動的后果以及確保改動不會影響現有的功能。如果什么地方出錯了，你僅僅需要核查很少的一部分代碼。

如果你開始做更改并且意識到改得很糟糕，那么你恢復到上一次的commit，不會損失太多的無用功。如果你過了一段時間才發現什么地方有細微的差錯，你可以在版本歷史中使用二進制搜找到導致問題的更改。

最常見的錯誤就是一次進行多處更改。譬如，當去除不必要的類層次的勢后，你發現API的方法并不是像你喜歡的使用方法，而你打算重新組織它們。不要這么做！先去除層次結構，commit之后再更改API。

聰明的程序員懂得組織，所以他們也不需要太聰明。

試著找一個途徑，沿著這個途徑你可以把代碼變成你想要的模樣，每次只有一點點改動。譬如，第一步你重命名方法，使之名字更合理。下一步，你可以將成員變量變成方法的參數。然后將算法變得更清楚些，等等。

如果你開始做更改，并且發現比你原先設想的改變要大，不要害怕又退回去，使用更小的更簡單的步驟去完成同樣的事情.。

4. 不要同時清理代碼和修正代碼

這是(3)的結果，但是仍然很重要。

這是一個常見的問題。你開始察看一個模塊，是因為你想加入某個新功能。然后你發現這個代碼相當的糟糕，所以你開始重新組織它并且加入新的功能。

問題在于清理代碼和修正錯誤是完全不同的目標。當你清理的勢后，你想讓代碼看起來更好，而沒有改變它的功能。當你修正錯誤時， 你想改變功能。如果你同時清理代碼和改正錯誤，很難保證清理不會改變什么。

先清理代碼，然后再在一個干凈的基礎上，加入新的功能。

1. 刪除你沒有使用的功能

清理的時間正比于代碼的數量，復雜性和糟糕的程度。

如果代碼的功能你目前沒有使用，而且在可預見的將來也不會使用，那么就刪除它，這會減少你瀏覽的代碼數，降低復雜度（刪除不必要的概念和依賴）。你會清理的更快的，而且最后的結果會更簡單。

不要留著代碼僅僅因為“誰知道呢，你可能某一天需要它”。代碼是有代價的 – 它需要被移植，修正錯誤，被閱讀以及被理解。你有更少的代碼，就更好。就算在最不可能的情況下，你需要這個舊代碼，你也能從代碼庫中找到它。

6. 刪除大部分的注釋

爛代碼很少會有好的注釋。它們通常是這樣的：

// Pointless: 
 
    // Set x to 3 
 
    x = 3; 
 
// Incomprehensible: 
 
    // Fix for CB (aug) 
 
    pos += vector3(0, -0.007, 0); 
 
// Sowing fear and doubt: 
 
    // Really we shouldn't be doing this 
 
    t = get_latest_time(); 
 
// Downright lying: 
 
    // p cannot be NULL here 
 
    p->set_speed(0.7);