實戰遺留代碼

什么是遺留代碼？沒有自動化測試的代碼就是遺留代碼，不管它是十年前寫的，還是昨天寫的。

關于遺留代碼，《修改代碼的藝術》迄今為止依然是在具體手法上講得最好的一本書。

不過，這本書上來就直奔代碼，還有一些東西是技法之外的。

搭建基礎設施

做軟件，沒有自動化，基本上都算刀耕火織。關于基礎設施，我曾寫過一篇很長的文章，以我實際的一個項目為例，介紹了一些設施的基本樣子。

那篇文章很長，具體到面對遺留代碼，有哪些特別之處呢？

我們的目標是給沒有測試的遺留系統增加代碼，那么，那么增加代碼覆蓋率檢查是一個不錯的選擇，各種語言都有自己的測試覆蓋率方案。與單純使用測試覆蓋率不同的是，我們需要保證測試覆蓋率只能提升，不能降低。所以，這里可能會略有一些開發的工作量。

此外，遺留代碼的質量往往不高，除了測試覆蓋率工具，我們還可以引入各種代碼檢查工具，同時，采用同上面類似的做法，保證各種錯誤只能減少，不能增加。

這里的基本想法很簡單，不要在廢墟上繼續破壞。

補測試

理想中，我們要為所有代碼補上測試，但是，這種想法不現實，很簡單，欠賬太多。

一個更為實際的做法是，任務驅動。根據要解決的問題，先把周邊代碼清理干凈，然后再實現新需求。

動手清理之前，我們要先補寫驗收測試，這樣做主要是為了保證我們不會產生大規模的破壞。對于比較復雜的場景，要補的測試可能會比較多，但請記住，這是欠賬，昨日的帳，今天補當然會很痛苦。

補完驗收測試，就該補單元測試了，補單元測試的做法有幾種，無論哪種做法，我們都要先理解一下要動到的代碼。

如果面對的函數比較小，理解起來比較容易，我們就可以直接為它補充單元測試。如果函數比較大怎么辦呢？一次看懂所有的邏輯幾乎就是一項不可能完成的任務，但通常，即便不能理解所有的代碼，但至少我們可以理解一個片段。我們能做的就是把這個可以理解的片段提取到一個單獨的函數里，然后，測試這個單獨的片段。

在具體操作的層面上，經常出現的問題是，我們理解了這段丑陋的代碼，腦子里常會不經意閃過這段代碼未來的樣子，所以，一動手就直奔目標樣子而去，請停下來。先把這段完整的復制到待測函數里，然后給它寫測試，測試通過之后再說重構的事。請記住，步子大了，容易扯到蛋。

這個片段函數做完之后，我們再回到原來的函數里，在原來片段的地方，調用這個新函數。然后，再繼續理解，繼續分解，繼續補測試，繼續重構，繼續替換原有調用。如此N番，你會發現，那個復雜的大函數也不像原來那樣不可理喻了，這時候，如果還需要，對這個函數，我們也可以如法炮制。

添加新代碼

所有一切準備就緒，才是添加新代碼的時機。

或許，這種做法會讓曾經在開發中健步如飛的你有一種舉步維艱的感覺，但請記住，曾經的健步如飛是你的錯覺，因為當初的你并沒有完成你該做的事情，那是欠賬。

出來混，遲早要還的。