大話重構連載4：大布局與小步快跑

標籤：blog   http   問題   html   工作   代碼   

以往我們在重新設計一個系統時，總是喜歡大布局。全面地整理系統需求，全面地分析系統功能，再全面地設計系統、開發、測試。這樣一個過程往往會持續數月，花費大量的工作量。但是，不到最後設計出來，誰都不知道會不會存在問題。這就是“大布局”的弊病。

正因為如此，軟體大師在講述系統重構時總是強調，系統重構應當避免大設計，而應當盡量採用一個一個連續不斷的小設計。這就是我們所說的“小步快跑”的設計模式。

小步快跑體現出了敏捷式軟體開發 (Agile Software Development)的特點——簡單與快速反饋。不要想得太多了，活在今天的格子裡，因為你永遠不可能預知今後會發生什麼。所以，做今天的設計，解決今天的問題，完成今天的重構，讓明天見鬼去吧。要知道，簡單對於我們是多麼的重要。當我們的大腦開始思考各種複雜的問題時，就開始充血，然後就是夢遊，最後的結果就是顧此失彼。既然如此，我們為何不選擇一種更加簡單的生活呢？

非常遺憾的是，很多時候我們不能選擇這種簡單的生活，因為我們害怕明天，害怕明天會出現那些我們處理不了的業務情境，因此我們開始過度設計。我不是批判我們不應當有預見，預見性設計與過度設計往往就是一線之隔。有限的預見是可以的，但不要想得過於遙遠。當明天真的需求變更了，我們現在的設計不能滿足了，怎麼辦呢？沒什麼大不了的，因為我們有重構。通過安全而平穩的重構方法先重構我們的系統，使之可以應付那個需求，然後再添加代碼，實現新需求。這個過程被稱為“兩頂帽子”：一頂是只重構而不新增功能，一頂是增加新的功能實現新需求。正因為如此，我們在設計時思考當下就可以了。

另外一個問題就是及時反饋，落實到此地就是及時測試。只有測試通過了，此次重構才算成功，我們才能繼續往下重構，否則我們必須還原。從這裡我們不難看出，重構的周期是多麼的重要。在我以往的重構工作中，一次重構的周期也就在10分鐘到1小時。重構的周期越長，說明你考慮的問題越複雜，最終出錯的機率也就越大。所以，我們一定要習慣“小步快跑”的工作方式，讓自己只活在當下。

說了那麼多重構，相信一定有一個疑問開始在你腦中縈繞。既然系統重構對於客戶來說是透明的，客戶完全感覺不到它的存在，毫無疑問，它對於客戶來說就是毫無價值的。這下疑問就來了：既然重構對於客戶來說就是毫無價值的，我們做它還有什麼意義呢？要說明白這個問題，我們需要首先談一談軟體修改的四種動機。

大話重構連載首頁：http://www.cnblogs.com/mooodo/p/talkAboutRefactoringHome.html

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