python-refactor
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChinesePython 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 statements throughout the code
global - 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:
- 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
- Clarity over cleverness - Explicit, obvious code beats implicit, clever code
- Preserve correctness - All tests must pass; behavior must remain identical
- Single Responsibility - Each class and function should do one thing well (SOLID principles)
- Self-documenting structure - Code structure tells what, comments explain why
- Progressive disclosure - Reveal complexity in layers, not all at once
- Reasonable performance - Never sacrifice >2x performance without explicit approval
按以下优先级遵循这些原则:
- 必须采用基于类的架构 - 始终优先选择规范的基于类的OOP架构,而非冗长混乱的面条代码脚本。 将任何过程式“类脚本”代码转换为结构清晰的OOP代码,包含规范的类、模块和接口。这是硬性要求,无协商空间。
- ❌ 绝对不接受:全局变量、零散函数、1000+行的脚本、无清晰结构的代码
- ✅ 必须实现:职责清晰的类、依赖注入、规范的模块
- 清晰优于技巧 - 显式、直白的代码优于隐式、花哨的代码
- 保留正确性 - 所有测试必须通过;行为必须保持一致
- 单一职责 - 每个类和函数应专注做好一件事(SOLID原则)
- 自文档化结构 - 代码结构说明“做什么”,注释解释“为什么”
- 渐进式披露 - 分层展示复杂度,而非一次性全部暴露
- 合理性能 - 未经明确批准,性能损耗不得超过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 before tests to catch NameErrors immediately
flake8 --select=F821,E0602 - 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%验证迁移完成前,绝对不能删除旧代码。
- 先做静态分析 - 运行后再执行测试,立即捕获NameError
flake8 --select=F821,E0602 - 面向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.mdQuick 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:
核心规则:
- Test coverage >= 80% sulle funzioni target, altrimenti scrivi test PRIMA
- Golden outputs catturati per edge cases critici prima di toccare il codice
- Static analysis PRIMA dei test dopo ogni micro-change:
flake8 --select=F821,E999 - Rollback immediato se qualsiasi test fallisce - non procedere mai
⛔ QUALSIASI REGRESSIONE = FALLIMENTO TOTALE DEL REFACTORING ⛔- 目标函数测试覆盖率≥80%,否则先编写测试
- 修改代码前,为关键边缘场景捕获标准输出
- 每次微变更后,先做静态分析再执行测试:
flake8 --select=F821,E999 - 任何测试失败立即回滚 - 绝对不要继续
⛔ 任何回归 = 重构完全失败 ⛔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
passclass 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.htmlThis 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
- Check test coverage - Identify gaps that need filling before refactoring
- 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]:
# 封装的状态,清晰的职责
passclass 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)
- 类型注释覆盖率
- 代码简化机会
- 命名规范违规
- 检查测试覆盖率 - 识别重构前需要补充的测试缺口
- 使用分析模板记录发现(见)
assets/templates/analysis_template.md
输出结果:按影响和风险优先级排序的问题列表,包含flake8报告。
Phase 2: Planning
阶段2:规划
Plan the refactoring approach systematically with safety-by-design:
-
Identify changes by type:
- Non-destructive: Renames, documentation, type hints → Low risk
- Destructive: Removing globals, deleting functions, replacing APIs → High risk
-
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>.txtDocument 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. -
Risk assessment for each proposed change (Low/Medium/High)
-
Dependency identification - What else depends on this code?
-
Test strategy - What tests are needed? What might break?
-
Change ordering - Sequence changes from safest to riskiest
-
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
系统规划重构方案,以设计保障安全:
-
按类型识别变更:
- 非破坏性:重命名、文档、类型提示 → 低风险
- 破坏性:删除全局变量、删除函数、替换API → 高风险
-
对于破坏性变更 - 创建迁移计划(强制要求):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. 删除旧代码 ### 风险等级:[高/中/低]禁止:如果无法创建包含完整引用统计的迁移计划,则不能进行破坏性变更。请推迟或选择更安全的方案。 -
对每个拟议变更进行风险评估(低/中/高)
-
识别依赖关系 - 哪些其他代码依赖于当前代码?
-
测试策略 - 需要哪些测试?哪些部分可能出错?
-
变更排序 - 按从最安全到最危险的顺序排列变更
-
预期结果 - 记录哪些指标应得到改善,以及改善幅度
输出结果:重构计划,包含:
- 按风险等级排序的变更序列
- 所有破坏性变更的完整迁移计划(含引用计数)
- 测试策略
- 回退/滚回计划
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):
- Rename variables/functions for clarity
- Extract magic numbers/strings to named constants
- Add/improve documentation and type hints
- 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:全面搜索所有引用
bash
undefinedExample: 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:创建迁移检查清单**
```markdownMigration: 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
执行规则
- NEVER skip the migration checklist - Attempting to remove code without a verified checklist is PROHIBITED
- Run static analysis BEFORE tests - Catch NameErrors immediately, don't wait for runtime
- One pattern at a time - Never mix multiple refactoring patterns in one change
- Atomic commits - Each migration step gets its own commit
- Stop on ANY error - Static analysis errors OR test failures require immediate fix/revert
Refactoring order (MANDATORY sequence):
-
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 for complete guide
references/examples/script_to_oop_transformation.md
-
Rename variables/functions for clarity (within the new OOP structure)
-
Extract magic numbers/strings to named constants (as class constants or enums)
-
Add/improve documentation and type hints
-
Extract methods to reduce function length
-
Simplify conditionals with guard clauses
-
Reduce nesting depth
-
Final review: Ensure separation of concerns is clean (should be done in step 1)
Output: Refactored code passing all tests with clear commit history.
- 绝对不能跳过迁移检查清单 - 未使用已验证的检查清单就尝试删除代码是被禁止的
- 先运行静态分析再执行测试 - 立即捕获NameError,不要等到运行时
- 一次应用一种模式 - 不要在一次变更中混合多种重构模式
- 原子提交 - 每个迁移步骤单独提交
- 任何错误立即停止 - 静态分析错误或测试失败需立即修复/回滚
重构顺序(必须按此序列执行):
-
首先:将类脚本代码转换为规范的OOP架构(如果代码是过程式的,这是硬性要求,无协商空间)
- 这不是可选操作 - 面条代码必须重构
- 识别所有全局状态并封装到类中
- 将所有零散函数分组到规范的类中(仓库、服务、管理器)
- 创建规范的领域模型(数据类、枚举)
- 全面应用依赖注入
- 组织到规范的模块中,具有清晰的边界
- 完整指南见
references/examples/script_to_oop_transformation.md
-
在新OOP结构内重命名变量/函数以提升清晰度
-
将魔法数字/字符串提取为命名常量(作为类常量或枚举)
-
添加/完善文档和类型提示
-
提取方法以缩短函数长度
-
使用卫语句简化条件判断
-
减少嵌套深度
-
最终审查:确保关注点分离清晰(应在步骤1完成)
输出结果:通过所有测试的重构后代码,具有清晰的提交历史。
Phase 4: Validation
阶段4:验证
Validate improvements objectively:
- Run static analysis FIRST (catch errors before tests):
MANDATORY: Zero F821 (undefined name) and E0602 (undefined variable) errors requiredbash
# 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> - Run full test suite - 100% pass rate required
- 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
- Compare before/after metrics using
scripts/measure_complexity.py - 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 - Compare flake8 reports to quantify improvements:
Validates:bash
python scripts/compare_flake8_reports.py \ before_flake8.json \ after_flake8.json \ --html flake8_comparison.html- Total issue reduction
- Severity-level improvements (high/medium/low)
- Category improvements (bugs, complexity, style, docs)
- Fixed vs new issues
- Code quality trend
- Performance regression check - Run for hot paths
scripts/benchmark_changes.py - Generate summary report using format from
assets/templates/summary_template.md - 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
客观验证改进效果:
- 首先运行静态分析(在测试前捕获错误):
强制要求:必须零F821(未定义名称)和E0602(未定义变量)错误bash
# 检查未定义的名称/变量(防止NameError) flake8 <file> --select=F821,E0602 # 检查未使用的导入(验证清理效果) flake8 <file> --select=F401 # 全面质量检查 flake8 <file> - 运行完整测试套件 - 要求100%通过率
- 验证OOP架构改进:
- 确认全局状态已消除或被正确封装
- 验证代码按规范的模块/类组织
- 检查职责是否已合理分离
- 确保在合适的地方使用了依赖注入
- 对照SOLID原则验证(见)
references/oop_principles.md
- 使用比较前后指标
scripts/measure_complexity.py - 再次运行flake8分析以衡量代码质量改进:
bash
python scripts/analyze_with_flake8.py <target> \ --output after_flake8.json \ --html after_flake8.html - 比较flake8报告以量化改进:
验证内容包括:bash
python scripts/compare_flake8_reports.py \ before_flake8.json \ after_flake8.json \ --html flake8_comparison.html- 问题总数减少
- 严重程度改进(高/中/低)
- 分类改进(bug、复杂度、风格、文档)
- 已修复问题 vs 新出现问题
- 代码质量趋势
- 性能回归检查 - 对热点路径运行
scripts/benchmark_changes.py - 使用中的格式生成总结报告
assets/templates/summary_template.md - 如果出现以下情况,标记为需人工审查:
- 性能下降超过10%
- 公共API签名已变更
- 测试覆盖率下降
- 进行了重大架构变更
- Flake8问题增加(回归)
输出结果:全面验证报告,包含:
- 测试结果
- 复杂度指标对比
- Flake8前后对比
- 性能基准测试
- 整体质量改进总结
Refactoring Patterns
重构模式
Apply these patterns systematically. Each pattern is documented in detail in .
references/patterns.md系统应用这些模式。每个模式的详细文档见。
references/patterns.mdComplexity Reduction Patterns
复杂度降低模式
Guard Clauses - Replace nested conditionals with early returns:
python
undefined卫语句 - 用提前返回替代嵌套条件:
python
undefinedBefore
重构前
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:
```pythondef process(data):
if not data:
return None
if not data.is_valid():
return None
if not data.has_permission():
return None
return data.process()
**提取方法** - 将大函数拆分为专注的单元:
```pythonBefore: 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:
```pythondef validate_input(data): ...
def transform_data(data): ...
def store_result(data): ...
**替换复杂条件** - 使用命名布尔方法:
```pythonBefore
重构前
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):
...
undefineddef can_access_feature(user):
return user.age >= 18 and user.verified and not user.banned
if can_access_feature(user):
...
undefinedCognitive Complexity Reduction Patterns
认知复杂度降低模式
See for complete details on calculation rules and patterns.
references/cognitive_complexity_guide.mdDictionary Dispatch - Eliminate if-elif chains:
python
undefined完整计算规则和模式见。
references/cognitive_complexity_guide.md字典分发 - 消除if-elif链:
python
undefinedBEFORE: 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:
```pythonHANDLERS = {
"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次:
```pythonBEFORE: 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!):
```pythondef get_status_message(status):
match status: # 总计+1!
case "pending":
return "待处理"
case "approved":
return "已批准"
case "rejected":
return "已拒绝"
case _:
return "未知"
**提取方法** - 重置嵌套计数器(最强大的模式!):
```pythonBEFORE: 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:
```pythondef 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)
**命名布尔条件** - 明确复杂条件:
```pythonBEFORE: 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:
```pythonis_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层嵌套:
```pythonBefore: 5 levels of nesting
重构前:5层嵌套
After: Extract inner logic to helper functions
重构后:将内部逻辑提取到辅助函数
undefinedundefinedNaming Improvement Patterns
命名改进模式
Apply these naming conventions consistently:
Variables:
- Descriptive names (no ,
x,tmpunless trivial scope)data - Booleans: ,
is_active,has_permission,can_editshould_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_editshould_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
undefinedUse 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
undefinedBefore: 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:**
```pythondef main_function():
data = fetch_data()
result = transform_data(data)
return result
def transform_data(data):
# 10行转换逻辑
return transformed_data
**分组相关功能:**
```pythonBefore: 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:**
```pythonclass UserValidator:
def validate_email(self, email): ...
def validate_age(self, age): ...
def validate_permissions(self, user): ...
**分离关注点:**
```pythonBefore: 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:**
```pythondef fetch_user_data(user_id): ... # 数据层
def calculate_user_metrics(data): ... # 业务逻辑
def format_user_display(metrics): ... # 展示层
**一致的抽象层级:**
```pythonBefore: 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()
undefineddef process_order():
validate_order()
save_order_to_database()
charge_payment()
undefinedOOP Transformation Patterns
OOP转换模式
Transform script-like "spaghetti code" into well-structured OOP architecture. See for complete example.
references/examples/script_to_oop_transformation.mdEncapsulate Global State in Classes:
python
undefined将类脚本“面条代码”转换为结构清晰的OOP架构。完整示例见。
references/examples/script_to_oop_transformation.md将全局状态封装到类中:
python
undefinedBefore: 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:**
```pythonclass 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
**将相关函数分组到类中:**
```pythonBefore: 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:**
```pythonclass 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
**创建领域模型:**
```pythonBefore: 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:**
```pythonfrom 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
**应用依赖注入:**
```pythonBefore: 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
undefinedStep 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"-
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 -
Migrate ALL usages before removal
-
Run static analysis to verify:bash
flake8 <file> --select=F821 # Check for undefined names pylint <file> --disable=all --enable=E0602 # Check for undefined variables -
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"-
记录所有找到的引用: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 引用已迁移 - 暂不能删除 -
所有引用迁移完成后再删除
-
运行静态分析验证:bash
flake8 <file> --select=F821 # 检查未定义的名称 pylint <file> --disable=all --enable=E0602 # 检查未定义的变量 -
仅在此时删除旧代码
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 for detailed examples.
references/anti-patterns.mdCRITICAL Priority Fixes (Must Fix First):
- Script-like / Procedural Code - Global state, scattered functions, no OOP structure (See )
references/examples/script_to_oop_transformation.md - 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 (, , , )
7. Missing type hints on public APIs
8. Missing or inadequate docstrings
9. Unclear error handling
10. Mixed abstraction levels in single function
xtmpdatadMedium-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最高优先级修复(必须首先修复):
- 类脚本/过程式代码 - 全局状态、零散函数、无OOP结构(见)
references/examples/script_to_oop_transformation.md - 上帝对象/上帝类 - 单个类承担过多不相关职责
高优先级修复:
3. 复杂嵌套条件(>3层)
4. 长函数(>30行,承担多个职责)
5. 魔法数字和字符串
6. 晦涩变量名(、、、)
7. 公共API缺失类型提示
8. 缺失或不充分的文档字符串
9. 不清晰的错误处理
10. 单个函数中混合不同抽象层级
xtmpdatad中优先级修复:
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:
| Metrica | Tool | Uso |
|---|---|---|
| Cognitive Complexity | complexipy | Comprensibilità umana |
| Cyclomatic Complexity | ruff (C901), radon | Test planning |
| Maintainability Index | radon | Salute generale codice |
不要仅依赖单一指标。组合使用:
| 指标 | 工具 | 用途 |
|---|---|---|
| 认知复杂度 | complexipy | 人类可读性 |
| 圈复杂度 | ruff (C901), radon | 测试规划 |
| 可维护性指数 | radon | 代码整体健康度 |
Stack Raccomandato: Ruff + Complexipy
推荐工具栈:Ruff + Complexipy
bash
undefinedbash
undefinedSetup 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
undefinedruff check src/ # 快速lint(基于Rust,速度是flake8的150-200倍)
complexipy src/ --max-complexity-allowed 15 # 认知复杂度(基于Rust)
radon mi src/ -s # 可维护性指数
undefinedPerché Ruff + Complexipy?
为什么选择Ruff + Complexipy?
| Tool | Vantaggi |
|---|---|
| Ruff | Standard de facto, 800+ regole, velocissimo (Rust), sostituisce flake8+plugins |
| Complexipy | Cognitive 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
undefinedbash
undefinedAnalisi 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
undefinedcomplexipy src/ --max-complexity-allowed 15
undefinedAPI Python
Python API
python
from complexipy import file_complexity, code_complexitypython
from complexipy import file_complexity, code_complexityAnalizza 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})")
undefinedresult = file_complexity("src/user_service.py")
for func in result.functions:
if func.complexity > 15:
print(f"⚠️ {func.name}: {func.complexity} (行 {func.line_start})")
undefinedPre-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: 15yaml
- name: Ruff
uses: astral-sh/ruff-action@v1
- name: 认知复杂度检查
uses: rohaquinlop/complexipy-action@v2
with:
paths: src/
max_complexity_allowed: 15Cognitive Complexity: Dettagli Importanti
认知复杂度:重要细节
Vedi per la guida completa. Punti chiave:
references/cognitive_complexity_guide.mdRegole 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
undefinedSetup (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:**
```bashwily graph src/module.py complexity
**CI集成用于趋势检查:**
```bashFail se complessità AUMENTATA rispetto a commit precedente
如果复杂度较上一次提交增加,则失败
wily diff src/ -r HEAD~1..HEAD
undefinedwily diff src/ -r HEAD~1..HEAD
undefinedThreshold Progressivi per Legacy Code
遗留代码的渐进式阈值
Non applicare threshold stretti immediatamente su legacy:
ini
undefined不要对遗留代码立即应用严格阈值:
ini
undefinedFase 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":**
```bashmax-cognitive-complexity = 10
**“仅修改文件”策略:**
```bashStrict 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
undefinedCHANGED=$(git diff --name-only origin/main...HEAD -- '*.py')
for f in $CHANGED; do
flake8 "$f" --max-cognitive-complexity=10 # 严格阈值
done
undefinedComplexity 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.htmlThree-tier plugin system (16 curated plugins for maximum readability):
ESSENTIAL (Must-Have - Install First):
- flake8-bugbear: Finds likely bugs and design problems (B codes)
- flake8-simplify: Suggests simpler, clearer code (SIM codes)
- flake8-cognitive-complexity: Measures cognitive load (CCR codes)
- pep8-naming: Enforces clear naming conventions (N codes)
- 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-docstringsInstall 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-spellcheckAnalysis 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 configuration file () for consistent analysis.
.flake8assets/.flake8bash
python scripts/analyze_with_flake8.py <file_or_directory> \
--output report.json \
--html report.html三层插件系统(16个精选插件,最大化可读性):
核心插件(必须安装 - 优先安装):
- flake8-bugbear:发现潜在bug和设计问题(B类代码)
- flake8-simplify:建议更简洁、清晰的代码(SIM类代码)
- flake8-cognitive-complexity:测量认知负载(CCR类代码)
- pep8-naming:强制清晰的命名规范(N类代码)
- 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报告
配置:
使用提供的配置文件()以保证分析一致性。
.flake8assets/.flake8Flake8 Before/After Comparison
Flake8前后对比
bash
python scripts/compare_flake8_reports.py before.json after.json \
--html comparison.htmlComparison 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 for data containers
dataclasses - Path handling: Use over
pathlibos.path - Error handling: Specific exceptions, not bare
except - Modern features: f-strings, context managers, comprehensions (when clear)
- 类型提示:所有公共API和复杂内部逻辑都需添加
- 文档字符串:推荐使用Google风格
- 数据结构:使用作为数据容器
dataclasses - 路径处理:使用替代
pathlibos.path - 错误处理:使用特定异常,而非裸
except - 现代特性:f字符串、上下文管理器、推导式(当清晰时使用)
JavaScript/TypeScript
JavaScript/TypeScript
- Types: Explicit TypeScript types for all public APIs
- Async: Prefer over callbacks or raw promises
async/await - Destructuring: Use for clarity, not just brevity
- Immutability: Prefer , avoid mutation when practical
const - Error handling: Try/catch for async, explicit error types
- 类型:所有公共API使用显式TypeScript类型
- 异步:优先使用而非回调或原始Promise
async/await - 解构:用于提升清晰度,而非仅为简洁
- 不可变性:优先使用,实际可行时避免突变
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.mdSummary Structure
总结结构
markdown
undefinedmarkdown
undefinedRefactoring Summary
重构总结
File:
Date: YYYY-MM-DD
Risk Level: [Low/Medium/High]
path/to/file.py文件:
日期: YYYY-MM-DD
风险等级: [低/中/高]
path/to/file.pyChanges Made
已做变更
-
Extracted methodfrom
validate_user_inputprocess_request- Rationale: Function was 85 lines, violated SRP
- Risk: Low (pure extraction, no logic changes)
-
Renamed→
ddiscount_percentage- Rationale: Improved clarity
- Risk: Low (local variable)
-
Added guard clauses to reduce nesting from 5 to 2 levels
- Rationale: Improved readability, eliminated arrow code
- Risk: Low (behavior preserved, tests pass)
-
从中提取方法
process_requestvalidate_user_input- 理由:原函数85行,违反SRP原则
- 风险:低(纯提取,无逻辑变更)
-
将重命名为
ddiscount_percentage- 理由:提升清晰度
- 风险:低(局部变量)
-
添加卫语句,将嵌套从5层减少到2层
- 理由:提升可读性,消除箭头代码
- 风险:低(行为保留,测试通过)
Metrics Improvement
指标改进
| Metric | Before | After | Change |
|---|---|---|---|
| Avg Cyclomatic Complexity | 18.5 | 7.2 | -61% ✓ |
| Avg Function Length | 47 lines | 22 lines | -53% ✓ |
| Max Nesting Depth | 5 | 2 | -60% ✓ |
| Docstring Coverage | 45% | 92% | +104% ✓ |
| Type Hint Coverage | 30% | 95% | +217% ✓ |
| 指标 | 重构前 | 重构后 | 变化 |
|---|---|---|---|
| 平均圈复杂度 | 18.5 | 7.2 | -61% ✓ |
| 平均函数长度 | 47行 | 22行 | -53% ✓ |
| 最大嵌套深度 | 5 | 2 | -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否 - 变更为低风险机械改进,且有完整测试覆盖。
如果是,指定需审查的区域:
- [不适用]
undefinedIntegration with Same-Package Skills
与同包技能的集成
This skill works in synergy with other skills in :
python-development本技能与中的其他技能协同工作:
python-developmentpython-testing-patterns
python-testing-patterns
- Before refactoring: Use to set up comprehensive pytest fixtures, mocking, and coverage
python-testing-patterns - 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 skill
python-testing-patterns
- 重构前:使用设置全面的pytest夹具、模拟和覆盖率
python-testing-patterns - 重构中:参考测试模式编写验证测试
- 重构后:验证测试覆盖率未下降
- 调用时机:如需详细的pytest模式、夹具、参数化 → 使用技能
python-testing-patterns
python-performance-optimization
python-performance-optimization
- Before refactoring: Use for deep profiling with cProfile, py-spy, memory_profiler
python-performance-optimization - After refactoring: Run benchmark validation using profiling patterns
- Note: This skill's script is for quick regression checks; use the performance skill for deep analysis
benchmark_changes.py - Invoke: For runtime profiling, memory analysis, optimization → use skill
python-performance-optimization
- 重构前:使用进行深度性能分析,使用cProfile、py-spy、memory_profiler
python-performance-optimization - 重构后:使用性能分析模式运行基准验证
- 注意:本技能的脚本用于快速回归检查;如需深度分析,使用性能优化技能
benchmark_changes.py - 调用时机:如需运行时分析、内存分析、优化 → 使用技能
python-performance-optimization
python-packaging
python-packaging
- After refactoring: If refactoring a library, use for proper pyproject.toml and distribution setup
python-packaging - Invoke: For packaging, publishing to PyPI → use skill
python-packaging
- 重构后:如果重构的是库,使用进行规范的pyproject.toml和分发设置
python-packaging - 调用时机:如需打包、发布到PyPI → 使用技能
python-packaging
uv-package-manager
uv-package-manager
- Use commands referenced in this skill (
uv,uv run ruff)uv run complexipy - Invoke: For dependency management, virtual environments → use skill
uv-package-manager
- 使用本技能中引用的命令(
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 skill
async-python-patterns
- 重构异步代码时,参考异步模式以获得规范的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 for comprehensive before/after examples across different scenarios:
references/examples/- - Complete transformation from script-like "spaghetti code" to clean OOP architecture (MUST READ)
examples/script_to_oop_transformation.md - - Nested conditionals and long functions
examples/python_complexity_reduction.md - - Variable and function renaming with TypeScript patterns
examples/typescript_naming_improvements.md
See for comprehensive guides:
references/- - Mandatory checklist to prevent regressions (MUST READ)
REGRESSION_PREVENTION.md - - Complete guide to cognitive complexity calculation, patterns, and tools
cognitive_complexity_guide.md - - All refactoring patterns with examples
patterns.md - - Common anti-patterns to fix
anti-patterns.md - - SOLID principles and OOP best practices
oop_principles.md - - Plugin ecosystem for code quality
flake8_plugins_guide.md
见获取不同场景的完整重构前后示例:
references/examples/- - 从类脚本“面条代码”到整洁OOP架构的完整转换(必读)
examples/script_to_oop_transformation.md - - 嵌套条件和长函数的重构
examples/python_complexity_reduction.md - - TypeScript变量和函数重命名模式
examples/typescript_naming_improvements.md
见获取完整指南:
references/- - 防止回归的强制检查清单(必读)
REGRESSION_PREVENTION.md - - 认知复杂度计算、模式和工具的完整指南
cognitive_complexity_guide.md - - 所有重构模式及示例
patterns.md - - 需修复的常见反模式
anti-patterns.md - - SOLID原则和OOP最佳实践
oop_principles.md - - 代码质量插件生态
flake8_plugins_guide.md
Success Criteria
成功标准
Refactoring is successful when:
- ✓ ZERO REGRESSIONI - All existing tests pass, behavior unchanged
- ✓ Golden master match - Output identico per casi critici documentati
- ✓ Complexity metrics improved (documented in summary)
- ✓ No performance regression >10% (or explicit approval obtained)
- ✓ Documentation coverage improved
- ✓ Code is easier for humans to understand (subjective but validated by metrics)
- ✓ No new security vulnerabilities introduced
- ✓ Changes are atomic and well-documented in git history
- ✓ Wily trend - Complessità non aumentata rispetto a commit precedente
- ✓ Static analysis shows improvement (flake8 issues reduced)
重构成功的标志:
- ✓ 零回归 - 所有现有测试通过,行为未改变
- ✓ 标准输出匹配 - 关键场景的输出与记录的完全一致
- ✓ 复杂度指标已改进(记录在总结中)
- ✓ 性能下降未超过10%(或已获得明确批准)
- ✓ 文档覆盖率已提升
- ✓ 代码更易于人类理解(主观但可通过指标验证)
- ✓ 未引入新安全漏洞
- ✓ 变更为原子操作,且Git历史记录清晰
- ✓ Wily趋势 - 复杂度较上一次提交未增加
- ✓ 静态分析显示改进(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.
系统应用本技能,将难以维护的代码转换为清晰、文档完善、可维护的代码。遵循四阶段工作流,逐步应用模式,持续验证,并知道何时停止。在可读性和实用性之间取得平衡 - 目标是让人类可以自信修改的代码,而非无人敢碰的“完美”代码。