<div class="markdown_views">
            <h3 id="重構前需要考慮"><a name="t0"></a>重構前需要考慮</h3>

• 全面的瞭解系統的過去，包括以前的架構/技術背景、業務需求
• 分析以前架構的問題，例如：可維護性低、在哪個方面已經不滿足現有需求等等
• 檢視至少80%的核心程式碼，最好有一定時間的真實在以前程式碼基礎上編碼的經歷

有了上面幾點後還需要搞一個有效地重構計劃，保證重構有條不紊的進行，才不會出現重構沒有動力或者無法推動，或者與其他的業務需求衝突。

重構重點關注

幾個比較醜陋的程式碼：

• 臃腫的類: 類之所以會臃腫，是因為開發者缺乏對最基本的編碼原則，即“單一職責原則”（SRP）的理解。這些類往往會變得很臃腫，是由於不同的且在功能上缺少關聯的方法都放在了相同的類裡面。
• 長方法: 方法之所以會變得很長主要是有以下幾個原因：
  1、許多沒有關聯性的、功能複雜的模組的程式碼都放在相同的方法內。這主要是開發者缺乏SRP的概念。
  2、多種條件都放在同一個方法內，這在長方法內經常會發生的。這是由於缺乏McCabe程式碼複雜度和SRP的概念的比較。
• 大量的傳參: 我經常遇到這幾種情況，一些方法跟另一些方法進行互動，或者呼叫另一些方法的時候傳入大量的引數。這就會出現如果更改了其中一個引數，就得在多個方法內進行更改。
• 常量值無處不在: 經常會發現開發者（尤其是新手）會使用一些具有明確含義的常量值（主要是魔鬼數字），但沒有給它們賦予合適的常量變數。這會降低程式碼的可讀性和可理解性。
• 模糊的方法名: 許多時候，以下取的方法名會影響程式碼的可讀性和可理解性：模糊的不具有任何意義的方法名，技術性的，卻沒有提及相關領域的名稱

6個處理上面程式碼異味的重構方法（手法）

以下是6個可以用來幫助你解決80%（80-20原則）的程式碼質量問題的重構方法，並能幫助你成為一個更優秀的開發者。

• 提取類/抽離方法：正如上面提到的，像“臃腫的類”（一個類提供了本該有幾個類提供的功能）這種程式碼異味應該將原有類中的方法和屬性移動到適當數目的新類中去。舊類中對應新類的方法和屬性應該被移除。另外，有時候一些類過於臃腫是因為它包含了被其他類使用本應該是其他類的成員方法的成員方法。這些方法也應該被遷移到合適的類中。
• 提取方法：像上面提到的“過長的方法”這種程式碼異味可以通過從舊方法中提取程式碼到一個或多個新方法中消除。
• 分離條件：許多時候，一個方法很長是因為包含好幾個分支語句（if-else）。這些分支條件可以被提取和移動到幾個單獨的方法中。這確實能大大改善程式碼可讀性和可理解性。
• 引入引數物件/保留全域性物件：在我做程式碼審查時發現另外一個很常見的情況 - 好幾個引數被傳入方法。問題主要與需要從已有方法中增加或者移除一個方法引數有關。在這種場景，建議將相關方法引數組成一個物件（引入引數物件），讓方法傳遞這些物件而不是每個單獨的引數。
• 用符號常量替換魔法數字：對於有意義的並且到處被使用的字面常量，應該為它們分配一個命名常量。這能大大增強程式碼可讀性和可理解性。
• 重新命名方法：正如上面提到的，模糊不清的方法名會影響程式碼的可使用性。這些模糊不清的名稱應該重新命名為有意義的可能與業務術語有關的名稱，來幫助開發者通過業務上下文更好地理解程式碼。這很需要技巧並且要求開發者與業務專家一起協作來理清程式碼需要滿足的業務需求。

重構的方法

程式碼結構

• 良好的結構組織，MVC，面向介面；
• 風格統一，程式碼複查，pr->review；

批量、多執行緒、並行非同步

• 非同步請求，任務分離，按業務拆分執行緒池；
• 集中管理，自動配置（[email protected]）；

快取、異構化

• Local + 集中快取，非同步重新整理、永不過期（mq、task）；
• 資料異構化，別的系統都掛了，自己的系統依然堅挺；

監控治理

• 合理監控，量化報表；
• 報警及時，覆盤總結；
  重構是一個過程，需要穩步小跑，不能停留，任何一個優秀的系統都是進過無數次重構優化的。