譯者 | 劉濤

審校 | 重樓

目錄

重構概述

重構前期準備

• 爭取管理層支持
• 通過自動化測試確保安全保障
• 識別高風險區域
• 設定明確的重構目標

復雜代碼庫的重構技巧

• 識別并隔離問題區域
• 漸進式重構與大爆炸式重構
• 拆分單體代碼
• 確保向后兼容性
• 處理依賴關系與緊密耦合
• 測試策略（自信地安全重構）
• 在不降低性能的前提下進行重構
• 使用人工智能工具自動化代碼審查

總結

一、重構概述

重構是一種對代碼開展持續優化的重要手段，其核心目標在于降低代碼的復雜程度，削減技術債務。通過不斷完善代碼庫來解決項目推進過程中出現的代碼結構惡化問題，它能將雜亂無章或低效的代碼轉變為結構良好、便于維護的解決方案。

二、重構前期準備

在著手進行代碼重構之前，搭建一個堅實穩固的基礎有著舉足輕重的意義。這不僅有助于規范重構流程，確保各項工作有序開展，還能促進團隊成員間的高效協作與溝通，使全體成員對目標和任務達成共識，避免因信息不一致或方向偏差阻礙項目進展。

1.爭取管理層支持

若能將代碼重構工作與核心業務成果、產品上市周期的有效縮短、系統宕機概率的顯著降低以及開展新業務計劃的能力進行深度關聯，清晰展示出重構工作在這些關鍵層面所具備的潛在價值，管理層通常會更傾向于為重構工作投入所需資源。

2.通過自動化測試確保安全保障

在進行代碼重構時，測試堪稱保障重構安全的關鍵防線。在對某個組件進行修改之前，需要圍繞它編寫特征測試。

# example: characterization test for a legacy function
def legacy_calculate_discount(price, rate):
 # ... complex logic you don't fully understand yet ...
return price * (1 - rate/100) if rate < 100 else 0
def test_legacy_calculate_discount():
 # capture existing behavior
 assert legacy_calculate_discount(100, 10) == 90
assert legacy_calculate_discount(50, 200) == 0

測試在重構中記錄運行狀態，單元、集成和端到端測試可驗證重構是否破壞原有功能。自動化測試至關重要，搭建持續集成管道，使每次代碼變更觸發測試，能快速反饋，避免引入回歸問題。

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
 test:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - uses: actions/setup-python@v4
 with: python-version: '3.10'
 - run: pip install -r requirements.txt
 - run: pytest --maxfail=1 --disable-warnings -q

3.識別高風險區域

重構的首要步驟是明確重構對象。高風險區域指代碼中易引發漏洞或阻礙開發進度的部分，常見表現有方法冗長、類體量過大、代碼重復以及復雜的條件邏輯。

借助靜態分析工具能夠自動識別此類問題。如SonarQube能標記增加技術債務的代碼缺陷。使用同類工具，能夠生成代碼復雜度（如圈復雜度指標）報告，精準定位代碼庫中需重點關注的區域。

4.設定明確的重構目標

重構代碼前，需明確具體且可量化的目標，如降低類規模或函數圈復雜度、提升單元測試覆蓋率等。每個目標對應可衡量結果，如精簡方法、減少條件語句等，既能指引重構計劃，又方便驗證成果。

三、復雜代碼庫的重構技巧

1.識別并隔離問題區域

最高效的重構工作通常聚焦于“問題區域”，即代碼庫中復雜度高、易出錯，或成為開發與性能瓶頸的部分。精準識別這些區域后，需進行隔離以便安全重構，可采用以下策略：

• 打破依賴關系（創建接縫）：有效利用遺留代碼。如 PaymentService 與 StripeGateway 緊密耦合的情況。
• 添加抽象層：在舊代碼前添加抽象層（如接口或代理），后面新舊代碼實現，逐漸將舊實現遷移到新實現，可通過配置或功能標志切換。

2.漸進式重構與大爆炸式重構

重構時需在漸進式重構和“大爆炸”式重構中做戰略選擇。多數情況下，漸進式方法更優，但特定場景下也會考慮大爆炸式重構。

# before: one large function with multiple responsibilities
def process_order(order):
 validate(order)
 apply_discount(order)
 save_to_db(order)
 send_confirmation(order)
 log_metrics(order)
 update_loyalty_points(order)
# potentially more steps 
# after: refactored incrementally into clearer, smaller units
def process_order(order):
 validate(order)
 apply_discount(order)
persist_and_notify(order)
def persist_and_notify(order):
 save_to_db(order)
 send_confirmation(order)
 log_metrics(order)
 update_loyalty_points(order)

漸進式重構

漸進式重構是隨時間推移進行微小、易管理的更改，而非一次性大規模整改。其優勢在于降低風險，出錯概率低且后續易定位修復。

大爆炸式重構

這是“推倒重來”的方法，停止添加新功能，凍結代碼一段時間，投入大量精力重新設計或重寫系統大部分甚至全部內容，目標是打造全新整潔的系統。

3.拆分單體代碼

許多復雜代碼庫最初是單一的單體應用，即一個可部署的代碼項目或一組緊密耦合、統一維護發布的模塊。隨著時間推移，單體應用變得難以管控，因此需將單體應用模塊化或拆分為更易管理的部分。

# define the interfaceclass PaymentProcessor:
 def charge(self, amount): ...
# old implementationclass LegacyProcessor(PaymentProcessor):
 def charge(self, amount):
 # original code
# new implementation behind a feature flagclass NewProcessor(PaymentProcessor):
 def charge(self, amount):
 # cleaner code
def get_processor():
 if config.feature_new_payment:
 return NewProcessor()
 return LegacyProcessor()
# usage remains the same
processor = get_processor()
processor.charge(100)

模塊化策略

拆分單體應用可采用以下策略：

• 分層分離：強化邏輯層邊界，將用戶界面、業務邏輯、數據訪問代碼分開，按層組織代碼以限制變更連鎖反應。
• 基于領域的模塊化：按業務領域或功能區域拆分，如電商單體應用拆分為賬戶、訂單等模塊，減少模塊間內部信息依賴，通過清晰 API 交互。
• 微服務或服務提取：將單體應用拆分為通過 API 通信的獨立微服務，提升獨立部署和可擴展性，可循序漸進先提取一項功能為單獨服務，再逐步處理其他模塊。
• 模塊化單體架構：將單個應用構建為通過明確接口通信的模塊，類似內部微服務，可獲微服務優勢，避免運維復雜性。
• 區分共享工具與獨立組件：拆分時將廣泛共享的代碼整合到庫或服務中。

4.確保向后兼容性

大規模重構時，關鍵要確保重構后依賴代碼的系統、模塊或客戶端能否正常運行。若代碼庫涉及提供公共API、持久化數據或配置文件等內容時，向后兼容性尤為重要。以下是維持向后兼容性的策略：

• 函數重構：對于廣泛使用的函數（如 send_email）進行重構時，需保持其公共 API 不變，將調用委托給新的內部函數；引入改進后的新版本時，在文檔中標記舊版本為已棄用，同時確保舊版本在內部調用新版本，為其他團隊留出遷移時間。
• 編寫適配器或兼容層：重構底層數據模型但存在舊配置文件時，編寫適配器程序將舊配置文件格式轉換為新格式，使舊數據仍能正常使用，實現數據的平滑過渡與兼容。
• 進行兼容性測試：納入確保向后兼容性的測試，如針對公共 API保留使用舊版本定義的交互規則，開展測試并在重構后運行。

5.處理依賴關系與緊密耦合

重構大型代碼庫時，復雜系統常存在緊密耦合問題，如模塊間相互依賴細節、廣泛使用全局變量或單例模式，任何一處改動都有可能影響大片代碼。

降低耦合度是重構的重要目標，可使代碼更具模塊化，便于獨立理解、測試和修改。以下是降低耦合度的策略：

• 引入接口或抽象層：在組件間引入接口是有效的解耦方法。例如，讓直接查詢數據庫的類使用接口，使類不依賴具體數據獲取方式，遵循依賴倒置原則。

# before: direct instantiation
class OrderService:
 def __init__(self):
 self.repo = OrderRepository()
 
# after: inject dependency
class OrderService:
 def __init__(self, repo):
 self.repo = repo
 
# wiring up in application startup
repo = OrderRepository(db_conn)
service = OrderService(repo)

• 使用依賴注入：完成接口配置后，可通過依賴注入提供具體實現。
• 外觀模式或包裝服務：若特定子系統與其他子系統糾纏復雜時，可引入外觀模式和包裝服務以優化。
• 逐步替換（并行運行）：若需用新實現替換特定組件，可暫時并行運行新舊組件。例如，對于需重構的復雜模塊，可保留舊代碼以處理遺留調用，同時引導新調用至新模塊。

6.測試策略（自信地安全重構）

穩健的測試策略能為大規模重構提供信心，確保出現問題時可迅速察覺。在大規模重構中，可按以下方式開展測試：

• 通過回歸測試建立基線：重構特定組件前，需確保有覆蓋其當前行為的測試。若代碼庫測試套件不完善，應優先編寫特性測試。
• 持續集成：建議將測試集成到持續集成管道，每次提交或合并代碼時運行測試，以便及時捕獲重構過程中引入的錯誤，縮短反饋周期。
• 金絲雀發布測試：金絲雀發布測試是先將變更部署到部分用戶或服務器，觀察后逐步擴大范圍，有助于發現測試遺漏的問題。若表現良好則全面推廣，反之則迅速回滾，減小影響范圍。
• 性能與負載測試：若性能是關注點，應在測試策略中加入性能測試，可在預發布環境進行。若性能顯著下降，需重新考慮重構方法或優化新代碼。
• 測試舊代碼：處理未經測試的舊代碼時，應優先覆蓋部分內容，可采用審批測試等技術，以此為重構指引方向。總之，強大的測試策略對重構復雜系統至關重要，它是安全保障和早期預警系統，能確保重構不破壞關鍵內容。

7.在不降低性能的前提下進行重構

重構代碼不會改變算法和數據結構，因此理論上并不會影響系統性能。但實際操作中可能會無意間影響性能，如占用更多內存或移除關鍵緩存機制。資深工程師重構時需關注性能敏感部分，避免性能倒退，以下是兼顧性能的方法：

• 確定關鍵路徑：不同代碼對性能影響不同，重構性能關鍵代碼時要重新測量性能；非關鍵部分操作空間更大。
• 使用分析工具：用性能分析器在重構前后測量代碼，對比性能表現，及時發現性能問題。
• 提升性能機會：重構也可提升性能，如重構重復代碼以使用更好的緩存機制，重構時留意此類機會。

8.使用人工智能工具自動化代碼審查

代碼重構是個持續過程，人工智能代碼審查工具可推行整潔代碼標準，提前發現代碼問題，減少重復工作，讓工程師專注于架構或特定領域難題。

CodeRabbit作為一款強大的人工智能驅動審查平臺，旨在減半審查時間與漏洞數量，其工作原理及對重構流程的優化作用如下：

智能情境反饋

CodeRabbit利用先進語言模型與靜態分析技術，逐行分析拉取請求，在人工介入前就能標記潛在漏洞、不良實踐與風格問題。

多元實用功能

• 摘要生成與一鍵修復：為大型拉取請求生成摘要，快速應用簡單修復方案。
• 實時協作與智能交互：通過與人工智能聊天獲取解釋、替代代碼與即時反饋。
• 主流平臺集成：支持 GitHub、GitLab 和 Azure DevOps，實現拉取請求無縫掃描。

此外，CodeRabbit 還在VS Code 提供免費審查功能，借助該擴展，開發者可在編輯器內直接獲得先進審查服務，節省時間、捕捉更多漏洞，推動代碼重構。

總結

重構應成為持續的過程。把相關實踐融入日常開發，如每個沖刺周期預留時間重構，或在處理代碼時適時開展，可避免代碼庫質量下滑。單次小的重構不必過于復雜，但其積累效應顯著。

譯者介紹

劉濤，51CTO社區編輯，某大型央企系統上線檢測管控負責人。

原文標題：How to Refactor Complex Codebases – A Practical Guide for Devs，作者：Ankur Tyagi