python-refactor

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Python Refactor

Python 代码重构

Purpose

目标

Transform complex, hard-to-understand code into clear, well-documented, maintainable code while preserving correctness. This skill guides systematic refactoring that prioritizes human comprehension without sacrificing correctness or reasonable performance.
将复杂、难以理解的代码转换为清晰、文档完善、可维护的代码,同时保留代码正确性。本技能指导系统化的重构工作,优先保障代码的人类可读性,同时不牺牲正确性或合理性能。

When to Invoke

调用时机

Invoke this skill when:
  • User explicitly requests "human", "readable", "maintainable", "clean", or "refactor" code improvements
  • Code review processes flag comprehension or maintainability issues
  • Working with legacy code that needs modernization
  • Preparing code for team onboarding or educational contexts
  • Code complexity metrics exceed reasonable thresholds
  • Functions or modules are difficult to understand or modify
  • 🚨 RED FLAG: You see any of these spaghetti code indicators:
    • File >500 lines with scattered functions and global state
    • Multiple
      global
      statements throughout the code
    • Functions with hard-coded dependencies (no dependency injection)
    • No clear module/class organization
    • Dict/list manipulation instead of proper domain objects
    • Configuration mixed with business logic
Do NOT invoke this skill when:
  • Code is performance-critical and profiling shows optimization is needed first
  • Code is scheduled for deletion or replacement
  • External dependencies require upstream contributions instead
  • User explicitly requests performance optimization over readability
在以下场景调用本技能:
  • 用户明确要求对代码进行“人性化”“可读”“可维护”“整洁”或“重构”改进
  • 代码评审流程中标记出理解性或可维护性问题
  • 处理需要现代化改造的遗留代码
  • 为团队入职或教育场景准备代码
  • 代码复杂度指标超出合理阈值
  • 函数或模块难以理解或修改
  • 🚨 危险信号:出现以下任何面条代码特征:
    • 超过500行的文件,包含零散函数和全局状态
    • 代码中多处使用
      global
      语句
    • 函数存在硬编码依赖(未使用依赖注入)
    • 没有清晰的模块/类组织结构
    • 使用字典/列表操作替代合适的领域对象
    • 配置与业务逻辑混合
请勿在以下场景调用本技能:
  • 代码对性能要求极高,且性能分析显示需优先优化
  • 代码已计划删除或替换
  • 问题代码属于外部依赖,需向上游贡献修改
  • 用户明确要求优先性能优化而非可读性

Core Principles

核心原则

Follow these principles in priority order:
  1. CLASS-BASED ARCHITECTURE IS MANDATORY - ALWAYS prefer proper class-based OOP architecture over long messy spaghetti code scripts. Transform any procedural "script-like" code into well-structured OOP with proper classes, modules, and interfaces. This is NON-NEGOTIABLE.
    • NEVER accept: Globals, scattered functions, 1000+ line scripts, no clear structure
    • ALWAYS create: Classes with clear responsibilities, dependency injection, proper modules
  2. Clarity over cleverness - Explicit, obvious code beats implicit, clever code
  3. Preserve correctness - All tests must pass; behavior must remain identical
  4. Single Responsibility - Each class and function should do one thing well (SOLID principles)
  5. Self-documenting structure - Code structure tells what, comments explain why
  6. Progressive disclosure - Reveal complexity in layers, not all at once
  7. Reasonable performance - Never sacrifice >2x performance without explicit approval
按以下优先级遵循这些原则:
  1. 必须采用基于类的架构 - 始终优先选择规范的基于类的OOP架构,而非冗长混乱的面条代码脚本。 将任何过程式“类脚本”代码转换为结构清晰的OOP代码,包含规范的类、模块和接口。这是硬性要求,无协商空间。
    • 绝对不接受:全局变量、零散函数、1000+行的脚本、无清晰结构的代码
    • 必须实现:职责清晰的类、依赖注入、规范的模块
  2. 清晰优于技巧 - 显式、直白的代码优于隐式、花哨的代码
  3. 保留正确性 - 所有测试必须通过;行为必须保持一致
  4. 单一职责 - 每个类和函数应专注做好一件事(SOLID原则)
  5. 自文档化结构 - 代码结构说明“做什么”,注释解释“为什么”
  6. 渐进式披露 - 分层展示复杂度,而非一次性全部暴露
  7. 合理性能 - 未经明确批准,性能损耗不得超过2倍

Key Constraints

关键约束

ALWAYS observe these constraints:
  • SAFETY BY DESIGN - Use mandatory migration checklists for destructive changes. Create new structure → Search all usages → Migrate all → Verify → Only then remove old code. NEVER remove code before 100% migration verified.
  • STATIC ANALYSIS FIRST - Run
    flake8 --select=F821,E0602
    before tests to catch NameErrors immediately
  • OOP-ORIENTED ARCHITECTURE - Transform script-like code into proper OOP with classes, modules, and clear boundaries. Avoid global state, scattered functions, and spaghetti code
  • PRESERVE BEHAVIOR - All existing tests must pass after refactoring
  • NO PERFORMANCE REGRESSION - Never degrade performance >2x without explicit user approval
  • NO API CHANGES - Public APIs remain unchanged unless explicitly requested and documented
  • NO OVER-ENGINEERING - Simple code stays simple; don't add unnecessary abstraction (but DO structure code properly)
  • NO MAGIC - No framework magic, no metaprogramming unless absolutely necessary
  • VALIDATE CONTINUOUSLY - Run static analysis + tests after each logical change
必须始终遵守以下约束:
  • 设计保障安全 - 对破坏性变更使用强制迁移检查清单。创建新结构 → 搜索所有引用 → 迁移全部引用 → 验证 → 仅在完成后删除旧代码。未100%验证迁移完成前,绝对不能删除旧代码。
  • 先做静态分析 - 运行
    flake8 --select=F821,E0602
    后再执行测试,立即捕获NameError
  • 面向OOP的架构 - 将类脚本代码转换为规范的OOP代码,包含类、模块和清晰的边界。避免全局状态、零散函数和面条代码
  • 保留行为 - 重构后所有现有测试必须通过
  • 无性能退化 - 未经用户明确批准,性能下降不得超过2倍
  • 无API变更 - 公共API保持不变,除非用户明确要求并已记录
  • 不过度设计 - 简单代码保持简洁;不要添加不必要的抽象(但必须合理组织代码结构)
  • 无魔法操作 - 除非绝对必要,否则不使用框架魔法、元编程
  • 持续验证 - 每次逻辑变更后运行静态分析+测试

⛔ REGRESSION PREVENTION (MANDATORY)

⛔ 防止回归(强制要求)

IL REFACTORING NON DEVE MAI INTRODURRE REGRESSIONI TECNICHE, LOGICHE O FUNZIONALI.
Prima di qualsiasi refactoring, leggi e applica
references/REGRESSION_PREVENTION.md
.
代码重构绝对不能引入技术、逻辑或功能回归。
在进行任何重构前,请阅读并执行
references/REGRESSION_PREVENTION.md
中的内容。

Quick Safety Checklist

快速安全检查清单

PRIMA di ogni sessione di refactoring:
□ Test suite passa al 100%?
□ Coverage >= 80% su codice target? (se no → scrivi test PRIMA)
□ Golden outputs catturati per edge cases critici?
□ Static analysis baseline salvata?
DOPO ogni micro-cambiamento (non alla fine, OGNI SINGOLO!):
□ flake8 --select=F821,E999 → 0 errori?
□ pytest -x → tutti passano?
□ Comportamento invariato? (spot check 1 edge case)
Se QUALSIASI check fallisce:
→ STOP → REVERT → ANALYZE → FIX APPROACH → RETRY
每次重构会话开始前:
□ 测试套件100%通过?
□ 目标代码覆盖率≥80%?(如果没有 → 先编写测试)
□ 已捕获关键边缘场景的标准输出?
□ 已保存静态分析基线?
每次微变更后(不是最后,而是每一次!):
□ flake8 --select=F821,E999 → 0错误?
□ pytest -x → 全部通过?
□ 行为未改变?(抽查1个边缘场景)
如果任何检查失败:
→ 停止 → 回滚 → 分析 → 修正方案 → 重试

Le regole fondamentali:

核心规则:

  1. Test coverage >= 80% sulle funzioni target, altrimenti scrivi test PRIMA
  2. Golden outputs catturati per edge cases critici prima di toccare il codice
  3. Static analysis PRIMA dei test dopo ogni micro-change:
    flake8 --select=F821,E999
  4. Rollback immediato se qualsiasi test fallisce - non procedere mai
⛔ QUALSIASI REGRESSIONE = FALLIMENTO TOTALE DEL REFACTORING ⛔
  1. 目标函数测试覆盖率≥80%,否则先编写测试
  2. 修改代码前,为关键边缘场景捕获标准输出
  3. 每次微变更后,先做静态分析再执行测试:
    flake8 --select=F821,E999
  4. 任何测试失败立即回滚 - 绝对不要继续
⛔ 任何回归 = 重构完全失败 ⛔

Refactoring Workflow

重构工作流

Execute refactoring in four phases with validation at each step.
分四个阶段执行重构,每个阶段都包含验证步骤。

Phase 1: Analysis

阶段1:分析

Before making any changes, analyze the code comprehensively:
CRITICAL FIRST CHECK - Script vs OOP Architecture:
Ask yourself: "Is this code structured as a proper OOP system or is it a messy script?"
python
undefined
在进行任何变更前,全面分析代码:
关键首次检查 - 脚本式 vs OOP架构:
自问:“这段代码是作为规范的OOP系统构建的,还是混乱的脚本?”
python
undefined

❌ UNACCEPTABLE - Script-like spaghetti code

❌ 不可接受 - 类脚本面条代码

1500-line file with:

1500行的文件包含:

users_cache = {} # Global state API_URL = "https://..." # Global config
def fetch_user(user_id): # Scattered function global users_cache # ...
def validate_user(data): # Another scattered function # ...
def save_to_db(data): # Yet another scattered function # Hard-coded dependencies # ...
users_cache = {} # 全局状态 API_URL = "https://..." # 全局配置
def fetch_user(user_id): # 零散函数 global users_cache # ...
def validate_user(data): # 另一个零散函数 # ...
def save_to_db(data): # 又一个零散函数 # 硬编码依赖 # ...

50+ more scattered functions...

还有50+个零散函数...


```python

```python

✅ REQUIRED - Proper class-based architecture

✅ 要求的结构 - 规范的基于类的架构

Organized modules:

组织化的模块:

project/

project/

models/user.py

models/user.py

repositories/user_repository.py

repositories/user_repository.py

services/user_service.py

services/user_service.py

clients/api_client.py

clients/api_client.py

from dataclasses import dataclass from typing import Protocol
@dataclass class User: id: int email: str
class UserRepository: def init(self, api_client: APIClient): self._api_client = api_client self._cache: dict[int, User] = {}
def get_by_id(self, user_id: int) -> Optional[User]:
    # Encapsulated state, clear responsibility
    pass
class UserService: def init(self, user_repo: UserRepository, db_repo: DatabaseRepository): self._user_repo = user_repo self._db_repo = db_repo
def process_user(self, user_id: int):
    # Dependency injection, testable, clear
    pass

**If you find script-like code → Transformation to OOP is MANDATORY, not optional!**

1. **Read the entire codebase section** being refactored to understand context
2. **Identify readability issues** using the anti-patterns reference (see `references/anti-patterns.md`):
   - **CRITICAL**: Check for script-like/procedural code (anti-pattern #1) - global state, scattered functions, no clear structure
   - **CRITICAL**: Check for God Objects/Classes (anti-pattern #2) - classes doing too much
   - Complex nested conditionals, long functions, magic numbers, cryptic names, etc.
3. **Assess OOP architecture** (see `references/oop_principles.md`):
   - Is code organized in proper classes and modules?
   - Is there global state that should be encapsulated?
   - Are responsibilities properly separated (models, repositories, services)?
   - Are SOLID principles followed?
   - Is dependency injection used instead of hard-coded dependencies?
4. **Measure current metrics**:
   - Cyclomatic complexity per function (use `scripts/measure_complexity.py`)
   - Function length (lines of code)
   - Documentation coverage (docstrings, type hints)
   - Nesting depth
5. **Run flake8 analysis** for comprehensive code quality assessment:
   ```bash
   python scripts/analyze_with_flake8.py <target> \
       --output before_flake8.json \
       --html before_flake8.html
This provides:
  • Style violations (PEP 8)
  • Potential bugs (Bugbear plugin)
  • Complexity issues (McCabe, Cognitive)
  • Missing docstrings (pydocstyle)
  • Type annotation coverage
  • Code simplification opportunities
  • Naming convention violations
  1. Check test coverage - Identify gaps that need filling before refactoring
  2. Document findings using the analysis template (see
    assets/templates/analysis_template.md
    )
Output: Prioritized list of issues by impact and risk, including flake8 report.
from dataclasses import dataclass from typing import Protocol
@dataclass class User: id: int email: str
class UserRepository: def init(self, api_client: APIClient): self._api_client = api_client self._cache: dict[int, User] = {}
def get_by_id(self, user_id: int) -> Optional[User]:
    # 封装的状态,清晰的职责
    pass
class UserService: def init(self, user_repo: UserRepository, db_repo: DatabaseRepository): self._user_repo = user_repo self._db_repo = db_repo
def process_user(self, user_id: int):
    # 依赖注入,可测试,清晰
    pass

**如果发现类脚本代码 → 必须转换为OOP架构,而非可选操作!**

1. **阅读待重构的整个代码库部分**,理解上下文
2. **使用反模式参考文档识别可读性问题**(见`references/anti-patterns.md`):
   - **关键**:检查类脚本/过程式代码(反模式#1)- 全局状态、零散函数、无清晰结构
   - **关键**:检查上帝对象/类(反模式#2)- 承担过多职责的类
   - 复杂嵌套条件、长函数、魔法数字、晦涩命名等
3. **评估OOP架构**(见`references/oop_principles.md`):
   - 代码是否按规范的类和模块组织?
   - 是否存在应封装的全局状态?
   - 职责是否已合理分离(模型、仓库、服务)?
   - 是否遵循SOLID原则?
   - 是否使用依赖注入替代硬编码依赖?
4. **测量当前指标**:
   - 每个函数的圈复杂度(使用`scripts/measure_complexity.py`)
   - 函数长度(代码行数)
   - 文档覆盖率(文档字符串、类型提示)
   - 嵌套深度
5. **运行flake8分析**进行全面代码质量评估:
   ```bash
   python scripts/analyze_with_flake8.py <target> \
       --output before_flake8.json \
       --html before_flake8.html
分析内容包括:
  • 风格违规(PEP 8)
  • 潜在bug(Bugbear插件)
  • 复杂度问题(McCabe、认知复杂度)
  • 缺失的文档字符串(pydocstyle)
  • 类型注释覆盖率
  • 代码简化机会
  • 命名规范违规
  1. 检查测试覆盖率 - 识别重构前需要补充的测试缺口
  2. 使用分析模板记录发现(见
    assets/templates/analysis_template.md
输出结果:按影响和风险优先级排序的问题列表,包含flake8报告。

Phase 2: Planning

阶段2:规划

Plan the refactoring approach systematically with safety-by-design:
  1. Identify changes by type:
    • Non-destructive: Renames, documentation, type hints → Low risk
    • Destructive: Removing globals, deleting functions, replacing APIs → High risk
  2. For DESTRUCTIVE changes - CREATE MIGRATION PLAN (MANDATORY):
    bash
    # For each element to be removed, search for ALL usages
    grep -rn "<element_name>" --include="*.py" > migration_plan_<element>.txt
    grep -rn "<element_name>\[" --include="*.py" >> migration_plan_<element>.txt
    grep -rn "<element_name>\." --include="*.py" >> migration_plan_<element>.txt
    Document findings:
    markdown
    ## Removal Plan: <element_name>
    
    ### Total Usages Found: X
    ### Files Affected: Y
    ### Estimated Migration Effort: Z hours
    
    ### Detailed Usage List:
    - file.py:123 - function_name() - [usage type]
    - file.py:456 - another_function() - [usage type]
    ...
    
    ### Migration Strategy:
    1. Create replacement structure
    2. Migrate usages in this order: [list]
    3. Verify with static analysis
    4. Remove old code
    
    ### Risk Level: [High/Medium/Low]
    PROHIBITION: If you cannot create this migration plan with complete usage accounting, you CANNOT proceed with the destructive change. Defer it or choose safer approach.
  3. Risk assessment for each proposed change (Low/Medium/High)
  4. Dependency identification - What else depends on this code?
  5. Test strategy - What tests are needed? What might break?
  6. Change ordering - Sequence changes from safest to riskiest
  7. Expected outcomes - Document what metrics should improve and by how much
Output: Refactoring plan with:
  • Sequenced changes with risk levels
  • Complete migration plans for ALL destructive changes (with usage counts)
  • Test strategy
  • Fallback/rollback plan
系统规划重构方案,以设计保障安全
  1. 按类型识别变更
    • 非破坏性:重命名、文档、类型提示 → 低风险
    • 破坏性:删除全局变量、删除函数、替换API → 高风险
  2. 对于破坏性变更 - 创建迁移计划(强制要求)
    bash
    # 对于每个要删除的元素,搜索所有引用
    grep -rn "<element_name>" --include="*.py" > migration_plan_<element>.txt
    grep -rn "<element_name>\[" --include="*.py" >> migration_plan_<element>.txt
    grep -rn "<element_name>\." --include="*.py" >> migration_plan_<element>.txt
    记录发现:
    markdown
    ## 删除计划:<element_name>
    
    ### 找到的引用总数:X
    ### 受影响的文件数:Y
    ### 预估迁移工作量:Z小时
    
    ### 详细引用列表:
    - file.py:123 - function_name() - [引用类型]
    - file.py:456 - another_function() - [引用类型]
    ...
    
    ### 迁移策略:
    1. 创建替代结构
    2. 按以下顺序迁移引用:[列表]
    3. 静态分析验证
    4. 删除旧代码
    
    ### 风险等级:[高/中/低]
    禁止:如果无法创建包含完整引用统计的迁移计划,则不能进行破坏性变更。请推迟或选择更安全的方案。
  3. 对每个拟议变更进行风险评估(低/中/高)
  4. 识别依赖关系 - 哪些其他代码依赖于当前代码?
  5. 测试策略 - 需要哪些测试?哪些部分可能出错?
  6. 变更排序 - 按从最安全到最危险的顺序排列变更
  7. 预期结果 - 记录哪些指标应得到改善,以及改善幅度
输出结果:重构计划,包含:
  • 按风险等级排序的变更序列
  • 所有破坏性变更的完整迁移计划(含引用计数)
  • 测试策略
  • 回退/滚回计划

Phase 3: Execution

阶段3:执行

Apply refactoring patterns using safety-by-design workflow that prevents incomplete migration:
使用以设计保障安全的工作流应用重构模式,防止不完整迁移:

Safe Refactoring Workflow (MANDATORY ORDER)

安全重构工作流(必须按顺序执行)

For NON-DESTRUCTIVE changes (safe to do anytime):
  1. Rename variables/functions for clarity
  2. Extract magic numbers/strings to named constants
  3. Add/improve documentation and type hints
  4. Add guard clauses to reduce nesting
For DESTRUCTIVE changes (removing/replacing code) - STRICT PROTOCOL:
This protocol makes incomplete migration structurally impossible:
Step 1: CREATE new structure (no removal yet)
  • Write new classes/functions/services
  • Add tests for new structure
  • DO NOT remove or modify old code yet
Step 2: SEARCH comprehensively for ALL usages
bash
undefined
对于非破坏性变更(任何时候都可安全执行):
  1. 重命名变量/函数以提升清晰度
  2. 将魔法数字/字符串提取为命名常量
  3. 添加/完善文档和类型提示
  4. 添加卫语句以减少嵌套
对于破坏性变更(删除/替换代码) - 严格执行协议:
本协议从结构上杜绝不完整迁移的可能:
步骤1:创建新结构(暂不删除旧代码)
  • 编写新的类/函数/服务
  • 为新结构添加测试
  • 暂不删除或修改旧代码
步骤2:全面搜索所有引用
bash
undefined

Example: Removing global variable "sse_connections"

示例:删除全局变量"sse_connections"

Search for exact name

搜索精确名称

grep -rn "sse_connections" --include="*.py" > migration_checklist.txt
grep -rn "sse_connections" --include="*.py" > migration_checklist.txt

Search for common access patterns

搜索常见访问模式

grep -rn "sse_connections[" --include=".py" >> migration_checklist.txt grep -rn "sse_connections." --include=".py" >> migration_checklist.txt grep -rn "_get_sse_connections" --include="*.py" >> migration_checklist.txt
grep -rn "sse_connections[" --include=".py" >> migration_checklist.txt grep -rn "sse_connections." --include=".py" >> migration_checklist.txt grep -rn "_get_sse_connections" --include="*.py" >> migration_checklist.txt

Review ALL results - every line must be accounted for

检查所有结果 - 每一行都必须记录


**Step 3: CREATE migration checklist**
```markdown

**步骤3:创建迁移检查清单**
```markdown

Migration: sse_connections → SSEManagerService._connections

迁移:sse_connections → SSEManagerService._connections

Found Usages (from grep):

找到的引用(来自grep):

  • rest_api_channel_api.py:456 - broadcast_sse_event() - helper function
  • rest_api_channel_api.py:1234 - cleanup_sse_connections() - helper function
  • rest_api_channel_api.py:1916 - stream_positions() route - DIRECT ACCESS
  • rest_api_channel_api.py:1945 - stream_signals() route - DIRECT ACCESS
  • rest_api_channel_api.py:1978 - stream_agents() route - DIRECT ACCESS
  • rest_api_channel_api.py:2001 - stream_orders() route - DIRECT ACCESS
Total: 6 locations requiring migration
  • rest_api_channel_api.py:456 - broadcast_sse_event() - 辅助函数
  • rest_api_channel_api.py:1234 - cleanup_sse_connections() - 辅助函数
  • rest_api_channel_api.py:1916 - stream_positions() 路由 - 直接访问
  • rest_api_channel_api.py:1945 - stream_signals() 路由 - 直接访问
  • rest_api_channel_api.py:1978 - stream_agents() 路由 - 直接访问
  • rest_api_channel_api.py:2001 - stream_orders() 路由 - 直接访问
总计:6处需要迁移的位置

Migration Status: 0/6 complete - CANNOT REMOVE YET

迁移状态:0/6 完成 - 暂不能删除旧代码


**Step 4: MIGRATE one usage at a time**
- Update ONE usage to use new structure
- Check off in migration checklist
- Run static analysis: `flake8 <file> --select=F821,E0602`
- Run tests
- Commit with message: "refactor: migrate broadcast_sse_event to SSEManagerService (1/6)"

**Step 5: VERIFY complete migration**
- Checklist shows 6/6 complete
- Re-run original grep searches - should find ZERO matches (except in new code)
- Run static analysis one final time before removal

**Step 6: REMOVE old code (ONLY after 100% migration verified)**
- Comment out old code first (safety net)
- Run static analysis: `flake8 <file> --select=F821,E0602` - MUST show zero errors
- Run full test suite - MUST pass 100%
- If both pass, permanently delete commented code
- Commit with message: "refactor: remove obsolete sse_connections global (migration complete)"

**步骤4:逐个迁移引用**
- 更新一处引用以使用新结构
- 在检查清单中标记完成
- 运行静态分析:`flake8 <file> --select=F821,E0602`
- 运行测试
- 提交时使用如下信息:"refactor: migrate broadcast_sse_event to SSEManagerService (1/6)"

**步骤5:验证迁移完成**
- 检查清单显示6/6完成
- 重新运行最初的grep搜索 - 应找到0个匹配项(新代码中的引用除外)
- 删除前最后一次运行静态分析

**步骤6:删除旧代码(仅在100%验证迁移完成后)**
- 先注释旧代码(安全网)
- 运行静态分析:`flake8 <file> --select=F821,E0602` - 必须显示0错误
- 运行完整测试套件 - 必须100%通过
- 如果两者都通过,永久删除注释的代码
- 提交时使用如下信息:"refactor: remove obsolete sse_connections global (migration complete)"

Execution Rules

执行规则

  1. NEVER skip the migration checklist - Attempting to remove code without a verified checklist is PROHIBITED
  2. Run static analysis BEFORE tests - Catch NameErrors immediately, don't wait for runtime
  3. One pattern at a time - Never mix multiple refactoring patterns in one change
  4. Atomic commits - Each migration step gets its own commit
  5. Stop on ANY error - Static analysis errors OR test failures require immediate fix/revert
Refactoring order (MANDATORY sequence):
  1. FIRST: Transform script-like code to proper OOP architecture (NON-NEGOTIABLE if code is procedural)
    • This is NOT optional - spaghetti code MUST be restructured
    • Identify ALL global state and encapsulate in classes
    • Group ALL scattered functions into proper classes (repositories, services, managers)
    • Create proper domain models (dataclasses, enums)
    • Apply dependency injection everywhere
    • Organize into proper modules with clear boundaries
    • See
      references/examples/script_to_oop_transformation.md
      for complete guide
  2. Rename variables/functions for clarity (within the new OOP structure)
  3. Extract magic numbers/strings to named constants (as class constants or enums)
  4. Add/improve documentation and type hints
  5. Extract methods to reduce function length
  6. Simplify conditionals with guard clauses
  7. Reduce nesting depth
  8. Final review: Ensure separation of concerns is clean (should be done in step 1)
Output: Refactored code passing all tests with clear commit history.
  1. 绝对不能跳过迁移检查清单 - 未使用已验证的检查清单就尝试删除代码是被禁止的
  2. 先运行静态分析再执行测试 - 立即捕获NameError,不要等到运行时
  3. 一次应用一种模式 - 不要在一次变更中混合多种重构模式
  4. 原子提交 - 每个迁移步骤单独提交
  5. 任何错误立即停止 - 静态分析错误或测试失败需立即修复/回滚
重构顺序(必须按此序列执行):
  1. 首先:将类脚本代码转换为规范的OOP架构(如果代码是过程式的,这是硬性要求,无协商空间)
    • 这不是可选操作 - 面条代码必须重构
    • 识别所有全局状态并封装到类中
    • 将所有零散函数分组到规范的类中(仓库、服务、管理器)
    • 创建规范的领域模型(数据类、枚举)
    • 全面应用依赖注入
    • 组织到规范的模块中,具有清晰的边界
    • 完整指南见
      references/examples/script_to_oop_transformation.md
  2. 在新OOP结构内重命名变量/函数以提升清晰度
  3. 将魔法数字/字符串提取为命名常量(作为类常量或枚举)
  4. 添加/完善文档和类型提示
  5. 提取方法以缩短函数长度
  6. 使用卫语句简化条件判断
  7. 减少嵌套深度
  8. 最终审查:确保关注点分离清晰(应在步骤1完成)
输出结果:通过所有测试的重构后代码,具有清晰的提交历史。

Phase 4: Validation

阶段4:验证

Validate improvements objectively:
  1. Run static analysis FIRST (catch errors before tests):
    bash
    # Check for undefined names/variables (NameError prevention)
    flake8 <file> --select=F821,E0602
    
    # Check for unused imports (cleanup verification)
    flake8 <file> --select=F401
    
    # Full quality check
    flake8 <file>
    MANDATORY: Zero F821 (undefined name) and E0602 (undefined variable) errors required
  2. Run full test suite - 100% pass rate required
  3. Validate OOP architecture improvements:
    • Confirm global state has been eliminated or properly encapsulated
    • Verify code is organized in proper modules/classes
    • Check that responsibilities are properly separated
    • Ensure dependency injection is used where appropriate
    • Validate against SOLID principles (see
      references/oop_principles.md
      )
  4. Compare before/after metrics using
    scripts/measure_complexity.py
  5. Run flake8 analysis again to measure code quality improvements:
    bash
    python scripts/analyze_with_flake8.py <target> \
        --output after_flake8.json \
        --html after_flake8.html
  6. Compare flake8 reports to quantify improvements:
    bash
    python scripts/compare_flake8_reports.py \
        before_flake8.json \
        after_flake8.json \
        --html flake8_comparison.html
    Validates:
    • Total issue reduction
    • Severity-level improvements (high/medium/low)
    • Category improvements (bugs, complexity, style, docs)
    • Fixed vs new issues
    • Code quality trend
  7. Performance regression check - Run
    scripts/benchmark_changes.py
    for hot paths
  8. Generate summary report using format from
    assets/templates/summary_template.md
  9. Flag for human review if:
    • Performance degraded >10%
    • Public API signatures changed
    • Test coverage decreased
    • Significant architectural changes were made
    • Flake8 issues increased (regression)
Output: Comprehensive validation report with:
  • Test results
  • Complexity metrics comparison
  • Flake8 before/after comparison
  • Performance benchmarks
  • Overall quality improvement summary
客观验证改进效果:
  1. 首先运行静态分析(在测试前捕获错误):
    bash
    # 检查未定义的名称/变量(防止NameError)
    flake8 <file> --select=F821,E0602
    
    # 检查未使用的导入(验证清理效果)
    flake8 <file> --select=F401
    
    # 全面质量检查
    flake8 <file>
    强制要求:必须零F821(未定义名称)和E0602(未定义变量)错误
  2. 运行完整测试套件 - 要求100%通过率
  3. 验证OOP架构改进
    • 确认全局状态已消除或被正确封装
    • 验证代码按规范的模块/类组织
    • 检查职责是否已合理分离
    • 确保在合适的地方使用了依赖注入
    • 对照SOLID原则验证(见
      references/oop_principles.md
  4. 使用
    scripts/measure_complexity.py
    比较前后指标
  5. 再次运行flake8分析以衡量代码质量改进:
    bash
    python scripts/analyze_with_flake8.py <target> \
        --output after_flake8.json \
        --html after_flake8.html
  6. 比较flake8报告以量化改进:
    bash
    python scripts/compare_flake8_reports.py \
        before_flake8.json \
        after_flake8.json \
        --html flake8_comparison.html
    验证内容包括:
    • 问题总数减少
    • 严重程度改进(高/中/低)
    • 分类改进(bug、复杂度、风格、文档)
    • 已修复问题 vs 新出现问题
    • 代码质量趋势
  7. 性能回归检查 - 对热点路径运行
    scripts/benchmark_changes.py
  8. 使用
    assets/templates/summary_template.md
    中的格式生成总结报告
  9. 如果出现以下情况,标记为需人工审查
    • 性能下降超过10%
    • 公共API签名已变更
    • 测试覆盖率下降
    • 进行了重大架构变更
    • Flake8问题增加(回归)
输出结果:全面验证报告,包含:
  • 测试结果
  • 复杂度指标对比
  • Flake8前后对比
  • 性能基准测试
  • 整体质量改进总结

Refactoring Patterns

重构模式

Apply these patterns systematically. Each pattern is documented in detail in
references/patterns.md
.
系统应用这些模式。每个模式的详细文档见
references/patterns.md

Complexity Reduction Patterns

复杂度降低模式

Guard Clauses - Replace nested conditionals with early returns:
python
undefined
卫语句 - 用提前返回替代嵌套条件:
python
undefined

Before

重构前

def process(data): if data: if data.is_valid(): if data.has_permission(): return data.process() return None
def process(data): if data: if data.is_valid(): if data.has_permission(): return data.process() return None

After

重构后

def process(data): if not data: return None if not data.is_valid(): return None if not data.has_permission(): return None return data.process()

**Extract Method** - Split large functions into focused units:
```python
def process(data): if not data: return None if not data.is_valid(): return None if not data.has_permission(): return None return data.process()

**提取方法** - 将大函数拆分为专注的单元:
```python

Before: 50-line function doing validation, transformation, and storage

重构前:50行的函数,同时处理验证、转换和存储

After: 3 focused functions

重构后:3个专注的函数

def validate_input(data): ... def transform_data(data): ... def store_result(data): ...

**Replace Complex Conditionals** - Use named boolean methods:
```python
def validate_input(data): ... def transform_data(data): ... def store_result(data): ...

**替换复杂条件** - 使用命名布尔方法:
```python

Before

重构前

if user.age >= 18 and user.verified and not user.banned: ...
if user.age >= 18 and user.verified and not user.banned: ...

After

重构后

def can_access_feature(user): return user.age >= 18 and user.verified and not user.banned
if can_access_feature(user): ...
undefined
def can_access_feature(user): return user.age >= 18 and user.verified and not user.banned
if can_access_feature(user): ...
undefined

Cognitive Complexity Reduction Patterns

认知复杂度降低模式

See
references/cognitive_complexity_guide.md
for complete details on calculation rules and patterns.
Dictionary Dispatch - Eliminate if-elif chains:
python
undefined
完整计算规则和模式见
references/cognitive_complexity_guide.md
字典分发 - 消除if-elif链:
python
undefined

BEFORE: Cognitive Complexity = 8

重构前:认知复杂度 = 8

def process(action, data): if action == "create": # +1 return create(data) elif action == "update": # +1 return update(data) elif action == "delete": # +1 return delete(data) # ... altri 5 elif ... else: # +1 raise ValueError(f"Unknown: {action}")
def process(action, data): if action == "create": # +1 return create(data) elif action == "update": # +1 return update(data) elif action == "delete": # +1 return delete(data) # ... 另外5个elif ... else: # +1 raise ValueError(f"Unknown: {action}")

AFTER: Cognitive Complexity = 1

重构后:认知复杂度 = 1

HANDLERS = { "create": create, "update": update, "delete": delete, }
def process(action, data): handler = HANDLERS.get(action) if handler is None: # +1 unico branch raise ValueError(f"Unknown: {action}") return handler(data)

**Match Statement** (Python 3.10+) - Switch conta UNA VOLTA:
```python
HANDLERS = { "create": create, "update": update, "delete": delete, }
def process(action, data): handler = HANDLERS.get(action) if handler is None: # +1 唯一分支 raise ValueError(f"Unknown: {action}") return handler(data)

**Match语句**(Python 3.10+)- 仅+1次:
```python

BEFORE: Cognitive Complexity = 4

重构前:认知复杂度 = 4

def get_status_message(status): if status == "pending": # +1 return "In attesa" elif status == "approved": # +1 return "Approvato" elif status == "rejected": # +1 return "Rifiutato" else: # +1 return "Sconosciuto"
def get_status_message(status): if status == "pending": # +1 return "待处理" elif status == "approved": # +1 return "已批准" elif status == "rejected": # +1 return "已拒绝" else: # +1 return "未知"

AFTER: Cognitive Complexity = 1

重构后:认知复杂度 = 1

def get_status_message(status): match status: # +1 totale! case "pending": return "In attesa" case "approved": return "Approvato" case "rejected": return "Rifiutato" case _: return "Sconosciuto"

**Extract Method** - Resetta il nesting counter (pattern più potente!):
```python
def get_status_message(status): match status: # 总计+1! case "pending": return "待处理" case "approved": return "已批准" case "rejected": return "已拒绝" case _: return "未知"

**提取方法** - 重置嵌套计数器(最强大的模式!):
```python

BEFORE: Cognitive Complexity = 6

重构前:认知复杂度 = 6

def process_items(items): for item in items: # +1, nesting +1 if item.valid: # +2 (1 + nesting) if item.ready: # +3 (1 + 2×nesting) handle(item)
def process_items(items): for item in items: # +1,嵌套+1 if item.valid: # +2 (1 + 嵌套层级) if item.ready: # +3 (1 + 2×嵌套层级) handle(item)

AFTER: Cognitive Complexity = 3 totale

重构后:总认知复杂度 = 3

def process_items(items): for item in items: # +1 process_item(item)
def process_item(item): # Nesting RESETTATO a 0! if not item.valid: # +1 (no nesting penalty) return if not item.ready: # +1 (no nesting penalty) return handle(item)

**Named Boolean Conditions** - Chiarisce condizioni complesse:
```python
def process_items(items): for item in items: # +1 process_item(item)
def process_item(item): # 嵌套重置为0! if not item.valid: # +1 (无嵌套惩罚) return if not item.ready: # +1 (无嵌套惩罚) return handle(item)

**命名布尔条件** - 明确复杂条件:
```python

BEFORE: Cognitive Complexity = 3 (cambio operatore and→or)

重构前:认知复杂度 = 3(操作符从and变为or)

if user.active and user.verified or user.is_admin and not user.banned: grant_access()
if user.active and user.verified or user.is_admin and not user.banned: grant_access()

AFTER: Cognitive Complexity = 1

重构后:认知复杂度 = 1

is_regular_user_ok = user.active and user.verified is_admin_ok = user.is_admin and not user.banned if is_regular_user_ok or is_admin_ok: grant_access()

**Reduce Nesting** - Maximum 3 levels deep:
```python
is_regular_user_ok = user.active and user.verified is_admin_ok = user.is_admin and not user.banned if is_regular_user_ok or is_admin_ok: grant_access()

**减少嵌套** - 最大允许3层嵌套:
```python

Before: 5 levels of nesting

重构前:5层嵌套

After: Extract inner logic to helper functions

重构后:将内部逻辑提取到辅助函数

undefined
undefined

Naming Improvement Patterns

命名改进模式

Apply these naming conventions consistently:
Variables:
  • Descriptive names (no
    x
    ,
    tmp
    ,
    data
    unless trivial scope)
  • Booleans:
    is_active
    ,
    has_permission
    ,
    can_edit
    ,
    should_retry
  • Collections: plural nouns (
    users
    ,
    transactions
    ,
    events
    )
Functions:
  • Verb + object pattern (
    calculate_total
    ,
    validate_email
    ,
    fetch_user
    )
  • Boolean queries:
    is_valid()
    ,
    has_items()
    ,
    can_proceed()
Constants:
  • UPPERCASE_WITH_UNDERSCORES
  • Magic numbers →
    MAX_RETRY_COUNT = 3
  • Magic strings →
    DEFAULT_ENCODING = 'utf-8'
Classes:
  • PascalCase nouns (
    UserAccount
    ,
    PaymentProcessor
    )
一致应用这些命名规范:
变量:
  • 描述性名称(除非是极小作用域,否则不要使用
    x
    tmp
    data
  • 布尔值:
    is_active
    has_permission
    can_edit
    should_retry
  • 集合:复数名词(
    users
    transactions
    events
函数:
  • 动词+对象模式(
    calculate_total
    validate_email
    fetch_user
  • 布尔查询:
    is_valid()
    has_items()
    can_proceed()
常量:
  • UPPERCASE_WITH_UNDERSCORES
    格式
  • 魔法数字 →
    MAX_RETRY_COUNT = 3
  • 魔法字符串 →
    DEFAULT_ENCODING = 'utf-8'
类:
  • PascalCase格式的名词(
    UserAccount
    PaymentProcessor

Documentation Patterns

文档模式

Function Docstrings - Document purpose, not implementation:
python
def calculate_discount(price: float, user_tier: str) -> float:
    """Calculate discount amount based on user tier.

    Args:
        price: Original price before discount
        user_tier: User membership tier ('bronze', 'silver', 'gold')

    Returns:
        Discount amount to subtract from price

    Raises:
        ValueError: If user_tier is not recognized
    """
Module Documentation - Purpose and key dependencies:
python
"""User authentication and authorization module.

This module handles user login, session management, and permission
checking. Depends on the database module for user persistence and
the crypto module for password hashing.
"""
Inline Comments - Only for non-obvious "why":
python
undefined
函数文档字符串 - 记录目的,而非实现细节:
python
def calculate_discount(price: float, user_tier: str) -> float:
    """根据用户等级计算折扣金额。

    参数:
        price: 折扣前的原价
        user_tier: 用户会员等级 ('bronze', 'silver', 'gold')

    返回:
        需从原价中扣除的折扣金额

    抛出:
        ValueError: 如果user_tier未被识别
    """
模块文档 - 记录目的和关键依赖:
python
"""用户认证与授权模块。

本模块处理用户登录、会话管理和权限检查。依赖数据库模块进行用户持久化,
依赖加密模块进行密码哈希。
"""
行内注释 - 仅用于非显而易见的“原因”:
python
undefined

Use exponential backoff to avoid overwhelming the API during outages

使用指数退避以避免在故障期间压垮API

time.sleep(2 ** retry_count)

**Type Hints** - All public APIs and complex internals:
```python
from typing import List, Optional, Dict

def process_users(
    users: List[User],
    filters: Optional[Dict[str, Any]] = None
) -> List[ProcessedUser]:
    ...
time.sleep(2 ** retry_count)

**类型提示** - 所有公共API和复杂内部逻辑都需添加:
```python
from typing import List, Optional, Dict

def process_users(
    users: List[User],
    filters: Optional[Dict[str, Any]] = None
) -> List[ProcessedUser]:
    ...

Structure Improvement Patterns

结构改进模式

Extract Nested Logic:
python
undefined
提取嵌套逻辑:
python
undefined

Before: nested helper logic inline

重构前:嵌套辅助逻辑内联

def main_function(): data = fetch_data() # 10 lines of transformation logic result = transformed_data return result
def main_function(): data = fetch_data() # 10行转换逻辑 result = transformed_data return result

After: extracted to helper

重构后:提取到辅助函数

def main_function(): data = fetch_data() result = transform_data(data) return result
def transform_data(data): # 10 lines of transformation logic return transformed_data

**Group Related Functionality:**
```python
def main_function(): data = fetch_data() result = transform_data(data) return result
def transform_data(data): # 10行转换逻辑 return transformed_data

**分组相关功能:**
```python

Before: scattered validation logic

重构前:零散的验证逻辑

After: grouped in validation module or class

重构后:分组到验证模块或类中

class UserValidator: def validate_email(self, email): ... def validate_age(self, age): ... def validate_permissions(self, user): ...

**Separate Concerns:**
```python
class UserValidator: def validate_email(self, email): ... def validate_age(self, age): ... def validate_permissions(self, user): ...

**分离关注点:**
```python

Before: mixed data fetching, business logic, and presentation

重构前:混合数据获取、业务逻辑和展示

After:

重构后:

def fetch_user_data(user_id): ... # Data layer def calculate_user_metrics(data): ... # Business logic def format_user_display(metrics): ... # Presentation

**Consistent Abstraction Levels:**
```python
def fetch_user_data(user_id): ... # 数据层 def calculate_user_metrics(data): ... # 业务逻辑 def format_user_display(metrics): ... # 展示层

**一致的抽象层级:**
```python

Before: mixing high-level and low-level operations

重构前:混合高层和低层操作

def process_order(): validate_order() # Low-level: manual SQL query here # High-level: call payment service
def process_order(): validate_order() # 低层:手动SQL查询 # 高层:调用支付服务

After: consistent abstraction level

重构后:一致的抽象层级

def process_order(): validate_order() save_order_to_database() charge_payment()
undefined
def process_order(): validate_order() save_order_to_database() charge_payment()
undefined

OOP Transformation Patterns

OOP转换模式

Transform script-like "spaghetti code" into well-structured OOP architecture. See
references/examples/script_to_oop_transformation.md
for complete example.
Encapsulate Global State in Classes:
python
undefined
将类脚本“面条代码”转换为结构清晰的OOP架构。完整示例见
references/examples/script_to_oop_transformation.md
将全局状态封装到类中:
python
undefined

Before: Script-like with global state

重构前:类脚本,包含全局状态

users_cache = {} # Global! API_URL = "https://api.example.com"
def fetch_user(user_id): global users_cache # ...
users_cache = {} # 全局变量! API_URL = "https://api.example.com"
def fetch_user(user_id): global users_cache # ...

After: OOP with encapsulation

重构后:OOP,封装状态

class UserRepository: def init(self, api_client: APIClient): self._api_client = api_client self._cache: dict[int, User] = {}
def get_by_id(self, user_id: int) -> Optional[User]:
    # Encapsulated state
    pass

**Group Related Functions into Classes:**
```python
class UserRepository: def init(self, api_client: APIClient): self._api_client = api_client self._cache: dict[int, User] = {}
def get_by_id(self, user_id: int) -> Optional[User]:
    # 封装的状态
    pass

**将相关函数分组到类中:**
```python

Before: Scattered functions

重构前:零散函数

def fetch_user(user_id): pass def validate_user(user_data): pass def save_user(user_data): pass
def fetch_user(user_id): pass def validate_user(user_data): pass def save_user(user_data): pass

After: Organized in classes by responsibility

重构后:按职责组织到类中

class UserRepository: def get_by_id(self, user_id): pass
class UserValidator: def is_valid(self, user): pass
class DatabaseRepository: def save_user(self, user): pass

**Create Domain Models:**
```python
class UserRepository: def get_by_id(self, user_id): pass
class UserValidator: def is_valid(self, user): pass
class DatabaseRepository: def save_user(self, user): pass

**创建领域模型:**
```python

Before: Using primitives and dicts

重构前:使用基本类型和字典

def process_user(user_id, email, status): user_dict = {'id': user_id, 'email': email, 'status': status} # ...
def process_user(user_id, email, status): user_dict = {'id': user_id, 'email': email, 'status': status} # ...

After: Rich domain models

重构后:丰富的领域模型

from dataclasses import dataclass from enum import Enum
class UserStatus(Enum): ACTIVE = 'active' INACTIVE = 'inactive'
@dataclass class User: id: int email: str status: UserStatus
def is_valid(self) -> bool:
    return '@' in self.email and self.status == UserStatus.ACTIVE

**Apply Dependency Injection:**
```python
from dataclasses import dataclass from enum import Enum
class UserStatus(Enum): ACTIVE = 'active' INACTIVE = 'inactive'
@dataclass class User: id: int email: str status: UserStatus
def is_valid(self) -> bool:
    return '@' in self.email and self.status == UserStatus.ACTIVE

**应用依赖注入:**
```python

Before: Hard-coded dependencies

重构前:硬编码依赖

def process_user(user_id): user = fetch_user(user_id) # Hard-coded! save_to_db(user) # Hard-coded!
def process_user(user_id): user = fetch_user(user_id) # 硬编码! save_to_db(user) # 硬编码!

After: Injected dependencies

重构后:注入依赖

class UserService: def init(self, user_repo: UserRepository, db_repo: DatabaseRepository): self._user_repo = user_repo self._db_repo = db_repo
def process_user(self, user_id: int):
    user = self._user_repo.get_by_id(user_id)
    self._db_repo.save_user(user)

**Organize into Layered Architecture:**
Before (script): After (OOP): user_script.py project/ ├── models/ │ └── user.py ├── repositories/ │ ├── user_repository.py │ └── database_repository.py ├── services/ │ └── user_service.py ├── clients/ │ └── api_client.py └── main.py

**Key OOP Principles to Apply:**
- **Single Responsibility** (SRP): One class, one responsibility
- **Open/Closed** (OCP): Open for extension, closed for modification
- **Liskov Substitution** (LSP): Subtypes must be substitutable
- **Interface Segregation** (ISP): Many specific interfaces over one general
- **Dependency Inversion** (DIP): Depend on abstractions, not concretions

See `references/oop_principles.md` for comprehensive guide with examples.
class UserService: def init(self, user_repo: UserRepository, db_repo: DatabaseRepository): self._user_repo = user_repo self._db_repo = db_repo
def process_user(self, user_id: int):
    user = self._user_repo.get_by_id(user_id)
    self._db_repo.save_user(user)

**组织为分层架构:**
重构前(脚本): 重构后(OOP): user_script.py project/ ├── models/ │ └── user.py ├── repositories/ │ ├── user_repository.py │ └── database_repository.py ├── services/ │ └── user_service.py ├── clients/ │ └── api_client.py └── main.py

**需应用的核心OOP原则:**
- **单一职责**(SRP):一个类,一个职责
- **开闭原则**(OCP):对扩展开放,对修改关闭
- **里氏替换原则**(LSP):子类型必须可替换父类型
- **接口隔离原则**(ISP):使用多个专用接口,而非一个通用接口
- **依赖倒置原则**(DIP):依赖抽象,而非具体实现

完整指南及示例见`references/oop_principles.md`。

Common Refactoring Mistakes (CRITICAL - MUST AVOID)

常见重构错误(关键 - 必须避免)

These are catastrophic mistakes that break code. NEVER make these errors:
这些是会破坏代码的严重错误。绝对不要犯这些错误:

1. Incomplete Migration (CRITICAL BUG GENERATOR)

1. 不完整迁移(关键bug生成器)

The Problem: Removing old code before ALL usages are migrated.
Example Failure:
python
undefined
问题: 在所有引用都迁移完成前删除旧代码。
失败示例:
python
undefined

Step 1: Create new service (GOOD)

步骤1:创建新服务(正确)

class SSEManagerService: def init(self): self._connections = {} self._lock = asyncio.Lock()
class SSEManagerService: def init(self): self._connections = {} self._lock = asyncio.Lock()

Step 2: Remove globals (DANGEROUS - TOO EARLY!)

步骤2:删除全局变量(危险 - 太早了!)

❌ WRONG: Removed these before checking all usages

❌ 错误:未检查所有引用就删除了这些变量

global sse_connections # REMOVED

global sse_connections # 已删除

global _sse_lock # REMOVED

global _sse_lock # 已删除

Step 3: Update some usages (INCOMPLETE)

步骤3:更新部分引用(不完整)

def broadcast_event(): # ✅ Updated to use service sse_manager.broadcast(event)
def broadcast_event(): # ✅ 已更新为使用服务 sse_manager.broadcast(event)

MISSED: Route still using removed globals

遗漏:路由仍在使用已删除的全局变量

@app.route('/stream') async def stream(): async with _sse_lock: # ❌ NameError: _sse_lock undefined! sse_connections[id].append(queue) # ❌ NameError: sse_connections undefined!

**Prevention Protocol:**
1. **BEFORE removing any code element**, run comprehensive searches:
   ```bash
   # Search for variable name
   grep -r "sse_connections" --include="*.py"

   # Search for related patterns
   grep -r "_sse_lock\|sse_global_connections\|sse_event_buffer" --include="*.py"

   # Search for common access patterns
   grep -r "sse_connections\[.*\]\|sse_connections\..*" --include="*.py"
  1. Document EVERY found usage:
    markdown
    ## Migration Checklist for sse_connections removal
    
    Found usages:
    - [ ] rest_api_channel_api.py:1234 - broadcast_sse_event() - MIGRATED
    - [ ] rest_api_channel_api.py:1916 - stream_positions() - NOT MIGRATED
    - [ ] rest_api_channel_api.py:1945 - stream_signals() - NOT MIGRATED
    - [ ] rest_api_channel_api.py:1978 - stream_agents() - NOT MIGRATED
    
    Status: 1/4 usages migrated - CANNOT REMOVE YET
  2. Migrate ALL usages before removal
  3. Run static analysis to verify:
    bash
    flake8 <file> --select=F821  # Check for undefined names
    pylint <file> --disable=all --enable=E0602  # Check for undefined variables
  4. Only then remove old code
@app.route('/stream') async def stream(): async with _sse_lock: # ❌ NameError: _sse_lock未定义! sse_connections[id].append(queue) # ❌ NameError: sse_connections未定义!

**预防协议:**
1. **删除任何代码元素前**,运行全面搜索:
   ```bash
   # 搜索变量名
   grep -r "sse_connections" --include="*.py"

   # 搜索相关模式
   grep -r "_sse_lock\|sse_global_connections\|sse_event_buffer" --include="*.py"

   # 搜索常见访问模式
   grep -r "sse_connections\[.*\]\|sse_connections\..*" --include="*.py"
  1. 记录所有找到的引用:
    markdown
    ## sse_connections删除迁移检查清单
    
    找到的引用:
    - [ ] rest_api_channel_api.py:1234 - broadcast_sse_event() - 已迁移
    - [ ] rest_api_channel_api.py:1916 - stream_positions() - 未迁移
    - [ ] rest_api_channel_api.py:1945 - stream_signals() - 未迁移
    - [ ] rest_api_channel_api.py:1978 - stream_agents() - 未迁移
    
    状态:1/4 引用已迁移 - 暂不能删除
  2. 所有引用迁移完成后再删除
  3. 运行静态分析验证:
    bash
    flake8 <file> --select=F821  # 检查未定义的名称
    pylint <file> --disable=all --enable=E0602  # 检查未定义的变量
  4. 仅在此时删除旧代码

2. Partial Pattern Application

2. 模式应用不完整

The Problem: Applying refactoring pattern to some functions but not others.
Prevention: Use grep to find ALL instances of the pattern, create checklist, migrate all.
问题: 仅对部分函数应用重构模式,其他函数不应用。
预防: 使用grep找到所有模式实例,创建检查清单,全部迁移。

3. Breaking Public APIs Without Documentation

3. 未记录就修改公共API

The Problem: Changing function signatures used by external code.
Prevention: Search for all callers before changing signatures. Document breaking changes.
问题: 修改了外部代码使用的函数签名。
预防: 修改签名前搜索所有调用者。记录破坏性变更。

4. Assuming Tests Cover Everything

4. 假设测试覆盖所有情况

The Problem: Tests pass but runtime errors occur (like NameError).
Prevention: Run static analysis (flake8, pylint, mypy) after every change.
问题: 测试通过但运行时出现错误(如NameError)。
预防: 每次变更后运行静态分析(flake8、pylint、mypy)。

Anti-Patterns to Fix

需修复的反模式

Identify and fix these common anti-patterns. See
references/anti-patterns.md
for detailed examples.
CRITICAL Priority Fixes (Must Fix First):
  1. Script-like / Procedural Code - Global state, scattered functions, no OOP structure (See
    references/examples/script_to_oop_transformation.md
    )
  2. God Object / God Class - Single class responsible for too many unrelated things
High-Priority Fixes: 3. Complex nested conditionals (>3 levels) 4. Long functions (>30 lines doing multiple things) 5. Magic numbers and strings 6. Cryptic variable names (
x
,
tmp
,
data
,
d
) 7. Missing type hints on public APIs 8. Missing or inadequate docstrings 9. Unclear error handling 10. Mixed abstraction levels in single function
Medium-Priority Fixes: 11. Duplicate code (violates DRY) 12. Primitive obsession (should use domain objects) 13. Long parameter lists (>5 parameters) 14. Comments explaining "what" instead of "why"
Low-Priority Fixes: 15. Inconsistent naming conventions 16. Redundant comments (obvious statements) 17. Unused imports or variables
识别并修复这些常见反模式。详细示例见
references/anti-patterns.md
最高优先级修复(必须首先修复):
  1. 类脚本/过程式代码 - 全局状态、零散函数、无OOP结构(见
    references/examples/script_to_oop_transformation.md
  2. 上帝对象/上帝类 - 单个类承担过多不相关职责
高优先级修复: 3. 复杂嵌套条件(>3层) 4. 长函数(>30行,承担多个职责) 5. 魔法数字和字符串 6. 晦涩变量名(
x
tmp
data
d
) 7. 公共API缺失类型提示 8. 缺失或不充分的文档字符串 9. 不清晰的错误处理 10. 单个函数中混合不同抽象层级
中优先级修复: 11. 重复代码(违反DRY原则) 12. 基本类型痴迷(应使用领域对象) 13. 长参数列表(>5个参数) 14. 解释“做什么”而非“为什么”的注释
低优先级修复: 15. 不一致的命名规范 16. 冗余注释(显而易见的陈述) 17. 未使用的导入或变量

Validation Framework

验证框架

Use the provided validation scripts to measure improvements objectively.
使用提供的验证脚本客观衡量改进效果。

Multi-Metric Analysis (RECOMMENDED)

多指标分析(推荐)

Non affidarti a una sola metrica. Combina:
MetricaToolUso
Cognitive ComplexitycomplexipyComprensibilità umana
Cyclomatic Complexityruff (C901), radonTest planning
Maintainability IndexradonSalute generale codice
不要仅依赖单一指标。组合使用:
指标工具用途
认知复杂度complexipy人类可读性
圈复杂度ruff (C901), radon测试规划
可维护性指数radon代码整体健康度

Stack Raccomandato: Ruff + Complexipy

推荐工具栈:Ruff + Complexipy

bash
undefined
bash
undefined

Setup completo

完整安装

pip install ruff complexipy radon wily
pip install ruff complexipy radon wily

Workflow quotidiano

日常工作流

ruff check src/ # Linting veloce (Rust, 150-200x flake8) complexipy src/ --max-complexity-allowed 15 # Cognitive complexity (Rust) radon mi src/ -s # Maintainability Index
undefined
ruff check src/ # 快速lint(基于Rust,速度是flake8的150-200倍) complexipy src/ --max-complexity-allowed 15 # 认知复杂度(基于Rust) radon mi src/ -s # 可维护性指数
undefined

Perché Ruff + Complexipy?

为什么选择Ruff + Complexipy?

ToolVantaggi
RuffStandard de facto, 800+ regole, velocissimo (Rust), sostituisce flake8+plugins
ComplexipyCognitive complexity dedicata, attivamente mantenuta (2025), Rust, ecosistema completo
工具优势
Ruff事实上的标准,800+规则,速度极快(Rust实现),可替代flake8+插件
Complexipy专注认知复杂度,持续维护(2025年),Rust实现,生态完整

Configurazione (pyproject.toml)

配置(pyproject.toml)

toml
[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.lint]
select = [
    "E", "W",     # pycodestyle
    "F",          # Pyflakes
    "C90",        # McCabe cyclomatic complexity
    "B",          # flake8-bugbear
    "SIM",        # flake8-simplify
    "N",          # pep8-naming
    "UP",         # pyupgrade
    "I",          # isort
]

[tool.ruff.lint.mccabe]
max-complexity = 10  # Cyclomatic complexity

[tool.complexipy]
paths = ["src"]
max-complexity-allowed = 15    # SonarQube default
exclude = ["tests", "migrations"]
toml
[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.lint]
select = [
    "E", "W",     # pycodestyle
    "F",          # Pyflakes
    "C90",        # McCabe圈复杂度
    "B",          # flake8-bugbear
    "SIM",        # flake8-simplify
    "N",          # pep8-naming
    "UP",         # pyupgrade
    "I",          # isort
]

[tool.ruff.lint.mccabe]
max-complexity = 10  # 圈复杂度阈值

[tool.complexipy]
paths = ["src"]
max-complexity-allowed = 15    # SonarQube默认阈值
exclude = ["tests", "migrations"]

CLI Complexipy

Complexipy命令行

bash
undefined
bash
undefined

Analisi base

基础分析

complexipy src/
complexipy src/

Output JSON per CI

输出JSON用于CI

complexipy src/ --output-json
complexipy src/ --output-json

Per legacy code: snapshot baseline

遗留代码:创建基线快照

complexipy src/ --snapshot-create --max-complexity-allowed 15
complexipy src/ --snapshot-create --max-complexity-allowed 15

Blocca solo regressioni (confronta con snapshot)

仅阻止回归(与快照对比)

complexipy src/ --max-complexity-allowed 15
undefined
complexipy src/ --max-complexity-allowed 15
undefined

API Python

Python API

python
from complexipy import file_complexity, code_complexity
python
from complexipy import file_complexity, code_complexity

Analizza file

分析文件

result = file_complexity("src/user_service.py") for func in result.functions: if func.complexity > 15: print(f"⚠️ {func.name}: {func.complexity} (line {func.line_start})")
undefined
result = file_complexity("src/user_service.py") for func in result.functions: if func.complexity > 15: print(f"⚠️ {func.name}: {func.complexity} (行 {func.line_start})")
undefined

Pre-commit Hook

预提交钩子

yaml
repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.8.0
    hooks:
      - id: ruff
        args: [--fix]
      - id: ruff-format

  - repo: https://github.com/rohaquinlop/complexipy-pre-commit
    rev: v3.0.0
    hooks:
      - id: complexipy
        args: [--max-complexity-allowed, "15"]
yaml
repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.8.0
    hooks:
      - id: ruff
        args: [--fix]
      - id: ruff-format

  - repo: https://github.com/rohaquinlop/complexipy-pre-commit
    rev: v3.0.0
    hooks:
      - id: complexipy
        args: [--max-complexity-allowed, "15"]

GitHub Actions

GitHub Actions

yaml
- name: Ruff
  uses: astral-sh/ruff-action@v1

- name: Cognitive Complexity
  uses: rohaquinlop/complexipy-action@v2
  with:
    paths: src/
    max_complexity_allowed: 15
yaml
- name: Ruff
  uses: astral-sh/ruff-action@v1

- name: 认知复杂度检查
  uses: rohaquinlop/complexipy-action@v2
  with:
    paths: src/
    max_complexity_allowed: 15

Cognitive Complexity: Dettagli Importanti

认知复杂度:重要细节

Vedi
references/cognitive_complexity_guide.md
per la guida completa. Punti chiave:
Regole di calcolo:
  • +1 per ogni break nel flusso (if, for, while, except)
  • +1 EXTRA per ogni livello di nesting (ESPONENZIALE!)
  • Boolean sequences: stesso operatore = gratis, cambio operatore = +1
  • match/switch = +1 TOTALE (non per branch)
完整指南见
references/cognitive_complexity_guide.md
。关键点:
计算规则:
  • 每个流程分支(if、for、while、except)+1
  • 每个嵌套层级额外+1(影响呈指数级!)
  • 布尔序列:相同操作符不加分,切换操作符+1
  • match/switch:总计+1(而非每个分支+1)

Historical Tracking con Wily

使用Wily进行历史跟踪

Monitora i trend nel tempo, non solo i threshold:
bash
undefined
随时间监控趋势,而非仅关注阈值:
bash
undefined

Setup (una volta)

初始化(一次)

wily build src/ -n 50 # Analizza ultimi 50 commit
wily build src/ -n 50 # 分析最近50次提交

Report per file

文件报告

wily report src/module.py
wily report src/module.py

Diff tra commit

提交间对比

wily diff src/ -r HEAD~5..HEAD
wily diff src/ -r HEAD~5..HEAD

Rank file più complessi

按复杂度排名文件

wily rank src/ complexity
wily rank src/ complexity

Grafico trend (apre browser)

趋势图表(打开浏览器)

wily graph src/module.py complexity

**Integrazione CI per trend check:**
```bash
wily graph src/module.py complexity

**CI集成用于趋势检查:**
```bash

Fail se complessità AUMENTATA rispetto a commit precedente

如果复杂度较上一次提交增加,则失败

wily diff src/ -r HEAD~1..HEAD
undefined
wily diff src/ -r HEAD~1..HEAD
undefined

Threshold Progressivi per Legacy Code

遗留代码的渐进式阈值

Non applicare threshold stretti immediatamente su legacy:
ini
undefined
不要对遗留代码立即应用严格阈值:
ini
undefined

Fase 1: Baseline (blocca solo casi estremi)

阶段1:基线(仅阻止极端情况)

max-cognitive-complexity = 25
max-cognitive-complexity = 25

Fase 2: Riduzione graduale

阶段2:逐步降低

max-cognitive-complexity = 20
max-cognitive-complexity = 20

Fase 3: Standard (target finale)

阶段3:标准(最终目标)

max-cognitive-complexity = 15
max-cognitive-complexity = 15

Fase 4: Strict (solo nuovo codice via pre-commit)

阶段4:严格(仅对新代码通过预提交钩子)

max-cognitive-complexity = 10

**Strategia "Changed Files Only":**
```bash
max-cognitive-complexity = 10

**“仅修改文件”策略:**
```bash

Strict solo per file modificati

仅对修改的文件应用严格阈值

CHANGED=$(git diff --name-only origin/main...HEAD -- '*.py') for f in $CHANGED; do flake8 "$f" --max-cognitive-complexity=10 # Strict done
undefined
CHANGED=$(git diff --name-only origin/main...HEAD -- '*.py') for f in $CHANGED; do flake8 "$f" --max-cognitive-complexity=10 # 严格阈值 done
undefined

Complexity Measurement

复杂度测量

bash
python scripts/measure_complexity.py <file_path>
Targets:
  • Cyclomatic complexity: <10 per function (warning at 15, error at 20)
  • Cognitive complexity: <15 per function (SonarQube default, warning at 20)
  • Function length: <30 lines (warning at 50)
  • Nesting depth: ≤3 levels
bash
python scripts/measure_complexity.py <file_path>
目标值:
  • 圈复杂度:每个函数<10(15警告,20错误)
  • 认知复杂度:每个函数<15(SonarQube默认值,20警告)
  • 函数长度:<30行(50警告)
  • 嵌套深度:≤3层

Documentation Coverage

文档覆盖率

bash
python scripts/check_documentation.py <file_path>
Targets:
  • Docstring coverage: >80% for public functions
  • Type hint coverage: >90% for public APIs
  • Module-level documentation: Required
bash
python scripts/check_documentation.py <file_path>
目标值:
  • 文档字符串覆盖率:公共函数>80%
  • 类型提示覆盖率:公共API>90%
  • 模块级文档:必须存在

Before/After Comparison

前后对比

bash
python scripts/compare_metrics.py <before_file> <after_file>
Generates comparison report showing improvements in all metrics.
bash
python scripts/compare_metrics.py <before_file> <after_file>
生成对比报告,展示所有指标的改进情况。

Performance Validation

性能验证

bash
python scripts/benchmark_changes.py <before_file> <after_file> <test_module>
Ensures no performance regression >10% (configurable threshold).
bash
python scripts/benchmark_changes.py <before_file> <after_file> <test_module>
确保性能下降不超过10%(阈值可配置)。

Flake8 Code Quality Analysis

Flake8代码质量分析

bash
python scripts/analyze_with_flake8.py <file_or_directory> \
    --output report.json \
    --html report.html
Three-tier plugin system (16 curated plugins for maximum readability):
ESSENTIAL (Must-Have - Install First):
  1. flake8-bugbear: Finds likely bugs and design problems (B codes)
  2. flake8-simplify: Suggests simpler, clearer code (SIM codes)
  3. flake8-cognitive-complexity: Measures cognitive load (CCR codes)
  4. pep8-naming: Enforces clear naming conventions (N codes)
  5. flake8-docstrings: Ensures documentation (D codes)
RECOMMENDED (Strong Readability Impact): 6. flake8-comprehensions: Cleaner comprehensions (C4 codes) 7. flake8-expression-complexity: Prevents complex expressions (ECE codes) 8. flake8-functions: Simpler function signatures (CFQ codes) 9. flake8-variables-names: Better variable naming (VNE codes) 10. tryceratops: Clean exception handling (TC codes)
OPTIONAL (Nice to Have): 11. flake8-builtins: Prevents shadowing built-ins (A codes) 12. flake8-eradicate: Finds commented-out code (E800 codes) 13. flake8-unused-arguments: Flags unused parameters (U codes) 14. flake8-annotations: Validates type hints (ANN codes) 15. pydoclint: Complete docstrings (DOC codes) 16. flake8-spellcheck: Catches typos (SC codes)
Install essential plugins (minimum):
bash
pip install flake8 flake8-bugbear flake8-simplify \
    flake8-cognitive-complexity pep8-naming flake8-docstrings
Install all recommended plugins (full suite):
bash
pip install flake8 flake8-bugbear flake8-simplify \
    flake8-cognitive-complexity pep8-naming flake8-docstrings \
    flake8-comprehensions flake8-expression-complexity \
    flake8-functions flake8-variables-names tryceratops \
    flake8-builtins flake8-eradicate flake8-unused-arguments \
    flake8-annotations pydoclint flake8-spellcheck
Analysis provides:
  • Issue severity classification (high/medium/low)
  • Issues by category (bugs, complexity, style, docs, naming)
  • Potential bug detection (Bugbear plugin)
  • Code simplification opportunities
  • Missing documentation and type hints
  • Style and naming violations
  • HTML and JSON reports for tracking
Configuration: Use the provided
.flake8
configuration file (
assets/.flake8
) for consistent analysis.
bash
python scripts/analyze_with_flake8.py <file_or_directory> \
    --output report.json \
    --html report.html
三层插件系统(16个精选插件,最大化可读性):
核心插件(必须安装 - 优先安装):
  1. flake8-bugbear:发现潜在bug和设计问题(B类代码)
  2. flake8-simplify:建议更简洁、清晰的代码(SIM类代码)
  3. flake8-cognitive-complexity:测量认知负载(CCR类代码)
  4. pep8-naming:强制清晰的命名规范(N类代码)
  5. flake8-docstrings:确保文档完整性(D类代码)
推荐插件(对可读性影响大): 6. flake8-comprehensions:更简洁的推导式(C4类代码) 7. flake8-expression-complexity:防止复杂表达式(ECE类代码) 8. flake8-functions:更简洁的函数签名(CFQ类代码) 9. flake8-variables-names:更好的变量命名(VNE类代码) 10. tryceratops:更简洁的异常处理(TC类代码)
可选插件(锦上添花): 11. flake8-builtins:防止遮蔽内置函数(A类代码) 12. flake8-eradicate:找到注释掉的代码(E800类代码) 13. flake8-unused-arguments:标记未使用的参数(U类代码) 14. flake8-annotations:验证类型提示(ANN类代码) 15. pydoclint:完整的文档字符串(DOC类代码) 16. flake8-spellcheck:捕获拼写错误(SC类代码)
安装核心插件(最小集合):
bash
pip install flake8 flake8-bugbear flake8-simplify \
    flake8-cognitive-complexity pep8-naming flake8-docstrings
安装所有推荐插件(完整套件):
bash
pip install flake8 flake8-bugbear flake8-simplify \
    flake8-cognitive-complexity pep8-naming flake8-docstrings \
    flake8-comprehensions flake8-expression-complexity \
    flake8-functions flake8-variables-names tryceratops \
    flake8-builtins flake8-eradicate flake8-unused-arguments \
    flake8-annotations pydoclint flake8-spellcheck
分析内容包括:
  • 问题严重程度分类(高/中/低)
  • 按类别划分的问题(bug、复杂度、风格、文档、命名)
  • 潜在bug检测(Bugbear插件)
  • 代码简化机会
  • 缺失的文档和类型提示
  • 风格和命名违规
  • 用于跟踪的HTML和JSON报告
配置: 使用提供的
.flake8
配置文件(
assets/.flake8
)以保证分析一致性。

Flake8 Before/After Comparison

Flake8前后对比

bash
python scripts/compare_flake8_reports.py before.json after.json \
    --html comparison.html
Comparison shows:
  • Total issue reduction (count and percentage)
  • Improvements by severity level (high/medium/low)
  • Improvements by category (bugs, complexity, style, docs)
  • Fixed issues vs new issues
  • Net improvement score
  • Detailed issue-by-issue analysis
Targets:
  • Zero high-severity issues (bugs, runtime errors)
  • <10 medium-severity issues (complexity, naming)
  • Continuous reduction in all issue counts
  • No regression in any category
bash
python scripts/compare_flake8_reports.py before.json after.json \
    --html comparison.html
对比内容包括:
  • 问题总数减少(数量和百分比)
  • 严重程度改进(高/中/低)
  • 类别改进(bug、复杂度、风格、文档)
  • 已修复问题 vs 新出现问题
  • 净改进分数
  • 逐问题详细分析
目标值:
  • 零高严重程度问题(bug、运行时错误)
  • 中严重程度问题<10个(复杂度、命名)
  • 所有问题数量持续减少
  • 任何类别都无回归

Language-Specific Guidelines

语言特定指南

Apply language-appropriate idioms and conventions.
应用适合语言的惯用写法和规范。

Python

Python

  • Type hints: Use for all public APIs and complex internals
  • Docstrings: Google style preferred
  • Data structures: Use
    dataclasses
    for data containers
  • Path handling: Use
    pathlib
    over
    os.path
  • Error handling: Specific exceptions, not bare
    except
  • Modern features: f-strings, context managers, comprehensions (when clear)
  • 类型提示:所有公共API和复杂内部逻辑都需添加
  • 文档字符串:推荐使用Google风格
  • 数据结构:使用
    dataclasses
    作为数据容器
  • 路径处理:使用
    pathlib
    替代
    os.path
  • 错误处理:使用特定异常,而非裸
    except
  • 现代特性:f字符串、上下文管理器、推导式(当清晰时使用)

JavaScript/TypeScript

JavaScript/TypeScript

  • Types: Explicit TypeScript types for all public APIs
  • Async: Prefer
    async/await
    over callbacks or raw promises
  • Destructuring: Use for clarity, not just brevity
  • Immutability: Prefer
    const
    , avoid mutation when practical
  • Error handling: Try/catch for async, explicit error types
  • 类型:所有公共API使用显式TypeScript类型
  • 异步:优先使用
    async/await
    而非回调或原始Promise
  • 解构:用于提升清晰度,而非仅为简洁
  • 不可变性:优先使用
    const
    ,实际可行时避免突变
  • 错误处理:异步代码使用Try/catch,使用显式错误类型

Java

Java

  • Interfaces: Define contracts for implementations
  • Streams: Use for collection operations (when clear)
  • Optional: Handle nullability explicitly
  • Exceptions: Checked for recoverable, unchecked for programming errors
  • 接口:为实现定义契约
  • :用于集合操作(当清晰时使用)
  • Optional:显式处理空值
  • 异常:可恢复的异常使用受检异常,编程错误使用非受检异常

Go

Go

  • Error handling: Explicit error checking, no silent failures
  • Defer: Use for resource cleanup
  • Names: Short names in small scopes, longer in broad scopes
  • Interfaces: Small, focused interfaces
  • 错误处理:显式错误检查,无静默失败
  • Defer:用于资源清理
  • 命名:小作用域使用短名称,大作用域使用长名称
  • 接口:小而专注的接口

Output Format

输出格式

Structure refactoring output consistently using the template from
assets/templates/summary_template.md
.
使用
assets/templates/summary_template.md
中的模板一致地组织重构输出。

Summary Structure

总结结构

markdown
undefined
markdown
undefined

Refactoring Summary

重构总结

File:
path/to/file.py
Date: YYYY-MM-DD Risk Level: [Low/Medium/High]
文件:
path/to/file.py
日期: YYYY-MM-DD 风险等级: [低/中/高]

Changes Made

已做变更

  1. Extracted method
    validate_user_input
    from
    process_request
    • Rationale: Function was 85 lines, violated SRP
    • Risk: Low (pure extraction, no logic changes)
  2. Renamed
    d
    discount_percentage
    • Rationale: Improved clarity
    • Risk: Low (local variable)
  3. Added guard clauses to reduce nesting from 5 to 2 levels
    • Rationale: Improved readability, eliminated arrow code
    • Risk: Low (behavior preserved, tests pass)
  1. process_request
    中提取方法
    validate_user_input
    • 理由:原函数85行,违反SRP原则
    • 风险:低(纯提取,无逻辑变更)
  2. d
    重命名为
    discount_percentage
    • 理由:提升清晰度
    • 风险:低(局部变量)
  3. 添加卫语句,将嵌套从5层减少到2层
    • 理由:提升可读性,消除箭头代码
    • 风险:低(行为保留,测试通过)

Metrics Improvement

指标改进

MetricBeforeAfterChange
Avg Cyclomatic Complexity18.57.2-61% ✓
Avg Function Length47 lines22 lines-53% ✓
Max Nesting Depth52-60% ✓
Docstring Coverage45%92%+104% ✓
Type Hint Coverage30%95%+217% ✓
指标重构前重构后变化
平均圈复杂度18.57.2-61% ✓
平均函数长度47行22行-53% ✓
最大嵌套深度52-60% ✓
文档字符串覆盖率45%92%+104% ✓
类型提示覆盖率30%95%+217% ✓

Test Results

测试结果

  • All 47 tests passing ✓
  • No new test failures
  • Test coverage maintained at 87%
  • 所有47个测试通过 ✓
  • 无新测试失败
  • 测试覆盖率保持87%

Performance Impact

性能影响

  • Benchmarked hot paths: No measurable difference (<2% variance)
  • No performance-critical code modified
  • 热点路径基准测试:无明显差异(<2%波动)
  • 未修改对性能要求高的代码

Risk Assessment

风险评估

Overall Risk: Low
  • No public API changes
  • All tests passing
  • No performance regression
  • Changes are mechanical refactorings
整体风险:低
  • 无公共API变更
  • 所有测试通过
  • 无性能退化
  • 变更为机械重构

Human Review Needed

是否需人工审查

No - Changes are low-risk mechanical improvements with full test coverage.
If yes, specify areas:
  • [N/A]
undefined
- 变更为低风险机械改进,且有完整测试覆盖。
如果是,指定需审查的区域:
  • [不适用]
undefined

Integration with Same-Package Skills

与同包技能的集成

This skill works in synergy with other skills in
python-development
:
本技能与
python-development
中的其他技能协同工作:

python-testing-patterns

python-testing-patterns

  • Before refactoring: Use
    python-testing-patterns
    to set up comprehensive pytest fixtures, mocking, and coverage
  • During refactoring: Reference test patterns for writing validation tests
  • After refactoring: Validate test coverage hasn't decreased
  • Invoke: For detailed pytest patterns, fixtures, parameterization → use
    python-testing-patterns
    skill
  • 重构前:使用
    python-testing-patterns
    设置全面的pytest夹具、模拟和覆盖率
  • 重构中:参考测试模式编写验证测试
  • 重构后:验证测试覆盖率未下降
  • 调用时机:如需详细的pytest模式、夹具、参数化 → 使用
    python-testing-patterns
    技能

python-performance-optimization

python-performance-optimization

  • Before refactoring: Use
    python-performance-optimization
    for deep profiling with cProfile, py-spy, memory_profiler
  • After refactoring: Run benchmark validation using profiling patterns
  • Note: This skill's
    benchmark_changes.py
    script is for quick regression checks; use the performance skill for deep analysis
  • Invoke: For runtime profiling, memory analysis, optimization → use
    python-performance-optimization
    skill
  • 重构前:使用
    python-performance-optimization
    进行深度性能分析,使用cProfile、py-spy、memory_profiler
  • 重构后:使用性能分析模式运行基准验证
  • 注意:本技能的
    benchmark_changes.py
    脚本用于快速回归检查;如需深度分析,使用性能优化技能
  • 调用时机:如需运行时分析、内存分析、优化 → 使用
    python-performance-optimization
    技能

python-packaging

python-packaging

  • After refactoring: If refactoring a library, use
    python-packaging
    for proper pyproject.toml and distribution setup
  • Invoke: For packaging, publishing to PyPI → use
    python-packaging
    skill
  • 重构后:如果重构的是库,使用
    python-packaging
    进行规范的pyproject.toml和分发设置
  • 调用时机:如需打包、发布到PyPI → 使用
    python-packaging
    技能

uv-package-manager

uv-package-manager

  • Use
    uv
    commands referenced in this skill (
    uv run ruff
    ,
    uv run complexipy
    )
  • Invoke: For dependency management, virtual environments → use
    uv-package-manager
    skill
  • 使用本技能中引用的
    uv
    命令(
    uv run ruff
    uv run complexipy
  • 调用时机:如需依赖管理、虚拟环境 → 使用
    uv-package-manager
    技能

async-python-patterns

async-python-patterns

  • When refactoring async code, reference async patterns for proper async/await structure
  • Invoke: For asyncio patterns, concurrent programming → use
    async-python-patterns
    skill
  • 重构异步代码时,参考异步模式以获得规范的async/await结构
  • 调用时机:如需asyncio模式、并发编程 → 使用
    async-python-patterns
    技能

External Integration

外部集成

  • Security Auditing: After refactoring, run security audit to ensure no new vulnerabilities introduced
  • Documentation Generation: Refactored code with better docstrings improves generated documentation
  • 安全审计:重构后,运行安全审计以确保未引入新漏洞
  • 文档生成:重构后代码的文档字符串更完善,可提升生成文档的质量

Edge Cases and Limitations

边缘情况和限制

When NOT to Refactor

何时不应重构

Performance-Critical Code:
  • Profile first - if code is in hot path and optimized, readability may need to compromise
  • Get explicit approval before refactoring performance-sensitive code
  • Benchmark before and after
Scheduled for Deletion:
  • Don't refactor code about to be removed or replaced
  • Focus efforts on code with long-term value
External Dependencies:
  • If the problematic code is in external libraries, contribute upstream
  • Don't refactor vendored dependencies without tracking changes
Stable, Working Legacy Code:
  • "If it ain't broke, don't fix it" applies when:
    • No one needs to modify it
    • It has no maintainability issues affecting development
    • Risk of introducing bugs outweighs readability benefits
对性能要求极高的代码:
  • 先做性能分析 - 如果代码在热点路径且已优化,可能需要在可读性上妥协
  • 重构对性能敏感的代码前需获得明确批准
  • 重构前后都要做基准测试
已计划删除的代码:
  • 不要重构即将删除或替换的代码
  • 将精力集中在有长期价值的代码上
外部依赖:
  • 如果问题代码属于外部库,向上游贡献修改
  • 不要重构 vendored 依赖,除非跟踪变更
稳定可用的遗留代码:
  • “如果没坏,就不要修”适用于以下情况:
    • 无人需要修改它
    • 它没有影响开发的可维护性问题
    • 引入bug的风险超过可读性提升的收益

Limitations

限制

Algorithmic Complexity:
  • Cannot improve O(n²) to O(n log n) - that's algorithm change, not refactoring
  • This skill focuses on code structure, not algorithmic optimization
Domain Knowledge:
  • Cannot add domain knowledge that doesn't exist in code or comments
  • Rename variables accurately only if their purpose is clear from context
Test Coverage:
  • Cannot guarantee correctness without comprehensive tests
  • Refactoring without tests is risky - add tests first when coverage is poor
Subjective Preferences:
  • Code style preferences vary - this skill applies widely-accepted practices
  • Be prepared to adjust based on team conventions
算法复杂度:
  • 无法将O(n²)改进为O(n log n) - 这是算法变更,而非重构
  • 本技能专注于代码结构,而非算法优化
领域知识:
  • 无法添加代码或注释中不存在的领域知识
  • 仅当变量用途从上下文清晰可见时,才能准确重命名变量
测试覆盖率:
  • 无全面测试则无法保证正确性
  • 覆盖率低时,重构前需先添加测试
主观偏好:
  • 代码风格偏好因人而异 - 本技能应用广泛接受的实践
  • 需准备根据团队规范调整

Examples

示例

See
references/examples/
for comprehensive before/after examples across different scenarios:
  • examples/script_to_oop_transformation.md
    - Complete transformation from script-like "spaghetti code" to clean OOP architecture (MUST READ)
  • examples/python_complexity_reduction.md
    - Nested conditionals and long functions
  • examples/typescript_naming_improvements.md
    - Variable and function renaming with TypeScript patterns
See
references/
for comprehensive guides:
  • REGRESSION_PREVENTION.md
    - Mandatory checklist to prevent regressions (MUST READ)
  • cognitive_complexity_guide.md
    - Complete guide to cognitive complexity calculation, patterns, and tools
  • patterns.md
    - All refactoring patterns with examples
  • anti-patterns.md
    - Common anti-patterns to fix
  • oop_principles.md
    - SOLID principles and OOP best practices
  • flake8_plugins_guide.md
    - Plugin ecosystem for code quality
references/examples/
获取不同场景的完整重构前后示例:
  • examples/script_to_oop_transformation.md
    - 从类脚本“面条代码”到整洁OOP架构的完整转换(必读)
  • examples/python_complexity_reduction.md
    - 嵌套条件和长函数的重构
  • examples/typescript_naming_improvements.md
    - TypeScript变量和函数重命名模式
references/
获取完整指南:
  • REGRESSION_PREVENTION.md
    - 防止回归的强制检查清单(必读)
  • cognitive_complexity_guide.md
    - 认知复杂度计算、模式和工具的完整指南
  • patterns.md
    - 所有重构模式及示例
  • anti-patterns.md
    - 需修复的常见反模式
  • oop_principles.md
    - SOLID原则和OOP最佳实践
  • flake8_plugins_guide.md
    - 代码质量插件生态

Success Criteria

成功标准

Refactoring is successful when:
  1. ZERO REGRESSIONI - All existing tests pass, behavior unchanged
  2. Golden master match - Output identico per casi critici documentati
  3. ✓ Complexity metrics improved (documented in summary)
  4. ✓ No performance regression >10% (or explicit approval obtained)
  5. ✓ Documentation coverage improved
  6. ✓ Code is easier for humans to understand (subjective but validated by metrics)
  7. ✓ No new security vulnerabilities introduced
  8. ✓ Changes are atomic and well-documented in git history
  9. Wily trend - Complessità non aumentata rispetto a commit precedente
  10. ✓ Static analysis shows improvement (flake8 issues reduced)
重构成功的标志:
  1. 零回归 - 所有现有测试通过,行为未改变
  2. 标准输出匹配 - 关键场景的输出与记录的完全一致
  3. ✓ 复杂度指标已改进(记录在总结中)
  4. ✓ 性能下降未超过10%(或已获得明确批准)
  5. ✓ 文档覆盖率已提升
  6. ✓ 代码更易于人类理解(主观但可通过指标验证)
  7. ✓ 未引入新安全漏洞
  8. ✓ 变更为原子操作,且Git历史记录清晰
  9. Wily趋势 - 复杂度较上一次提交未增加
  10. ✓ 静态分析显示改进(flake8问题减少)

Conclusion

结论

Apply this skill systematically to transform hard-to-maintain code into clear, well-documented, maintainable code. Follow the four-phase workflow, apply patterns incrementally, validate continuously, and know when to stop. Balance readability with pragmatism - the goal is code that humans can confidently modify, not perfect code that no one dares touch.
系统应用本技能,将难以维护的代码转换为清晰、文档完善、可维护的代码。遵循四阶段工作流,逐步应用模式,持续验证,并知道何时停止。在可读性和实用性之间取得平衡 - 目标是让人类可以自信修改的代码,而非无人敢碰的“完美”代码。