**摘要：**由于最近在做重構的項目，所以對重構又重新進行了一遍學習和整理，對31天重構最早接觸是在2009年10月份，由于當時沒有訂閱[Sean Chambers](http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx)的blog，所以是在國外的社區上閑逛的時候鏈接過去的。記得當時一口氣看完了整個系列并沒有多少感覺，因為這些基本上項目都在使用，只是我們沒有專門把它標示和整理出來，所以也沒有引起多大的重視。現在突然接手這個重構項目，由于團隊成員技術和經驗參差不齊，所以有必要專門整理一個重構的綱要，當然這個系列也非常適合做新系統的代碼規范參考，只要有代碼的地方，這個重構規范就很有價值。周末也不想出去閑逛，因為在剛到這個美麗的城市，沒有親戚或者朋友，所以才能靜下心來兩天時間寫完這個重構參考規范。同時也感受了Windows Live writer寫文章的快感。當然重構的整體架構得另當別論（整體架構在我的這篇文章有專門的講解（[http://www.cnblogs.com/zenghongliang/archive/2010/06/23/1763438.html](http://www.cnblogs.com/zenghongliang/archive/2010/06/archive/2010/06/archive/2010/06/23/1763438.html)）。大的架構設計好了以后，這些重構細節點就成了東風之后的大火，對整個項目也是至關重要。31天重構這個系列和《代碼大全》、《重構：改善既有代碼的設計》比較起來最大的特點就是比較簡單、淺顯易懂。那么我這些文章也都是學習Sean Chambers的31天重構的筆記整理，所以如果大家對這個筆記有任何異議也可以指出，具體也可以通過[http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx](http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx)查看原文。 **概念：**本文中的”引入契約式設計”是指我們應該對應該對輸入和輸出進行驗證，以確保系統不會出現我們所想象不到的異常和得不到我們想要的結果。 **正文：**契約式設計規定方法應該對輸入和輸出進行驗證，這樣你便可以保證你得到的數據是可以工作的，一切都是按預期進行的，如果不是按預期進行，異常或是錯誤就應該被返回，下面我們舉的例子中，我們方法中的參數可能會值為null的情況，在這種情況下由于我們沒有驗證，NullReferenceException異常會報出。另外在方法的結尾處我們也沒有保證會返回一個正確的decimal值給調用方法的對象。 ~~~ using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace LosTechies.DaysOfRefactoring.SampleCode.Day25_DesignByContract { public class CashRegister { public decimal TotalOrder(IEnumerable<Product> products, Customer customer) { decimal orderTotal = products.Sum(product => product.Price); customer.Balance += orderTotal; return orderTotal; } } } ~~~ 對上面的代碼重構是很簡單的，首先我們處理不會有一個null值的customer對象，檢查我們最少會有一個product對象。在返回訂單總和之前先確保我們會返回一個有意義的值。如果上面說的檢查有任何一個失敗，我們就拋出對應的異常，并在異常里說明錯誤的詳細信息，而不是直接拋出NullReferenceException。 ~~~ using System; using System.Collections.Generic; using System.Linq; using System.Text; using Microsoft.Contracts; namespace LosTechies.DaysOfRefactoring.SampleCode.DesignByContract.After { public class CashRegister { public decimal TotalOrder(IEnumerable<Product> products, Customer customer) { if (customer == null) throw new ArgumentNullException("customer", "Customer cannot be null"); if (products.Count() == 0) throw new ArgumentException("Must have at least one product to total", "products"); decimal orderTotal = products.Sum(product => product.Price); customer.Balance += orderTotal; if (orderTotal == 0) throw new ArgumentOutOfRangeException("orderTotal", "Order Total should not be zero"); return orderTotal; } } } ~~~ 上面的代碼中添加了額外的代碼來進行驗證，雖然看起來代碼復雜度增加了，但我認為這是非常值得做的，因為當NullReferenceException發生時去追查異常的詳細信息真是很令人討厭的事情。 **總結：**微軟在處理代碼乃至產品的時候，很喜歡應用此重構，你如果認真看它的代碼庫，認真看一下WCF的設計，就不難發現了。這個重構建議大家經常使用，這會增強整個系統的穩定性和健壯性。