??? 作為C++的程序員，我從大學就開始不間斷的看書，看到如今上班，也始終堅持每天多多少少閱讀技術文章，書看的很多，但很難有一本書，能讓我去反復的翻閱。但唯獨『重構--改善既有代碼的設計』這本書讓我重復看了不下3遍，今天我重新拿起這本書開始了第四遍的閱讀。
??? 我后來仔細想了想為什么我會對這個書如此“迷戀”？忽然之間，我意識到這本書真正意義上給我帶來了工作的改變。不像別的技術書籍，可能你看過之后，你腦子里有個印象，但對于實踐這塊不能立馬就做，所以往往印象不深。而這本重構，在你看完之后，你可以立馬開刀闊斧去進行真正意義上的實踐，而且收獲頗多，樂此不疲。
??? 接下來的日子，我將進行第四次『重構--改善既有代碼的設計』的閱讀，對于這本書，我也有了不一樣的感情在里面。以前對于看書，沒有寫讀書筆記的習慣，希望在這本書給我帶來各種便利的同時，我也能夠為它“做點什么”。呵呵，其實也是給自己加深印象的一種途徑。因為“重構”我感覺目前國內開發者還不是特別熟悉，甚至有些程序員寫了幾年代碼之后都不知道設計模式是什么東西。遇到項目，遇到代碼，往往是想到什么就寫什么。當遇到代碼修改或者增加功能的時候，不會去看擴展性或者兼容性，直接語句一貼就完事。對于這種程序員，我真的希望你可以好好的靜下心來想想，這些年來你代碼能力有沒有實質上的長進。
??? 擁有“代碼潔癖”其實是一種很難能可貴的事情，有時候看到一團糟糕代碼，心里會去想對他進行重構。不要懷疑這樣會不會耽誤自己的效率，重構之后添加功能往往能夠更加如魚得水。
??? 今天寫的是序，為了便于有文有料，還是總結幾個可以直接上手的要點給大家，之后我的出法應該就是針對重構列表中的每一條，都出一篇對應的文章。只有這樣，我才能真正意義上的去重視那些簡單的，和坦然接受那些復雜的重構手法。下面先列舉幾個比較有效的重構原則。作為序篇的總結。
??? 1. 有時候遇到大長段函數，需要進行Extract Method的時候，往往找不到一個比較好的切入點。其實這里有一個小竅門，就是尋找邏輯泥團，那么什么是邏輯泥團？其實很簡單，就是那種有switch,if...else,for,while等循環判斷的邏輯結構。往往提煉這種到單獨的函數可以更加有效。
??? 2. 對于函數自身來說，函數內部的參數命名其實也很重要。有些同學可能會覺得接口的命名似乎比內部實現的參數命名更加重要，但你要知道，這個函數很可能之后還是由你去修改去增加功能。如果沒有一個好的參數命名習慣，你又要重新開始去思考，這個變量是用來干什么的，這個時間就浪費掉了。
??? 3.? 如果函數中使用的參數都不是該類所持有，應該考慮是否要Move Method到別的類去。對于類中函數，如果有函數內部使用的變量跟本類沒有任何關系，那么說白了，這個函數不屬于這個類。那么就將這個函數移到他需要的參數所在的類中去。別以為這個小動作沒什么改變，這其實已經改變了類與類之間的耦合關系。從之前的實現耦合到現在的接口耦合，耦合度直接下降了一個級別，這是有目共睹的。
??? 4. 對于一些臨時變量，如果可以通過函數獲得，那么你就Replace Temp with Query，用函數將他替換，不要擔心性能效率問題，記住28原則，80%的效率問題僅僅掌握在20%的代碼身上。
??? 5. 針對變化，轉移函數。如果一個函數中需要同時用到兩個類以上的變量，那么你需要去觀察，這個函數中這些類中變量，在將來比較容易變化的是哪些。優先將這個函數放到變化類中去。這樣對于類型碼這種，你當然可以利用面向對象的法寶--多態來取代switch語句了。這里還有個小技巧，如果你覺得如果在類的生命周期中可能會改變類型，那你就別對這個類做繼承，你所要做的就是加個間接層，State/Strategy模式。通過委托來進行生命期的行為改變，還記得David Wheeler的名言嗎？----計算機科學中的大多數問題都可以通過增加一層間接性來解決。
??? 結語: 其實個人很喜歡測評界的ZEALER，因為他們的精神就是想到什么就去做，與其思來想去要不要真正來篇讀書筆記，不如狠下心來直接來一篇 『重構--改善既有代碼的設計』讀書筆記----序 ： ）
)
)
