大話重構連載2：什麼是系統重構

標籤：重構   軟體品質   高品質設計   

當我們開始系統重構的時候，不是著手去修改代碼，而是首先建立測試機制。不論什麼程式，只要是被我們修改了，理論上就可能引入BUG，因此我們就必須要進行測試。既然是測試就必須要有一個正確與否的評判標準。以往的測試，其評判的標準就是是否滿足業務需求。因此，測試人員往往總是拿著需求文檔測試系統。

與以往的代碼修改不同，重構沒有引入任何新的需求，系統原來什麼功能，重構以後還是這些功能。因此，重構的測試標準就只有一個，就是與之前的功能完全保持一致，僅此而已。

然而在許多經典的重構書籍中，大師們總是建議我們首先建立自動化測試機制，這已經被我在無數次實踐中證明是不現實的。要知道我們現在重構的是一個遺留系統，它往往設計混亂，介面不清晰，程式相互依賴。所有這些都使得最初的自動化測試變得非常困難而不切實際。

因此，從一開始就實現自動化測試是不切實際的，我們所能採用的還是手工測試。在重構之前首先將系統啟動起來，執行相應的功能，得到各自相應的輸出。然後開始重構，每次重構對代碼的修改量不要太大，花費的時間不要太長。因為，修改量太大，花費時間太長，一旦測試不通過，很難定位錯誤的原因。在這種情況下，我們只能還原代碼，將此次修改的工作完全作廢。如果此次修改已經花費了你數天甚至數月的時間，這樣的損失就實在太大了。

每做一次重構，修改一點兒代碼，然後提交，對系統進行一次測試。如果系統依然保持與以往一樣的功能，重構成功，繼續進行下一次重構。如果不是，你不得不還原回來重新重構。頻繁地測試著實讓你挺煩的，但卻有效減少了重構失敗帶給你的損失。一個折中的辦法就是，平時頻繁測試的時候，測試專案少一些，只測試主要項目，定期再進行全面地測試。錄製QTP[1]指令碼也是一個不錯的方式，它雖然有諸多問題，但卻可以在系統重構初期有效地建立自動化測試，系統層級的自動化測試。隨著系統重構的不斷深入，我們的程式開始在改善，耦合變得越來越鬆散，程式變得越來越內聚，介面變得越來越清晰。這時候，當自動化測試條件成熟時，我們才可以逐漸開始自動化測試，而這種自動化測試才是建立在代碼層級的真正的自動化測試。

一旦某個修改測試不通過，則還原回來。這種一次一小步的修改模式，我們形象地稱之為“小步快跑”。在測試整合工具的不斷監督下一點一點地修改程式，是系統重構異於以往的另外一個特點。通過小步快跑可以使我們在重構的過程中，以最快的速度發現修改的問題，將因修改錯誤帶來的損失減到最小，畢竟是人都不可能避免犯錯。

[1] QTP，Quicktest Professional的簡稱，是一種自動化的測試工具。使用QTP的目的是想用它來執行重複的手動測試，主要是用於迴歸測試和測試同一軟體的新版本。

大話重構連載首頁：http://blog.csdn.net/mooodo/article/details/32083021

特別說明：希望網友們在轉載本文時，應當註明作者或出處，以示對作者的尊重，謝謝！