重構，絕對是寫程式過程中最重要的事之一。在寫程式之前我們不可能事先了解所有的需求，設計肯定會有考慮不周的地方，而且隨著專案需求的修改，也有可能原來的設計已經被改得面目全非了。更何況，我們很少有機會從頭到尾完成一個專案，基本上都是接手別人的程式碼，即使這個專案是從頭參與的，也有可能接手其他組員的程式碼。我們都有過這樣的經驗，看到別人的程式碼時感覺就像屎一樣，有一種強烈的想重寫的衝動，但一定要壓制住這種衝動，你完全重寫，可能比原來的好一點，但浪費時間不說，還有可能引入原來不存在的Bug，而且，你不一定比原來設計得好，也許原來的設計考慮到了一些你沒考慮到的情況。我們寫的程式碼，終有一天也會被別人接手，很可能到時別人會有和我們現在一樣的衝動。所以，我們要做的是重構，從小範圍的重構開始。
重構不只可以改善既有的設計，還可以幫助我們理解原來很難理解的流程。比如一個複雜的條件表示式，我們可能需要很久才能看明白這個表示式的作用，還可能看了好久終於看明白了，過了沒多長時間又忘了，現在還要從頭看，如果我們把這個表示式運用Extract Method抽象出來，並起一個易於理解的名字，如果函式名字起得好，下次當我們再看到這段程式碼時，不用看邏輯我們就知道這個函式是做什麼的。如果對這個函式內所有難於理解的地方我們做了適當的重構，把每個細小的邏輯抽象成一個小函式並起一個容易理解的名字，當我們看程式碼時就有可能像看註釋一樣，不用再像以前一樣透過看程式碼的實現來猜測這段程式碼到底是做什麼的，好的程式碼勝過註釋，畢竟註釋還是有可能更新不及時的。
《重構，改善既有程式碼的設計》，這是一部經典之作，相信很多人都聽過或看過，看這本書時會發現，書中講的都是一些很簡單的東西，而且很多東西就是我們平時在做的，只是作者把它們總結了起來。比如說Rename Field，就是對不易理解其作用的欄位起一個易於理解的名字，這個肯定我們都做過，但是更多時候，我們是對這種欄位視而不見，比如曾經花了很久沒搞明白程式碼的欄位"IP"是什麼的縮寫，最後發現竟然是“INPUT”。看過這本書的收穫是，讓重構融於整個寫程式碼的過程中，讓重構不再作為一項獨立的任務，而是在寫程式碼的過程中隨時隨地的進行，一個函式不容易理解，重構；新增新功能時很不方便，重構，使新增新功能變得理解。
這本書是用Java寫的，而且Java的版本很老。
書中的一些東西說得太絕對，比如說看到switch就重構，但這是不現實的，比如說Android開發，選單的onOptionsItemSelected，這個肯定是重構不了的；對於很多控制元件的onClickListener，還是統一設定一個Listener並透過ViewID區分方便點，尤其是在Adapter的getView中，針對每個控制元件new一個onClickListener會生成太多物件。當然，不是說這個重構手法無效，而是這個手法提醒我們，當看到這樣的情況時需要認真考慮一下，當前的情況是否需要重構，如果確定不需要，就那樣好了。
但是有些東西還是很值得注意的，比如封裝集合(Encapsulate Collection)，當呼叫者請求一個類的一個集合物件時，我們最好不要返回這個集合物件，而是返回這個集合對像的一個不可修改的副本，並增加新增/移除資料的函式。比如Android開發的Adapter，我們經常會為了方便給Adapter新增返回資料集合與設定資料集合的方法，但這是不安全的，我們不能確定呼叫者獲得這個集合後會做什麼事情，如果呼叫者修改了這個集合的內容我們也對其一無所知，在Android中，如果呼叫者在非UI執行緒獲得了Adapter列表的資料並修改是會出問題的。
重構前，先檢查自己是否有一套可靠的測試機制。這些測試必須有自我檢驗的能力，畢竟重構可能破壞掉一些東西，我們要靠測試幫助我們發現這些問題，不要因為測試無法捕捉所有bug就不寫測試， 因為測試的確可以捕捉到大多數bug。不過，說來慚愧，我很少寫測試，尤其是Android專案。
書中全是一些很簡單的手法，我相信，我們肯定都用過其中的大部分重構手法，只是沒有察覺。這本書只是對其進行了一個總結，並讓我們意識到重構這項技能，並讓重構融入我們整個寫程式的過程中，讓重構無處不在。
書中的一些重構手法，在我感覺可能就不算是重構手法，比如給函式新增引數，如果引數不夠又必須新增，我們肯定會新增的，這算是功能修改還是重構，隨便怎麼理解吧，不過作為筆記，還是把所有這些都記錄下來了。
對這本書的筆記只有三個圖，是對書中所有重構手法列表的一個簡單記錄，方便以後查閱，至於具體操作步驟或例子，以後想看時翻書就行了，或都網上也可以搜到的。下面這個連結是一個C#版本關於重構的系列，但不是這本書的C#版本，其中的手法大都是相同的，聖殿騎士：31天重構系列。
重構列表：
要點列表：
程式碼壞味：
