他們總在說重構，不過是重寫(2)

　　檢查要進入重構階段的團隊有沒有寫好對應的單元測試，這些測試是否自動測試。

　　是否為重構的項目新開版本管理庫，如果是，那這不是重構，而是 重寫。

　　最終確認最開始要求添加的需求是否被完成。

　　最后這點看起來有點二，但實際中常常發生，團隊說，我開始重構啦，于是在大汗淋漓的兩周后，團隊只能保證“重構”后的項目勉強運行，項目進入了新階段——bug修復，然后就再也沒人提最初提出的新功能新需求了。

　　對于第一點，我們要理解重構的目標是

　　不改變代碼外在行為的前提下，對代碼進行修改，以改進程序的內部結構。

　　如何保證代碼外在行為沒有改變?就得靠單元測試了，這里將單元測試作為代碼或重構的質量標準，誰也不想一個正在運行的程序，被修改后引入一堆Bug。

　　既然重構講究的是小步修改，每次改完后都要通過單元測試，那么第二點也很好理解了，重建版本庫則意味著大段地搬移代碼，這個過程很難保證代碼質量，得到的很可能是 未經驗證 的代碼。

　　既然重構是一種編程手法，那么實踐中的重構是如何操作的?該如何避免重寫而*優雅地重構*呢?

原文轉自：http://www.jianshu.com/p/bce0fe294655