開車的朋友一定深有體會，駕駛汽車其實就是在不斷矯正汽車行駛方向的一個過程。在整個駕駛過程中，你必須全神貫注地緊盯前方，通過方向盤不斷矯正方向，否則即使行駛在直線路段也可能偏離車道。那些疲勞駕駛的司機，因為進入睡眠狀態，無法再矯正方向，車輛就會越來越偏離航向。這種情況下，即使數秒鐘的小盹，也能造成車毀人亡的嚴重後果。

重構與駕車雖然屬於完全不同的領域，但其道理是相同的。我們在運用重構方法修改程式碼的過程中也是經常會犯錯的（是人就會犯錯）。犯錯就如同偏離了航向一樣，因此我們需要不斷去矯正。既然是矯正，就必須有一個正確的標準，以及判斷是否正確的方法。駕車過程中正確的標準是車輛是否正確行駛在自己的車道上，判斷是否正確的方法則是司機朋友的目測。同樣地，重構過程中正確的標準是我們的軟體是否保持重構前的外部行為，判斷的方法則是測試，不論是手工測試還是自動化測試。

說起來這個道理很簡單，但問題是你不可能隨時都在測試，隨時都在矯正，這是不可能的。因此，我們必須要有一個週期，即間隔多長時間測試並矯正一次。週期越長，出大問題的機率就越大，就如同那個睡著了的司機；週期越短，我們所需要付出的成本就越高，因為每進行一次測試都是需要我們付出成本的。週期的長短是需要我們去不斷權衡的。

然而，與駕車不同，重構的測試周期還要取決於完成一次重構並提交程式碼的週期。因為軟體重構總是這樣一個過程，首先修改一部分程式碼，使程式處於一個錯誤而無法編譯執行的狀態，然後完全其它所有相關程式碼的修改，使程式恢復編譯可執行的狀態。在這個中間狀態中，我們是無法測試的，或者說測試是無意義的。只有當相關程式碼都修改完成，程式恢復到可執行狀態時，測試才變得有意義。每完成這樣一個過程，我們稱之為“完成一次重構”。而完成一次重構所花費的時間，是決定我們測試周期的關鍵因素。

既然如此，我們完成一次重構到底要花費多少時間呢？這聽起來像是在進行數學推導，但其中的道理就是這樣。決定一次重構花費的時間，是由我們的設計決定的。小設計，我們對程式碼的修改量少，我們完成重構的時間就短；大設計，我們對程式碼的修改量大，我們完成重構的時間必然長。完成重構時間長，測試的週期就長，我們發現錯誤的時間就晚，可能給我們造成的損失必然就大。

大布局為什麼我們傷不起？漫長的業務整理，漫長的設計與開發，持續數月之久。在這數月中我們一直都無法評估自己是否正確。當我們辛苦數月之後才被告知我們犯錯了，一切都為時已晚，專案不得不滑入了失敗的深淵。這就是前面那個故事系統改造失敗的根本原因。

我們說，大布局不可以，但大設計同樣不可能。我開始要重構了，我們思考了很多問題，運用了很多重構手法，來完成一次重構。這樣的重構，程式碼修改量必然多，重構週期必然長，出錯的風險就大。因此，我們的重構應當是一個一個的小設計。運用一個重構手法，解決一個問題，完成一次重構，測試通過，再運用一個重構手法，解決另一個問題，完成另一次重構……如此往復，這就是我在前面所說的“小步快跑”的開發模式。

但是一個我必須要澄清的概念就是，判斷是否是大設計的衡量標準並不是程式碼行數。舉一個簡單例子，我們將一段上千行的程式碼從一個函式，原封不動地挪到另一個函式中，而這段程式碼本身改動很小，這屬不屬於大設計呢？顯然不屬於，因為我們真正修改的程式碼量不多。後面我們將看到，重構過程會經常進行這種程式碼的搬移。

小步快跑讓我們每次重構的時候只關注一個問題，運用一個重構手法去解決這一個問題。這樣就使我們每次在修改問題時不會想得太多太遠。但是，小步快跑並不是要我們完全沒有遠期規劃，不是這樣的。你可以有遠期規劃，但這種規劃不要做得太早，過早做出這些規劃往往容易顧此失彼。先工作一段時間，做一些基礎的工作，讓我們對系統的整體有了一個比較全面地認識，然後再規劃，這樣將得到更好的效果。

同時，它要求我們對遠期的規劃不要過細。越近期的計劃越細，越遠期的規劃越粗。一些人之所以急急匆匆地去做細緻的遠期規劃，是因為擔心今天做出來的東西，到了今後發現不對，得改，所以今天多想想，多規劃一些。但問題是，今天規劃的就正確嗎？如果是當然很好，而現實常常是否。不正確的規劃卻常常適得其反，讓我們陷入一種困境，一種既不能解決當前問題，又不得不為錯誤設計埋單的困境之中。因此重構的思想卻完全打破了這種思維習慣。重構不懼怕修改，因為它讓明天的程式碼修改是安全的，而不再是走鋼絲。它認為，今天的任務就是改今天的，即使到了明天會被認為是錯誤的，也是明天再改去。

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