重構代碼的7個階段

第一階段 – 絕望

在你開始去查看你想要重構的模塊的，你會覺得好像很簡單，這里需要改一個類，那里需要改兩到三個函數，重寫幾個函數，看上去沒什么大不了的，一兩天就搞定 了。于是你著手開始重構，然后當你調整重構了一些代碼，比如改了一些命名，修理了一些邏輯，漸漸地，你會發現這個怪物原來體型這么大，你會看到與代碼不符 甚至含糊不清的注釋，完全摸不著頭腦的數據結構，還有一些看似不需要方法被調了幾次，你還會發現無法搞清一個函數調用鏈上的邏輯。你感到這個事可能一周都 搞不定，你開始絕望了。

第二階段 – 找最簡單的做

你承認你要重構的這個模塊就是一個可怕的怪物，不是一兩下就可以搞定的，于是你開始著干一些簡單的事，比如重新命名一下幾個函數，移除一些代碼的阻礙，產生幾個常量來消除magic number，等等，你知道這樣做至少不會讓代碼變得更糟糕。

第三階段 – 再次絕望

但是接下來的事會讓你再次撞墻。你會發現那些代碼的瑕疵是些不痛不癢的事，改正這些事完全于事無補，你應該要做的事就是重寫所有的東西。但是你卻沒有時間 這么干，而這些代碼剪不亂理還亂，耦合得太多，讓你再一次絕望。所以，你只能部分重寫那些不會花太多時間的部分，這樣至少可以讓這些老的代碼能被更多的重 用。雖然不完美，但是至少可以試試。

第四階段 – 開始樂觀

在你重構這個模塊幾天之后，不斷的重構了幾次，雖然你發現改善代碼的進度太慢了，但此時，你已知道代碼應該要被改成什么樣，你在痛苦之后也鎖定了那些那修改的類。是的，雖然你的時間預算已經超支，雖然要干的事比較多，但你還是充滿希望，覺得那是值得的。

第五階段 – 快速了結

這個時候，你知道你花了太多的時間，你感到你所面對的情況越來越讓你越到不安，你明白你自己已經陷入了困境。你原本以為只需要一次簡單的重構，然而現在你 要面對的是重寫所有的東西。你開始意識到原因是因為你是一個完美主義者，你想讓代碼變得完美。于是你開始在怠慢你文檔，并到到一個捷徑來重寫老的代碼，你 開始采用一些簡單而粗暴，快速而有點骯臟的方法。雖然不是很完美，但你就是這樣去做了。然后，你開始運行測試做UT，發現UT報告上全是紅色，幾乎全都失 敗了，你恐慌了，于是快速地fix代碼，然后讓UT 能工作。此時，你拍拍自己胸口，說到，沒問題 ，于是就反代碼提交了。

第六階段 – 修改大量的Bug

你的重寫并不完美，雖然其過了測試，但是那些測試對于你的新的代碼有點不太合適，雖然他們都沒有報錯，但是他們測試得范圍太小了，沒有覆蓋到所有的情況和 邊界。所以，在這以后，你還需要幾周的時間不得不來修改越來越多的bug，這使得你的設計在每一次quick-fix后就變得越來越難看。此時，代碼已經 不像你所期望的那樣完美了，但你依然覺得他還是比一開始要好一些。這個階段可能歷經幾個月。

第七階段 – 覺悟

經過了6個月，你重寫的模塊又出了一個比較嚴重的bug。這讓你重構的那個模塊變得更難堪。你發現出的這個問題是和當初的設計不一致，你還發現被你重構掉 的那段老的代碼并不是當初看上去的那么壞，那段老的代碼確實考慮到了一些你未曾考慮到的事情。這個時候，你團隊里有人站出來說這個模塊應該被重構或是重 寫，而你卻不動聲色地一言不發，并希望那個站出來的人能在幾個月后能覺悟起來。

——————

不知道這是不是你的經歷，我經歷過很多次這樣的事。對于很多維護性質的項目，我幾乎不敢動，那怕看到代碼很不合口味。那些從來沒有寫過代碼的敏捷咨詢師一定會說用TDD或是UT可以讓你的重構更有效也更容易，但我想告訴你，這種脫離實際的說法很不負責任，這就好比說——我在殺豬的時候遇到了一些麻煩，因為我對豬的生理結構不清楚，或是這本來就是一頭畸形的豬，導致我殺的豬很難看，而偉大的敏捷咨詢師卻告訴我，要用一把更快更漂亮的刀 。軟件開發永遠不是那么簡單的事，殺豬也一樣。