《重構，改善既有代碼的設計》讀書筆記

重構，絕對是寫程序過程當中最重要的事之一。在寫程序以前咱們不可能事先了解全部的需求，設計確定會有考慮不周的地方，並且隨着項目需求的修改，也有可能原來的設計已經被改得面目全非了。更況且，咱們不多有機會從頭至尾完成一個項目，基本上都是接手別人的代碼，即便這個項目是從頭參與的，也有可能接手其餘組員的代碼。咱們都有過這樣的經驗，看到別人的代碼時感受就像屎同樣，有一種強烈的想重寫的衝動，但必定要壓制住這種衝動，你徹底重寫，可能比原來的好一點，但浪費時間不說，還有可能引入原來不存在的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天重構系列。

重構列表：

要點列表：

代碼壞味：