：筆者根據自己的經驗說明的重構的重要性，以及在實際操作中請謹記小步進行，讓你的每一步都是安全的。
**重構
移動方法重構
ide對於重構的重要性相信不需要再強調。在開發的過程中，隨著**的演進，需求的改變我們必須持續不斷的對既有**進行重構：重新命名（以更精確地反映元素的職責），提取方法（用更具描述性的名字來歸納一段**），提取基類（消除重複，提高抽象層次）等。如果我們只是一味的去開發新的**，而對老**不聞不問，以為只要它能工作就夠了，總有一天我們會在這個上面栽跟頭的，設計會慢慢的走向腐化。
在閱讀martin fowler的《重構》時，幾次都沒有將全書讀完，前面幾章倒是讀的大呼過癮，不過後面的重構目錄讓我心生困惑：重構需要這麼小的步驟麼？連乙個重新命名都需要這麼繁瑣的進行。曾幾時我還小人的想：老馬是不是才思枯竭，沒有什麼寫的了，但又不想出版這麼一本薄薄的冊子，如是故意弄的這麼小步伐，湊篇幅。
不過現在我越來越覺得小步進行的重要性，如果我不能小步的重構一塊**，我甚至都不會去重構它。
在最近的結對程式設計中，經常碰到這樣的場景：
我：這段**太長了，我們重構一下吧
partner：好
我：（滑鼠鍵盤一起上了）
partner:你這樣不對（然後搶過鍵盤）
（實際上我們僅僅是為了想建立乙個新類，然後將這個類裡的一些方法移動到新的類裡，這樣原有類的**就變短了，職責也清晰了，而新類也有很清晰的職責。）
我：（我的做法是，新建乙個類，然後將方法copy過去）
partner：（而搭檔的做法是，新建乙個類newclass，然後在原有類裡宣告乙個這個類的字段newclass，然後將要抽離的方法method的方法體再抽取乙個方法internalmethod，然後將新方法internalmethod移動到newclass中，這樣method方法就變成newclass.internalmethod，而method的呼叫者沒有任何變化，而在這中間的每一步都執行一下單元測試）
原有類：
以下是引用片段：
1: public class oldclass
6: //many other code
7: }
第一步：
以下是引用片段：
1: public class newclass
3:
4: public class oldclass
10: //many other code
11: }
第二步：
以下是引用片段：
1: public class newclass
3:
4: public class oldclass
12: //many other code
13:
14: //使用ide重構工具提取方法
15: public void internalmethod()
18: }
第三步：
以下是引用片段：
1: public class newclass
6: }
7:
8: public class oldclass
16: //many other code
17: }
在經過上面的三步後，移動方法重構就基本完成了，然後再進行一些重新命名等工作，將**重構的更好。
雖然我嘴上沒說，但對這種小步進行的方式卻很不以為然，我覺得這完全是在浪費時間，我們有能力控制重構過程的小混亂，然後讓它恢復秩序。
日子就這麼一天天的過去了，終於有一天，因為大部分人去參加了公司的會議，沒有新的故事可以做了，如是我決定做一下有個模組的重構工作，為了確保萬無一失，我還花了很長時間來繪製重構完成後應該有的類階層次結構圖，然後貼在電腦螢幕旁，然後還做了乙個簡單的計畫，我應該從**入手，怎麼做怎麼做之類的。唯獨我沒有做到的是小步進行，當時只是為了能盡快的達到結構圖的目的，大步進行，我甚至沒有借助ide提供的工具，靠人肉重構（如果你也在使用這種方式，請千萬不要繼續下去了，這是重構大忌）。我不僅忘記了使用ide提供的重構工具，甚至還忘記了分步頻繁提交的準則，實際上我一開始，這次重構之旅注定要失敗。到了下午的時候，我看到測試類裡滿眼的紅色標記（編譯不通過），我都焦頭爛額了，但是我甚至還一錯再錯將單元測試暫時遮蔽，以為我可以在重構完成後再回過頭來修理測試。最後，我在沒有測試的情況下，繼續摸黑前行。最後，好不容易將功能**能編譯通過了，我舒了一口氣，然後敲了幾個命令編譯-部署，去倒了一杯咖啡，我回來的時候重新整理了一下頁面，給了我當頭一擊，乙個刺眼的錯誤頁面展現在眼前。因為我已經走的太遠，我都不知道如何去調查錯誤，這個錯誤是從幾何時引入的。沒辦法，在下班前的一刻我將整天的工作全部rollback。
1、如果我們每一步都很小，我們就能在下次重構之前記住我們上一次幹了啥，重構完成之後，執行測試發現測試未通過，我們就能很容易的定位錯誤，修正錯誤。
2、如果每一步都很小，我們在修改功能**後，我們也能很容易的演進測試，讓測試反應當前的變化，這樣測試就會與功能**共同演進。
3、如果每一步都很小，我們在跑完測試後可以馬上提交**，當我們發現重構發生問題時，我們可以回退到上一步，而不至於像我那樣將整天的工作全部回滾。
4、如果每一步都很小，我們就可以借助ide對重構提供的支援來安全的進行，因為ide對步驟太大的重構支援並不好。
如果你也在重構，請謹記小步進行，讓你的每一步都是安全的。請不要厭煩《重構》中重構目錄的羅嗦，因為那才是重構的精髓所在。
為什麼要進行重構？ 《重構》節選
我不想把重構說成治百病的萬靈丹，它絕對不是所謂的 銀彈 不過它的確很有價值，雖不是一顆銀子彈，卻是一把 銀鉗子 可以幫助你始終良好地控制自己的 重構是個工具，它可以 並且應該 為了以下數個目的而被運用 重構改進軟體設計 如果沒有重構，程式的設計會逐漸腐敗變質。當人們只為短期目的，或是在完全理解整體設...
初步進行JDBC的步驟
1.載入資料庫驅動 class.forname driverclass e.g class.forname com.mysql.jdbc.driver 2.通過drivermanager獲取資料庫連線 drivermanager.getconnection string url,string use...
BN多卡同步進行
為什麼不進行多卡同步?batchnorm的實現都是只考慮了single gpu。也就是說bn使用的均值和標準差是單個gpu算的，相當於縮小了mini batch size。至於為什麼這樣實現，1 因為沒有sync的需求，因為對於大多數vision問題，單gpu上的mini batch已經夠大了，完全...