code-refactor
npx machina-cli add skill u9401066/template-is-all-you-need/code-refactor --openclaw程式碼重構技能
描述
主動偵測並執行程式碼重構,維持 DDD 架構和程式碼品質。
觸發條件
- 「重構這段程式碼」、「refactor」
- 「這個檔案太長了」
- 「模組化」、「拆分」
- 主動觸發:偵測到程式碼超過閾值時
核心原則
📜 依據憲法第 7.3 條「主動重構原則」
重構不是改天換地,而是持續的小步快跑
每次提交都應該比上次更乾淨
閾值設定
📏 長度閾值
| 類型 | 警告 | 強制重構 |
|---|---|---|
| 檔案 | > 200 行 | > 400 行 |
| 類別 | > 150 行 | > 300 行 |
| 函數 | > 30 行 | > 50 行 |
| 目錄檔案數 | > 10 個 | > 15 個 |
🔄 複雜度閾值
| 指標 | 警告 | 強制重構 |
|---|---|---|
| 圈複雜度 | > 10 | > 15 |
| 巢狀深度 | > 3 層 | > 4 層 |
| 參數數量 | > 4 個 | > 6 個 |
| 依賴數量 | > 5 個 | > 8 個 |
重構模式庫
1️⃣ Extract Method(提取方法)
觸發條件:函數過長、重複邏輯
# Before
def process_order(order):
# 驗證訂單 (10 行)
if not order.items:
raise ValueError("Empty order")
if order.total < 0:
raise ValueError("Invalid total")
# ... 更多驗證
# 計算價格 (15 行)
subtotal = sum(item.price * item.qty for item in order.items)
tax = subtotal * 0.05
total = subtotal + tax
# ... 更多計算
# 儲存訂單 (10 行)
# ...
# After
def process_order(order):
self._validate_order(order)
total = self._calculate_total(order)
self._save_order(order, total)
def _validate_order(self, order):
"""驗證訂單有效性"""
if not order.items:
raise ValueError("Empty order")
# ...
def _calculate_total(self, order) -> Decimal:
"""計算訂單總金額(含稅)"""
subtotal = sum(item.price * item.qty for item in order.items)
return subtotal * Decimal("1.05")
2️⃣ Extract Class(提取類別)
觸發條件:類別職責過多、超過 150 行
# Before: User 類別包含太多職責
class User:
def __init__(self, name, email, ...):
self.name = name
self.email = email
self.address_line1 = ...
self.address_line2 = ...
self.city = ...
self.postal_code = ...
def validate_email(self): ...
def format_address(self): ...
def calculate_shipping(self): ...
# After: 提取 Address 值物件
@dataclass(frozen=True)
class Address:
"""地址值物件"""
line1: str
line2: str | None
city: str
postal_code: str
def format(self) -> str:
return f"{self.line1}\n{self.city} {self.postal_code}"
class User:
def __init__(self, name: str, email: Email, address: Address):
self.name = name
self.email = email
self.address = address
3️⃣ Replace Conditional with Polymorphism(多態取代條件)
觸發條件:大量 if-elif-else 或 switch
# Before: 條件地獄
def calculate_shipping(order):
if order.shipping_type == "standard":
return order.weight * 10
elif order.shipping_type == "express":
return order.weight * 25 + 50
elif order.shipping_type == "overnight":
return order.weight * 50 + 100
elif order.shipping_type == "international":
# 複雜計算...
pass
# After: 策略模式
class ShippingStrategy(ABC):
@abstractmethod
def calculate(self, order) -> Decimal: ...
class StandardShipping(ShippingStrategy):
def calculate(self, order) -> Decimal:
return order.weight * 10
class ExpressShipping(ShippingStrategy):
def calculate(self, order) -> Decimal:
return order.weight * 25 + 50
# 使用
shipping_strategies = {
"standard": StandardShipping(),
"express": ExpressShipping(),
# ...
}
cost = shipping_strategies[order.shipping_type].calculate(order)
4️⃣ Introduce Parameter Object(參數物件)
觸發條件:參數超過 4 個
# Before: 參數過多
def create_user(
name: str,
email: str,
phone: str,
address_line1: str,
address_line2: str,
city: str,
postal_code: str,
country: str,
):
...
# After: 使用參數物件
@dataclass
class CreateUserCommand:
name: str
email: str
phone: str
address: Address
def create_user(command: CreateUserCommand):
...
5️⃣ Split Module(拆分模組)
觸發條件:目錄超過 10 個檔案
# Before
src/Domain/
├── User.py
├── Order.py
├── Product.py
├── Payment.py
├── Shipping.py
├── Review.py
├── Coupon.py
├── Notification.py
├── ... # 太多了!
# After: 按子領域拆分
src/Domain/
├── Identity/
│ └── User.py
├── Ordering/
│ ├── Order.py
│ └── Payment.py
├── Catalog/
│ ├── Product.py
│ └── Review.py
├── Promotion/
│ └── Coupon.py
└── Communication/
└── Notification.py
DDD 架構守護
重構時必須檢查是否違反 DDD 原則:
❌ 常見違規
# 違規 1: Domain 層依賴 Infrastructure
# Domain/Services/OrderService.py
from infrastructure.database import db # ❌ 禁止!
# 違規 2: Presentation 直接存取 Domain
# Presentation/API/routes.py
from domain.repositories import UserRepository # ❌ 應透過 Application
# 違規 3: Entity 包含持久化邏輯
class User:
def save(self): # ❌ 應在 Repository
db.session.add(self)
✅ 正確依賴方向
Presentation → Application → Domain
↓
Infrastructure
重構流程
1️⃣ 偵測階段
🔍 偵測到重構需求:
- 檔案:`src/domain/services/order_service.py`
- 問題:檔案長度 342 行(超過 200 行警告閾值)
- 複雜度:圈複雜度 12(超過 10 警告閾值)
2️⃣ 分析階段
📊 分析結果:
- `process_order()` 函數 85 行,建議拆分
- 發現 3 處重複邏輯,建議提取
- 識別出 2 個隱藏的 Value Object
3️⃣ 規劃階段
📋 重構計畫:
1. 提取 `OrderValidator` 類別
2. 提取 `PricingCalculator` 服務
3. 建立 `OrderStatus` Value Object
4. 更新測試確保覆蓋
4️⃣ 執行階段
🔧 執行重構:
- [x] 建立 `OrderValidator` 類別
- [x] 遷移驗證邏輯
- [x] 更新測試
- [x] 確認測試通過
- [ ] 提取 `PricingCalculator`
- [ ] ...
5️⃣ 驗證階段
✅ 重構完成:
- 測試:全部通過(42/42)
- 覆蓋率:85%(+3%)
- 複雜度:8(-4)
- 架構:符合 DDD ✓
主動建議範本
當偵測到需要重構時,AI 應主動建議:
💡 **重構建議**
偵測到 `order_service.py` 已達 250 行,建議進行模組化:
### 建議拆分方案
| 新檔案 | 內容 | 行數 |
|--------|------|------|
| `order_validator.py` | 訂單驗證邏輯 | ~50 行 |
| `pricing_calculator.py` | 價格計算邏輯 | ~60 行 |
| `order_service.py` | 服務編排 | ~80 行 |
### 預期效益
- ✅ 單一職責原則
- ✅ 更易測試
- ✅ 降低認知負荷
是否要我執行這個重構?
與其他 Skills 整合
| Skill | 整合方式 |
|---|---|
code-reviewer | 審查時觸發重構建議 |
test-generator | 重構前先生成測試 |
ddd-architect | 確保重構符合 DDD |
memory-updater | 記錄重構決策 |
Source
git clone https://github.com/u9401066/template-is-all-you-need/blob/master/.claude/skills/code-refactor/SKILL.mdView on GitHub Overview
Code-refactor automatically detects when code grows too long or becomes too complex and executes targeted refactors to uphold a clean DDD architecture and high-quality code. It uses refactoring patterns such as Extract Method, Extract Class, and Replace Conditional with Polymorphism to keep modules modular and easier to maintain.
How This Skill Works
The agent monitors length and complexity thresholds and analyzes files, classes, and functions to identify refactoring opportunities. When a threshold is exceeded, it selects an appropriate pattern from the refactoring library and applies changes through approved tools like read_file, write_file, and replace_string_in_file, then suggests tests to validate behavior.
When to Use It
- A file exceeds 200 lines (warning) or 400 lines (force refactor)
- A class grows beyond 150 lines or accumulates too many responsibilities
- A function exceeds 30 lines (warning) or 50 lines (force refactor)
- Complexity metrics such as cyclomatic complexity > 10 (warning) or > 15 (force refactor)
- Many parameters or dependencies, e.g., 4+ parameters or 5+ dependencies
Quick Start
- Step 1: Detect long blocks or high complexity using code metrics
- Step 2: Choose a refactor pattern (Extract Method, Extract Class, etc.) and apply via allowed tools
- Step 3: Run the test suite and review diffs before committing in small, incremental steps
Best Practices
- Start with small, localized extractions to preserve behavior
- Prefer extracting classes when a single class has too many responsibilities
- Replace long conditionals with a strategy or polymorphism
- Introduce parameter objects when a function takes more than four parameters
- Run tests and review diffs before committing, keeping changes incremental
Example Use Cases
- Refactor process_order by splitting into _validate_order, _calculate_total, and _save_order
- Extract Address as a value object to replace scattered address fields in User
- Replace a long shipping calculation with a strategy-based approach for each shipping_type
- Group related parameters into a ShippingConfig object to reduce parameter count
- Modularize a large utility class into focused classes handling validation, formatting, and persistence