引數過長
影響：
方法不易被理解、使用，方法簽名容易不穩定，不易維護
解決方法：反復使用提煉方法+行內方法，消除多余引數
? 盡量把方法移進相關的類中
? 如物體類中的get方法在其他類中沒有被呼叫可以洗掉
? 實際作業中，可以結合引數數量、以及自身對業務的理解，在 最小知道 和 保持物件完整性 之間進行權衡
全域變數
影響：可以在任何位置進行修改，在使用程序中可能出現意想不到的值，并且沒有任何機制可以探測出哪段代碼進行了修改，導致定位困難
改進目標：
降低代碼耦合性，保持代碼清晰，維護簡單，降低由于對全域資料隨意的改變引發bug的風險
方法：封裝變數，提煉函式
使用Convert To Instance Method替換專案中使用靜態方法的地方，進行重構
如果想避免其他類中參考本類的欄位，修飾符改為private
可變資料
影響：
影響可維護性，在一處修改資料，卻在另一處造成難以發現的破壞
改進目標：
應用“資料不可變”：不可變性是強大的代碼防腐劑
方法：
封裝變數、拆分變數、提煉函式、移除設值，函式、查詢取代派生、Builder模式創建不可變物件、參考物件改為值物件、函式式編程等
發散式變化
定義：
某個模塊經常因為不同的原因在不同的方向上發生變化
影響：
通常，發散式變化是由于多個變化方向之間有較多的來回呼叫或者函式內部混合了多類處理邏輯，當處于多個不同背景關系的外部行為發生變化時候，都會引起對同一個類或模塊的修改，影響了代碼的可讀和可維護性
改進目標：
提高代碼組織結構、職責單一提升代碼可讀性、可維護性
方法：
拆分階段
搬移函式
提煉函式
提煉類
霰彈式修改
定義：
霰彈式修改：指的是如果每遇到某種變化，你都必須在許多不同的類內做出許多小修改，此時，你所面臨的壞味道就是霰彈式修改
影響：
修改的地方四面散布，而且有可能修改之后導致其他例外結果
改進目標：
更好的代碼組織，更少的代碼重復
方法：
搬移函式、搬移欄位、函陣列合成類、函陣列合成變換、拆分階段、行內函式、行內類
clone的應用
這里之所以使用 clone，是因為在跨邊界呼叫場景下，直接更改原物件會有一定風險，
比如某些場景下，邊界外更改物件可能改變邊界內狀態，或者呼叫方想維護多個狀態時可能引發混亂，
因此一般涉及狀態資訊更新時，盡量不直接處理同一物件（使用clone），或不暴露完整物件（回傳部分需要的屬性），
如果需要內部維護物件狀態，又需要將完整物件暴露出去，就回傳一個副本（比如當前案例，如果 clonePaySlip 需要在內部快取，那么回傳值應當進一步優化為：clonePaySlip.clone()）
依戀情節
定義：
依戀情節/特性依戀:一個函式跟另一個模塊中的函式或資料交流格外頻繁，遠勝于在自己所處模塊內部的交流
影響：
可讀性、可維護性低：呼叫另一模塊功能時往往需要打一套組合拳才能完成，需要知道過多的細節；往往會伴隨有“內幕交易、重復代碼、霰彈式修改……”
改進目標
將函式搬移到對應的類，解除跨模塊的過多交流
方法
提煉函式、搬移函式
注：策略模式、訪問者模式往往會帶來依戀情節，這不是說這兩個模式不可取，我們需要理解：
從根本上來說，我們消除“依戀情節”和應用這些設計模式都是為了把一起變化的東西放到一塊兒
——《重構，改善既有代碼的設計》
資料泥團
定義
總是成塊出現的相同資料項，包括多個類中相同的欄位、多個方法簽名中相同的引數等
影響
成塊出現的重復引數過多，影響閱讀和理解，難維護
改進目標
減少相同的欄位及入參，縮短入參列，簡化函式呼叫
方法
提煉類 引入引數物件 保持物件完整性
Tip：行內
這里之所以能夠直接行內，是因為欄位是final的，只會讀取，不會更新，大家可以嘗試在非final上行內，IDEA會提示我們行內失敗，因此當我們需要通過行內的方法消除欄位時，需要先想辦法把欄位變為final的
Ctrl+Alt+N
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/499553.html
標籤：其他
上一篇：重構
下一篇：分布式事務(Seata)