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