universal-dev-standards 4.2.0 → 5.0.0-beta.10

package/bundled/locales/zh-TW/core/refactoring-standards.md

@@ -1,864 +1,78 @@
----
-source: ../../../core/refactoring-standards.md
-source_version: 2.0.0
-translation_version: 2.0.0
-last_synced: 2026-01-21
-status: current
----
-
 # 重構標準
 
 > **語言**: [English](../../../core/refactoring-standards.md) | 繁體中文
 
-**版本**: 2.0.0
-**最後更新**: 2026-01-21
-**適用範圍**: 所有進行程式碼改善的軟體專案
+**版本**: 2.1.0
+**最後更新**: 2026-02-10
+**適用性**: 所有軟體專案
+**範圍**: 通用 (Universal)
 
 ---
 
 ## 目的
 
-本標準定義程式碼重構的完整指引，涵蓋從日常 TDD 重構循環到大型遺留系統現代化的所有場景。確保重構工作安全、可衡量，並與業務目標一致。
-
-**主要優點**：
-- 系統化的程式碼品質改善方法
-- 降低重構過程中引入錯誤的風險
-- 清晰的重構 vs 重寫決策框架
-- 可衡量的成果與投資報酬率追蹤
-
----
-
-## 目錄
-
-1. [重構 vs 重寫決策矩陣](#重構-vs-重寫決策矩陣)
-2. [戰術性重構策略](#戰術性重構策略)
-   - [預備性重構](#預備性重構)
-   - [童子軍規則](#童子軍規則)
-   - [紅-綠-重構](#紅-綠-重構)
-3. [戰略性重構策略](#戰略性重構策略)
-   - [絞殺榕模式](#絞殺榕模式)
-   - [防腐層](#防腐層)
-   - [抽象分支](#抽象分支)
-   - [平行變更](#平行變更expand-migrate-contract)
-4. [遺留程式碼安全策略](#遺留程式碼安全策略)
-   - [特徵測試](#特徵測試)
-   - [探針式重構](#探針式重構)
-   - [尋找接縫](#尋找接縫)
-   - [Sprout 與 Wrap 技術](#sprout-與-wrap-技術)
-5. [資料庫重構](#資料庫重構)
-6. [安全重構工作流程](#安全重構工作流程)
-7. [重構度量指標](#重構度量指標)
-8. [團隊協作](#團隊協作)
-9. [技術債管理](#技術債管理)
-10. [決策矩陣摘要](#決策矩陣摘要)
-11. [相關標準](#相關標準)
-12. [參考資料](#參考資料)
-13. [版本歷程](#版本歷程)
-
----
-
-## 重構 vs 重寫決策矩陣
-
-在開始任何大型重構工作之前，評估重構或重寫哪個更合適。
-
-### 決策流程圖
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│                     重構 vs 重寫決策樹                           │
-├─────────────────────────────────────────────────────────────────┤
-│                                                                 │
-│  程式碼目前在生產環境運行嗎？                                     │
-│  ├─ 否 → 考慮重寫（風險較低）                                    │
-│  └─ 是 ↓                                                        │
-│                                                                 │
-│  你了解程式碼在做什麼嗎？                                         │
-│  ├─ 否 → 先寫特徵測試，再決定                                    │
-│  └─ 是 ↓                                                        │
-│                                                                 │
-│  測試覆蓋率足夠嗎（>60%）？                                       │
-│  ├─ 否 → 先補測試，再決定                                        │
-│  └─ 是 ↓                                                        │
-│                                                                 │
-│  核心架構可以保留嗎？                                             │
-│  ├─ 否 → Strangler Fig（漸進替換）                               │
-│  └─ 是 → 漸進式重構 ✓                                            │
-│                                                                 │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-### 比較矩陣
-
-| 因素 | 傾向重構 | 傾向重寫 |
-|------|---------|---------|
-| **程式碼規模** | 大型、複雜 | 小型、獨立 |
-| **測試覆蓋率** | 良好（>60%）| 差或沒有 |
-| **業務連續性** | 關鍵 | 可容忍停機 |
-| **團隊知識** | 團隊理解程式碼 | 無組織知識 |
-| **核心架構** | 健全，只是混亂 | 根本性缺陷 |
-| **時間壓力** | 緊迫期限 | 彈性時間 |
-| **風險容忍度** | 低 | 較高 |
-
-### 警告：第二系統效應
-
-> 「第二個系統是一個人設計過最危險的系統。」— Fred Brooks
-
-重寫時，團隊常常過度工程化。避免：
-- 新增原本沒有的功能
-- 「為了未來彈性」過度抽象
-- 忽視現有系統的教訓
-
----
-
-## 戰術性重構策略
-
-戰術性策略用於日常開發工作。運作時間為分鐘到小時級別，需要最小的協調。
-
-### 預備性重構
-
-**定義**：在新增功能之前，先調整既有結構，使其易於接納新功能。
-
-> 「先把改變變容易（這可能很難），然後再做那個容易的改變。」— Kent Beck
-
-**適用情境**：
-- 現有架構難以直接插入新功能
-- 程式碼結構需要調整以支援新需求
-- 降低即將到來的變更的阻力
-
-**工作流程**：
-
-```
-1. 識別你想要做的改變
-2. 識別是什麼讓這個改變變困難
-3. 重構以讓改變變容易
-4. 做那個（現在已經變容易的）改變
-```
-
-**範例**：
-- 改變前：為一個緊耦合的服務加入快取很複雜
-- 預備性重構：抽取介面、注入依賴
-- 改變後：加入快取變得簡單直接
-
-**關鍵原則**：
-- 預備性重構是與功能分開的提交
-- 每一步都維持測試通過
-- 不要在同一個提交中混合重構與功能開發
-
-### 童子軍規則
-
-**定義**：離開時讓程式碼比你來的時候更乾淨。這是一種「機會主義重構」— 不刻意安排重構衝刺，而是在修復 Bug 或新增功能時，順手清理所接觸到的程式碼。
-
-> 「離開營地時，讓它比你來的時候更乾淨。」— Robert C. Martin
-
-**適用情境**：
-- 任何維護作業
-- Bug 修復
-- 功能新增
-- 對抗軟體熵（Software Entropy）
-
-**指導原則**：
-- 只做小改進（分鐘，不是小時）
-- 不可改變行為
-- 不可破壞現有測試
-- 改動範圍保持在你的任務內
-
-**童子軍改進的範例**：
-- 重新命名一個令人困惑的變數
-- 將幾行程式碼提取為命名良好的方法
-- 移除你注意到的死程式碼
-- 加入澄清註解
-- 修復一個小的程式碼風格問題
-
-**應避免的反模式**：
-- 把 Bug 修復變成大規模重構專案
-- 重構不相關的程式碼
-- 在沒有測試覆蓋的情況下修改
-- 範圍蔓延超出原始任務
-
-### 紅-綠-重構
-
-測試驅動開發（TDD）循環的一部分。完整細節請見[測試驅動開發](test-driven-development.md)。
-
-**特點**：
-- 時長：每循環 5-15 分鐘
-- 範圍：單一方法或類別
-- 測試：重構後必須保持綠色
-
-**循環**：
-
-```
-┌─────────────────────────────────────────┐
-│                                         │
-│    ┌─────┐     ┌─────┐     ┌─────────┐ │
-│    │ 紅燈│ ──► │綠燈 │ ──► │  重構   │ │
-│    └─────┘     └─────┘     └─────────┘ │
-│       ▲                          │      │
-│       └──────────────────────────┘      │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**常用重構技術**：
-- 提取方法（Extract Method）
-- 重新命名（Rename）
-- 內聯變數（Inline Variable）
-- 以常數取代魔術數字（Replace Magic Number with Constant）
-- 移除重複（Remove Duplication）
-
----
-
-## 戰略性重構策略
-
-戰略性策略用於重大架構變更。運作時間為週到月級別，需要團隊協調。
-
-### 絞殺榕模式
-
-**定義**：透過逐步將功能路由到新系統，漸進替換遺留系統。
-
-**來源**：命名自絞殺榕樹，它們環繞宿主樹生長，最終取代它。
-
-**適用情境**：
-- 漸進替換遺留系統
-- 無法承受大爆炸式重寫
-- 需要在遷移期間維持服務
-
-**架構**：
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│                    絞殺榕模式 (Strangler Fig)                    │
-├─────────────────────────────────────────────────────────────────┤
-│                                                                 │
-│  階段 1: 攔截（INTERCEPT）                                       │
-│  ┌─────────┐     ┌─────────┐     ┌─────────────┐               │
-│  │  請求   │────▶│  門面   │────▶│ 舊系統(100%)│               │
-│  └─────────┘     └─────────┘     └─────────────┘               │
-│                                                                 │
-│  階段 2: 遷移（MIGRATE）                                         │
-│  ┌─────────┐     ┌─────────┐     ┌─────────────┐               │
-│  │  請求   │────▶│  門面   │──┬─▶│ 新系統(功能A)│               │
-│  └─────────┘     └─────────┘  │  └─────────────┘               │
-│                               └─▶│ 舊系統(其餘) │               │
-│                                  └─────────────┘               │
-│                                                                 │
-│  階段 3: 完成（COMPLETE）                                        │
-│  ┌─────────┐     ┌─────────────┐                               │
-│  │  請求   │────▶│ 新系統(100%)│  [舊系統已下線]                │
-│  └─────────┘     └─────────────┘                               │
-│                                                                 │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-**檢查清單**：
-- [ ] 識別攔截點（API 閘道、門面、代理）
-- [ ] 建立事件捕獲層
-- [ ] 在新系統中實作第一個功能
-- [ ] 漸進式路由流量
-- [ ] 監控並比較結果
-- [ ] 下線舊元件
-
-### 防腐層
-
-**定義**：在遺留系統與新系統之間建立的翻譯層，防止遺留系統混亂的領域模型「污染」新系統的整潔架構。
-
-**來源**：Eric Evans,《領域驅動設計》(2003)
-
-**適用情境**：
-- 新舊系統必須並存且頻繁互動
-- 遺留系統有複雜/混亂的領域模型
-- 保護新系統的限界上下文（Bounded Context）
-
-**架構**：
-
-```
-┌────────────────────────────────────────────────────────────┐
-│                    防腐層 (ACL)                              │
-├────────────────────────────────────────────────────────────┤
-│                                                            │
-│  ┌─────────────┐     ┌─────────────┐     ┌─────────────┐  │
-│  │   新系統    │────▶│    ACL      │────▶│  遺留系統   │  │
-│  │ (整潔 API) │     │             │     │(混亂模型)   │  │
-│  └─────────────┘     │ ┌─────────┐ │     └─────────────┘  │
-│                      │ │ Adapter │ │                      │
-│                      │ │ Facade  │ │                      │
-│                      │ │Translator││                      │
-│                      │ └─────────┘ │                      │
-│                      └─────────────┘                      │
-│                                                            │
-└────────────────────────────────────────────────────────────┘
-```
-
-**組件**：
-
-| 組件 | 用途 |
-|------|------|
-| **Facade（門面）** | 簡化複雜的遺留介面 |
-| **Adapter（轉接器）** | 將遺留資料格式轉換為新領域模型 |
-| **Translator（翻譯器）** | 將遺留術語映射到通用語言 |
-
-**實作檢查清單**：
-- [ ] 定義 ACL 的清晰介面
-- [ ] 映射遺留實體到新領域模型
-- [ ] 處理資料格式轉換
-- [ ] 實作錯誤翻譯
-- [ ] 加入日誌以便除錯
-- [ ] 徹底測試 ACL 隔離性
-
-**與絞殺榕的比較**：
-
-| 面向 | 絞殺榕 | 防腐層 |
-|------|--------|--------|
-| **目標** | 取代遺留系統 | 與遺留系統共存 |
-| **方向** | 遷移離開遺留 | 整合遺留 |
-| **最終狀態** | 遺留系統下線 | 兩個系統繼續運作 |
-
-### 抽象分支
-
-**定義**：透過引入抽象層，在不使用長期分支的情況下重構共享程式碼。
-
-**適用情境**：
-- 在不用長期分支的情況下重構共享程式碼
-- 需要主幹開發
-- 變更風險太高，無法單一提交
-
-**步驟**：
-
-```
-步驟 1：引入抽象
-        客戶端 → 抽象（介面）→ 舊實作
-
-步驟 2：新增新實作
-        客戶端 → 抽象 → 舊實作
-                     └─→ 新實作（功能開關控制）
-
-步驟 3：切換並移除
-        客戶端 → 新實作
-        [舊實作已移除]
-```
-
-**關鍵原則**：
-- 所有變更在主幹（trunk）上（沒有長期分支）
-- 功能開關控制哪個實作是活躍的
-- 兩個實作可以在過渡期共存
-
-### 平行變更（Expand-Migrate-Contract）
-
-**定義**：透過三階段方法變更被多個客戶端使用的介面。
-
-**適用情境**：
-- 變更多個客戶端使用的介面
-- 資料庫 Schema 遷移
-- 需要零停機遷移
-
-**階段**：
-
-```
-階段 1: 擴展（EXPAND）
-├─ 在舊的旁邊新增新欄位/方法
-├─ 新程式碼使用新介面
-└─ 舊程式碼仍然運作
-
-階段 2: 遷移（MIGRATE）
-├─ 更新所有客戶端使用新介面
-├─ 驗證所有客戶端已遷移
-└─ 資料遷移（如需要）
-
-階段 3: 收縮（CONTRACT）
-├─ 移除舊欄位/方法
-├─ 清理遷移程式碼
-└─ 更新文件
-```
-
----
-
-## 遺留程式碼安全策略
-
-基於 Michael Feathers 的《Working Effectively with Legacy Code》。
-
-### 遺留程式碼困境
-
-**定義**：遺留程式碼 = 沒有測試的程式碼（無關年齡）
-
-**困境**：
-- 要安全地修改程式碼，我們需要測試
-- 要加測試，我們常常需要修改程式碼
-- 沒有測試就修改程式碼是有風險的
-
-**解決方案**：使用安全技術在修改前加入測試。
-
-### 特徵測試
-
-**定義**：捕獲現有行為（不是驗證正確性）的測試。
-
-**目的**：在重構遺留程式碼前建立安全網。
-
-**流程**：
-
-```
-1. 呼叫你想了解的程式碼
-2. 寫一個你預期會失敗的斷言
-3. 執行測試看實際發生什麼
-4. 更新斷言以符合實際行為
-5. 重複直到覆蓋你需要修改的行為
-```
-
-**範例**：
-
-```javascript
-// 步驟 1：初始（預期會失敗）
-test('calculateDiscount 回傳... 某個值', () => {
-  const result = calculateDiscount(100, 'GOLD');
-  expect(result).toBe(0); // 猜測 - 可能會失敗
-});
-
-// 步驟 2：執行後，更新為實際值
-test('calculateDiscount 對 GOLD 客戶回傳 15', () => {
-  const result = calculateDiscount(100, 'GOLD');
-  expect(result).toBe(15); // 實際行為
-});
-```
-
-**關鍵原則**：特徵測試記錄程式碼*做什麼*，而非*應該做什麼*。
-
-### 探針式重構
-
-**定義**：為了理解程式碼而重構，不保留任何變更。
-
-**目的**：透過實際動手修改來探索和理解無文件程式碼。
-
-**工作流程**：
-
-```
-1. 建立探針分支（或使用 git stash）
-2. 大膽重構以理解程式碼
-3. 記錄學到的內容
-4. 捨棄所有變更（git reset --hard）
-5. 將學習成果應用於撰寫特徵測試
-```
-
-**適用情境**：
-- 程式碼太複雜，無法透過閱讀理解
-- 沒有文件存在
-- 需要快速建立心智模型
-
-**關鍵原則**：目標是理解，不是整潔的程式碼。完成後捨棄一切。
-
-### 尋找接縫
-
-**定義**：接縫是可以在不編輯程式碼的情況下改變行為的地方。
-
-| 接縫類型 | 運作方式 | 範例 |
-|---------|---------|------|
-| **物件接縫** | 透過多型覆寫 | 透過介面注入測試替身 |
-| **預處理接縫** | 編譯時替換 | 條件編譯、巨集 |
-| **連結接縫** | 連結時替換 | 依賴注入、模組替換 |
-
-**目的**：在不修改遺留程式碼的情況下注入測試替身。
-
-### Sprout 與 Wrap 技術
-
-| 技術 | 使用時機 | 做法 |
-|-----|---------|-----|
-| **Sprout Method** | 在現有方法中加入新邏輯 | 建立新方法，從舊方法呼叫 |
-| **Sprout Class** | 新邏輯需要獨立演進 | 建立新類別，從舊程式碼參照 |
-| **Wrap Method** | 需要在前後加入行為 | 重命名原方法，建立包裝器 |
-| **Wrap Class** | 裝飾現有類別 | 裝飾者模式 |
-
-**原則**：新程式碼使用 TDD；遺留程式碼在測試前保持不動。
-
-### 程式碼考古
-
-理解無文件程式碼的技術：
-
-```
-1. 探針式重構（見上方）
-   ├─ 重構以理解，不是保留
-   ├─ 使用 git stash 或分支
-   └─ 完成後捨棄（git reset --hard）
-
-2. 追蹤變數流動
-   ├─ 從輸入追蹤到輸出
-   ├─ 標記關鍵轉換點
-   └─ 邊發現邊記錄
-
-3. 執行時觀察
-   ├─ 加入暫時性日誌
-   ├─ 使用除錯器逐步執行
-   └─ 建立心智模型
-
-4. Git 考古
-   ├─ git log -p <file>（查看所有變更）
-   ├─ git blame（找到原作者）
-   └─ 搜尋提交訊息找脈絡
-```
+本標準定義重構的時機、安全規則與決策矩陣。關於具體重構模式（如 Extract Method, Strangler Fig）的詳細教學，請參閱 **[重構指南](guides/refactoring-guide.md)**。
 
 ---
 
-## 資料庫重構
-
-### Schema 變更的 Expand-Contract 模式
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│              資料庫重構（Expand-Contract）                        │
-├─────────────────────────────────────────────────────────────────┤
-│                                                                 │
-│  階段 1: 擴展（新增新的，保留舊的）                                │
-│  ├─ 新增新欄位/表                                               │
-│  ├─ 應用程式同時寫入新舊                                         │
-│  └─ 此時可安全回滾                                              │
-│                                                                 │
-│  階段 2: 遷移（搬移資料）                                         │
-│  ├─ 從舊複製資料到新                                            │
-│  ├─ 驗證資料一致性                                              │
-│  └─ 應用程式開始從新讀取                                         │
-│                                                                 │
-│  階段 3: 收縮（移除舊的）                                         │
-│  ├─ 確認舊欄位/表不再被讀取                                      │
-│  ├─ 移除舊欄位/表                                               │
-│  └─ 清理雙寫程式碼                                              │
-│                                                                 │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-### 常見 Schema 重構場景
-
-| 場景 | 策略 | 風險等級 |
-|-----|------|---------|
-| **重命名欄位** | 新增新的 → 遷移 → 刪除舊的 | 中 |
-| **拆分表格** | 新表 + 外鍵 → 遷移 → 調整應用程式 | 高 |
-| **合併表格** | 新表 → 合併資料 → 切換應用程式 | 高 |
-| **變更資料型別** | 新欄位 → 轉換 → 切換應用程式 | 中 |
-| **新增 NOT NULL** | 填入預設值 → 新增約束 | 低 |
-
-### 資料庫遷移安全檢查清單
-
-```
-遷移前：
-□ 完整備份已完成
-□ 遷移腳本已在測試環境驗證
-□ 回滾腳本已準備
-□ 遷移時間已估算（考慮資料量）
-□ 維護視窗已通知
-
-遷移中：
-□ 監控資料庫效能
-□ 增量驗證資料完整性
-□ 應用程式健康檢查通過
-
-遷移後：
-□ 資料一致性驗證
-□ 應用程式功能驗證
-□ 效能基線比較
-□ 備份保留一段時間以供回滾
-```
-
-### 零停機遷移技術
-
-| 技術 | 說明 | 使用場景 |
-|-----|------|---------|
-| **Online Schema Change** | pt-osc, gh-ost | MySQL 大表變更 |
-| **Blue-Green Database** | 雙資料庫切換 | 高可用需求 |
-| **Shadow Write** | 同時寫入兩個資料庫並比較 | 驗證遷移正確性 |
-| **Feature Flag** | 控制讀取來源 | 漸進式切換 |
-
----
-
-## 安全重構工作流程
-
-### 重構前
-
-```
-□ 定義成功標準（可衡量的）
-□ 確保足夠的測試覆蓋率（建議 >80%）
-□ 提交/暫存當前工作（乾淨的工作目錄）
-□ 建立功能分支（或在主幹上使用功能開關）
-□ 與團隊溝通以避免衝突
-```
-
-### 重構中
-
-```
-□ 一次只做一個小變更
-□ 每次變更後執行測試
-□ 如果測試失敗，立即復原
-□ 頻繁提交（每次測試通過都是一個存檔點）
-□ 重構時絕不加入新功能
-```
-
-### 重構後
-
-```
-□ 所有測試通過（與之前相同）
-□ 程式碼可衡量地更好（複雜度、重複等）
-□ 如需要則更新文件
-□ 團隊審查完成
-□ 沒有新增功能
-```
-
----
-
-## 重構度量指標
-
-### 程式碼品質指標
+## 核心規則
 
-| 指標 | 測量方式 | 目標 |
-|-----|---------|-----|
-| **循環複雜度** | 靜態分析工具 | 每函式 < 10 |
-| **認知複雜度** | SonarQube 等 | 越低越好 |
-| **耦合度** | 模組間依賴數 | 降低 |
-| **內聚性** | LCOM 指標 | 提高 |
-| **程式碼重複** | 重複程式碼百分比 | < 3% |
-| **程式碼行數** | 僅供參考 | 較少 ≠ 一定更好 |
-
-### 測試品質指標
-
-| 指標 | 目標 | 備註 |
-|-----|-----|------|
-| **測試覆蓋率** | ≥ 80% | 重構期間不要降低 |
-| **測試速度** | 更快 | 重構應改善可測試性 |
-| **不穩定測試數** | 降低 | 穩定性改善 |
-
-### 運維指標（DORA 指標）
-
-| 指標 | 測量方式 | 預期改善 |
-|-----|---------|---------|
-| **部署頻率** | CI/CD 記錄 | 提高（可維護性改善）|
-| **變更失敗率** | 回滾次數 | 降低 |
-| **平均恢復時間** | 事故記錄 | 縮短 |
-| **前置時間** | 從提交到部署 | 縮短 |
-
-### 團隊效率指標
-
-| 指標 | 測量方式 | 備註 |
-|-----|---------|------|
-| **新人上手時間** | 新員工熟悉時間 | 縮短 = 更好的可讀性 |
-| **PR 審查時間** | Git 記錄 | 縮短 = 更好的可理解性 |
-| **Bug 修復時間** | Issue 追蹤 | 縮短 = 更好的可維護性 |
-
-### 重構 ROI 框架
-
-```
-成本：
-├─ 開發時間 × 時薪
-├─ 測試時間
-├─ 部署風險成本
-└─ 機會成本（未建置的功能）
-
-收益：
-├─ 減少的維護時間 × 未來年數
-├─ 減少的 Bug × 修復成本
-├─ 更快的功能開發
-└─ 更低的人員流動成本
-```
+1. **紅-綠-重構**: 只有在測試通過 (綠燈) 時才進行重構。
+2. **不改變行為**: 重構應改善結構，而非改變外部行為。
+3. **小步前進**: 偏好頻繁的小重構，而非大規模的「重寫」。
+4. **童子軍法則**: 離開程式碼時，要比你發現它時更乾淨。
 
 ---
 
-## 團隊協作
-
-### 重構專案啟動
-
-```
-啟動會議議程：
-1. 範圍定義
-   ├─ 哪些模組/檔案在範圍內
-   └─ 明確排除什麼
-
-2. 成功標準對齊
-   ├─ 量化目標（複雜度降低 X%）
-   └─ 功能目標（行為不變）
+## 何時重構 (觸發點)
 
-3. 工作分配
-   ├─ 按模組（垂直切分）
-   └─ 按層級（水平切分）
-
-4. 風險評估
-   ├─ 最高風險區域
-   └─ 回滾策略
-```
-
-### 分工策略
-
-| 策略 | 使用時機 | 注意事項 |
-|-----|---------|---------|
-| **垂直切分** | 獨立模組 | 確保介面不變 |
-| **水平切分** | 跨模組重構（如命名規範）| 需嚴格同步 |
-| **Strangler 分工** | 大型系統替換 | 一人一個 Strangler 切片 |
-| **Mob Programming** | 核心/高風險區域 | 全團隊一起，降低風險 |
-
-### 溝通機制
-
-```
-日常溝通：
-├─ 站立會議同步重構進度
-├─ 共享的重構看板（Kanban）
-└─ 專用頻道（#refactoring-xxx）
-
-PR 規範：
-├─ 標題加 [Refactor] 前綴
-├─ 說明改了什麼以及為什麼
-├─ 包含前後複雜度比較
-└─ 遺留程式碼需要特徵測試
-
-衝突處理：
-├─ 小範圍：立即解決
-├─ 中範圍：每日同步會議
-└─ 大範圍：考慮 Branch by Abstraction
-```
-
-### PR 大小指引
-
-| 大小 | 變更行數 | 審查時間 |
-|-----|---------|---------|
-| 小 | < 200 | < 30 分鐘 |
-| 中 | 200-500 | < 1 小時 |
-| 大 | > 500 | **應該拆分** |
-
-**原則**：多個小 PR > 一個大 PR
+| 觸發點 | 說明 | 建議行動 |
+|--------|------|----------|
+| **三次法則** | 發現重複程式碼三次 | 提取共用方法或元件 |
+| **難以測試** | 程式碼依賴性太高或副作用太多 | 依賴注入、純函式化 |
+| **新增功能受阻** | 現有結構難以擴充 | 準備性重構 (Preparatory Refactoring) |
+| **Code Review** | 被指出可讀性差或複雜度高 | 修正後再合併 |
 
 ---
 
-## 技術債管理
-
-### 技術債象限
-
-基於 Martin Fowler 的技術債象限：
+## 程式碼異味 (Code Smell) 檢查清單
 
-```
-                       刻意的
-                         │
-        ┌────────────────┼────────────────┐
-        │                │                │
-        │    審慎的      │     魯莽的     │
-        │   「我們知道   │   「我們沒時間  │
-        │    這是債務」  │    做設計」    │
-        │                │                │
-審慎的  ├────────────────┼────────────────┤ 魯莽的
-        │                │                │
-        │    審慎的      │     魯莽的     │
-        │   「現在我們   │   「什麼是     │
-        │    知道該怎麼  │    分層？」    │
-        │    做了」      │                │
-        │                │                │
-        └────────────────┼────────────────┘
-                         │
-                      無意的
-```
-
-### 債務優先順序
-
-| 優先級 | 標準 | 行動 |
-|-------|------|-----|
-| **高** | 阻擋開發、導致頻繁 Bug | 立即處理 |
-| **中** | 拖慢開發、增加複雜度 | 排入下個 Sprint |
-| **低** | 小煩惱、影響隔離 | 隨機處理 |
-
-### 追蹤技術債
-
-```
-每個債務項目記錄：
-├─ 描述：問題是什麼？
-├─ 影響：如何影響開發？
-├─ 估計工作量：修復需要多久？
-├─ 忽視的風險：不處理會怎樣？
-└─ 相關程式碼：受影響的檔案/模組連結
-```
+- [ ] **長函式 (Long Method)**: 超過 20-30 行？
+- [ ] **大類別 (Large Class)**: 承擔太多責任？
+- [ ] **重複程式碼 (Duplicated Code)**: 違反 DRY 原則？
+- [ ] **過多參數 (Long Parameter List)**: 超過 3-4 個參數？
+- [ ] **特徵依戀 (Feature Envy)**: 一個方法過度使用另一個類別的資料？
+- [ ] **魔法數字 (Magic Numbers)**: 未解釋的常數？
 
 ---
 
-## 決策矩陣摘要
-
-選擇適當重構策略的快速參考：
-
-| 策略 | 規模 | 風險 | 關鍵用途 |
-|------|------|------|----------|
-| **預備性重構** | 小 | 低 | 降低功能開發阻力 |
-| **童子軍規則** | 極小 | 低 | 持續償還技術債 |
-| **紅-綠-重構** | 小 | 低 | TDD 開發循環 |
-| **絞殺榕模式** | 大 | 中 | 系統汰換、架構遷移 |
-| **防腐層** | 中 | 低 | 新舊系統共存 |
-| **抽象分支** | 大 | 中 | 主幹上的長期重構 |
-| **平行變更** | 中 | 低 | 介面/Schema 遷移 |
-| **特徵測試** | — | — | **所有遺留重構的前置條件** |
-| **探針式重構** | 小 | 低 | 理解黑盒程式碼 |
-
-### 策略選擇指南
-
-```
-你的情境是什麼？
-
-功能開發被混亂程式碼阻擋？
-└─► 預備性重構
-
-在 Bug 修復中接觸程式碼？
-└─► 童子軍規則
-
-用 TDD 寫新程式碼？
-└─► 紅-綠-重構
-
-取代整個遺留系統？
-└─► 絞殺榕模式
+## 重構安全網
 
-需要整合遺留而不被污染？
-└─► 防腐層
+在重構遺留程式碼 (Legacy Code) 前，必須建立安全網：
 
-在主幹上重構共享程式碼？
-└─► 抽象分支
-
-變更被廣泛使用的介面？
-└─► 平行變更（Expand-Migrate-Contract）
-
-處理未測試的遺留程式碼？
-└─► 先用特徵測試 + 探針式重構
-```
+1. **確認現有測試**: 如果沒有測試，先寫測試（特徵測試 Characterization Tests）。
+2. **自動化執行**: 確保測試可以一鍵執行且快速回饋。
+3. **版本控制**: 確保在乾淨的 Git 狀態下開始。
 
 ---
 
 ## 相關標準
 
-- [測試驅動開發](test-driven-development.md) - TDD 循環包含重構階段
-- [程式碼審查清單](code-review-checklist.md) - 重構 PR 審查指引
-- [提交訊息指南](commit-message-guide.md) - `refactor` 提交類型
-- [程式碼簽入標準](checkin-standards.md) - 提交前要求
-
----
-
-## 參考資料
-
-### 書籍
-
-- Martin Fowler -《重構：改善既有程式的設計》第二版（2018）
-- Michael Feathers -《Working Effectively with Legacy Code》（2004）
-- Joshua Kerievsky -《Refactoring to Patterns》（2004）
-- Kent Beck -《Implementation Patterns》（2007）
-- Robert C. Martin -《Clean Code》（2008）
-- Eric Evans -《Domain-Driven Design》（2003）
-
-### 文章
-
-- Martin Fowler - [Strangler Fig Application](https://martinfowler.com/bliki/StranglerFigApplication.html)
-- Martin Fowler - [Branch by Abstraction](https://martinfowler.com/bliki/BranchByAbstraction.html)
-- Martin Fowler - [Preparatory Refactoring](https://martinfowler.com/articles/preparatory-refactoring-example.html)
-- Pete Hodgson - [Feature Toggles](https://martinfowler.com/articles/feature-toggles.html)
-- Martin Fowler - [Technical Debt Quadrant](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)
-
-### 工具
-
-- [Refactoring Guru](https://refactoring.guru/) - 重構技術目錄
-- [SonarQube](https://www.sonarqube.org/) - 程式碼品質與複雜度分析
-- [ApprovalTests](https://approvaltests.com/) - Golden Master 測試
+- [重構指南](guides/refactoring-guide.md) - 詳細模式與教學
+- [測試標準](testing-standards.md)
+- [程式碼審查清單](code-review-checklist.md)
 
 ---
 
-## 版本歷程
+## 版本歷史
 
 | 版本 | 日期 | 變更 |
-|-----|------|------|
-| 2.0.0 | 2026-01-21 | 重大重構：新增戰術性策略（預備性重構、童子軍規則）、防腐層、決策矩陣摘要。重組為戰術性/戰略性/安全防護三層分類。 |
-| 1.0.0 | 2026-01-12 | 初始重構標準定義 |
+|------|------|------|
+| 2.0.0 | 2026-01-29 | **重大重構**：拆分為規則（本文件）和指南（refactoring-guide.md）。 |
+| 1.0.0 | 2025-12-15 | 初始版本 |
 
 ---
 
 ## 授權
 
-本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權釋出。
+本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權發布。