前言：為什麼重構總是痛苦的？
代碼重構是軟體工程的常態，但許多 PHP 專案在重構時陷入泥沼。本文從實戰經驗出發，剖析導致重構困難的四大核心成因，並給出對應策略。
成因一：編碼規範流於形式，個人風格差異大
現象
- 專案初期訂立規範，但缺乏強制執行機制（如 PHP_CodeSniffer、PHP-CS-Fixer）
- 同一功能由不同人實現，邏輯結構、命名風格、錯誤處理方式截然不同
- 開發者不願閱讀他人代碼，傾向「重寫大法」，導致冗餘代碼指數級增長
對策
- 引入 **PHP_CodeSniffer + PHP-CS-Fixer** 整合至 Git Hook（pre-commit）與 CI 流程
- 制定《團隊編碼規範文件》，包含：命名慣例、目錄結構、設計模式選型、異常處理流程
- 推行 **Code Review 文化**：所有合併請求必須經過至少一位資深成員審閱
- 建立「重構獎勵機制」：對主動清理技術債務的行為給予肯定
成因二：人員流動頻繁，知識傳承斷層
現象
- 核心成員離職，新成員不熟悉歷史決策背景
- 為求穩定，制定「上線代碼不可動」規定，導致新需求只能疊加新 Class/Function
- 出現大量相似功能的類別（如 `UserServiceV1`、`UserServiceV2`、`UserManager`、`UserHandler`）
對策
- 建立 **架構決策記錄（ADR, Architecture Decision Records）**：記錄每個重大技術選型的背景、替代方案、決策理由、後果
- 實施 **領域驅動設計（DDD）分層架構**：明確領域層、應用層、基礎設施層職責，新功能擴展而非修改核心
- 推行 **Strangler Fig Pattern（綁架者模式）**：逐步以新實現替舊代碼，而非大爆炸式重寫
- 建立完善的 **單元測試與整合測試覆蓋率門檻**（如 >80%），給予重構信心
成因三：資料庫設計缺乏前瞻，冗餘欄位與表泛濫
現象
- 為滿足急迫需求，頻繁 `ALTER TABLE ADD COLUMN` 或建立關聯表
- 缺乏資料庫遷移工具，結構變更無版本控制、無回滾機制
- 「寬表」現象：單表欄位超過 50+，大量 NULL 值、重複資料
- 查詢效能下降，被迫加索引、建視圖、冗餘快照表，進一步惡化結構
對策
- 強制使用 **資料庫遷移工具**（Laravel Migration、Phinx、Doctrine Migrations）
- 採用 **規格化設計（3NF/BCNF）** 為基準，必要時才為效能進行反規格化，並文檔化理由
- 定期進行 **資料庫審計**：識別未使用索引、大表、冗餘欄位、孤兒表
- 引入 **Read Model / CQRS** 思想：寫入模型嚴格規格化，讀取模型可適度冗餘
成因四：缺乏模組化思維，耦合度極高
現象
- 「上帝類別」：單一類別承擔過多職責（業務邏輯、資料存取、外部 API 呼叫、視圖渲染）
- 硬編碼依賴：`new ConcreteClass()` 遍佈各處，無法替換實現
- 介面不統一：同類操作有多組參數/回傳格式，調用方需針對各類別特殊處理
- 全域狀態濫用：`$_SESSION`、`$_GLOBALS`、單例模式濫用，導致測試極度困難
對策
- 遵循 **SOLID 原則**，特別是單一職責（SRP）與依賴反轉（DIP）
- 全面採用 **依賴注入（DI）容器**（PHP-DI、Symfony DI、Laravel Service Container）
- 定義清晰的 **Repository Interface**、**Service Interface**，實現類別可替換
- 採用 **領域事件** 解耦跨聚合根操作，避免同步調用鏈過長
- 建立 **共用核心套件**：將通用工具、基類、介面抽離為獨立 Composer 套件
總結：重構是持續的投資，而非一次性專案
上述四大成因往往交織在一起。成功的重構策略是：
- **建立防護網**：測試覆蓋率、靜態分析、CI/CD 流程
- **小步快跑**：每次重構範圍可控、可驗證、可回滾
- **文化先行**：團隊共識 > 工具選型 > 流程落地
- **度量驅動**：追蹤圈複雜度、耦合度、重複代碼率、測試覆蓋率趨勢
記住：**最好的重構時機是專案啟動時；第二好的時機是現在。**
