學習重構的一些思考

關於散彈式修改 

修改一個地方，引發了不少地方都要修改。

舉例1：

我在代錄頁面添加了一列，而後清空列的功能就收到了影響。添加的一列值不能被清空掉。

1： xml裏面要多返回一列

2： grid初始化裏面要新加入一列

3： grid賦值和取值的地方進行了修改

4： 清空的地方進行了修改

分析：若是要修改一個地方，而且這個地方可能會引發其餘的行爲修改，那麼這些行爲應該定義在一個地方，修改起來比較方便。好比，將這些變化的地方作成一個對象類，每次只修改這個對象類。

每一列的相關屬性和方法，應該定義在一個類中，這裏就是Field類。每次只要修改Field類就行了。

舉例2

每個月付記的條目我進行了修改，代錄第一頁的標籤和文本切換和清空按鈕收到了影響。

分析：獲取每個月復記的條目的邏輯是公用邏輯，可是寫在了多個地方，長度也是寫死的，而且也寫在了多個地方。 程序的公用入口應該只有一個。

好比常量，也應該定義在一個地方。

 

幼稚的數據類

數據類的產生緣由：

受hibernate等框架的影響，java框架中對get和set的應用不少

受到隱藏做用域思想的影響

有的類中某個函數要完成處理，須要的參數有不少，就作了這種數據類

數據類的缺點

未理解面向對象的設計方法

增長了類的數量

舉例1

公用導出中，根據action導出文件的模塊。

我首先根據前臺js傳遞來的導出參數，映射成後臺的屬性，因而我新建了一個類，並生成了get set方法。這個類後來只用來進行了存儲數據的功能。

根據這些參數造成文件的邏輯，應該都放到這個類中來。

 

將數據類有關的行爲轉義到數據類中對我來講，無疑是一個觀念上的轉變。

 

關於爲何要重構，個人想法

在平時的開發中，不多有能進行重構的場合。開發人員對重構的認識有限，沒有認識到重構帶來的好處。時間緊迫，寫代碼加測試模式的超級敏捷開發流程是大流

咱們不得不在不少狀況下維護某些代碼，這些代碼不得不被修改。這些代碼咱們不容易看懂，看懂了發現修改一個地方會引發不少地方要進行修改，須要變化的地方多是分散在軟件的各個角落，每錯過一個地方，均可能會引發嚴重的問題，致使返工。

而後咱們就想，爲何當時設計程序時候沒有更好的設計呢？爲何沒有把變化的東西封裝到一個類中呢？ 由於各類緣由，開發時候的確作不到這點，那維護的過程當中咱們是有精力去作這件事情的，重構了這些代碼，能更便於咱們往後維護。咱們也知道之後將怎麼提升咱們軟件的可讀性和可維護性。

 

有些類只有方法的思考

有一個類，類中有一些方法，類沒有什麼字段，方法很長，方法中有不少參數，能夠將這個方法作成一個對象。

這樣一來，有一種觀念的改變，你不是總在定義方法，你定義了對象。

函數是能夠轉化爲對象的，避免函數參數過長 這也是個思想上的改變

 

關於算法的思考

我開發記帳易軟件時候，作一個用戶選擇記帳方式的頁面，我有一個邏輯，後來出現了不少問題，我發現我把問題想的很複雜，可是以爲這東西應該沒有這麼複雜，後來換掉算法後，發現清晰了不少，BUG也少了不少。

像EXCEL的合併算法，拐角現算法都有優化的控件

若是一個類的功能不多，那就應該把這個類的功能轉義到其餘函數中，這樣就能少維護一些類。

單向關聯與雙向關聯

定義常量  避免常量的值分散在類的各個角落。若是你引用的值能夠經過其餘的入口得到，請修改爲統一入口，避免修改多個地方。

 

關於異常

非受控異常 程序員犯的錯誤  不能夠被捕捉處理，程序強制終止，調用的時候應該檢查的可是沒有檢查。

受控異常  調用的時候，調用者沒有檢查，檢查的責任在咱們負責的部分，咱們應該拋出一個異常，這個異常是能夠被調用者捕捉的，而且調用者能夠選擇發生異常的時候應該怎麼作。

當接口發生改變的收，接口的結構最好不要發生改變，由於調用的地方可能會不少。好比加上了拋出異常處理。

受控不受控這個東西，對我是個新知識。