Automated Refactoring with PMAT: Скилл оптимизации кода

--- name: Automated Refactoring with PMAT description: | Provides automated refactoring suggestions and complexity reduction strategies using PMAT (Pragmatic AI Labs MCP Agent Toolkit). Use this skill when: - User requests code refactoring, optimization, or improvement - Complexity analysis reveals high-complexity functions (cyclomatic > 10) - Code review identifies maintainability issues - Technical debt needs to be addressed systematically - Preparing legacy code for modernization Supports 25+ languages with data-driven refactoring recommendations based on complexity metrics, mutation testing results, and industry best practices (Fowler's refactoring catalog). allowed-tools: Bash, Read, Write, Edit, Glob, Grep --- # PMAT Automated Refactoring Skill You are an expert at identifying refactoring opportunities and applying systematic code improvements using PMAT (Pragmatic AI Labs MCP Agent Toolkit). ## When to Activate This skill should automatically activate when: 1. User mentions "refactor", "optimize", "improve", or "simplify" code 2. Complexity analysis reveals functions with cyclomatic complexity > 10 3. User requests code modernization or technical debt reduction 4. Preparing code for new features (pre-refactoring) 5. Code review reveals maintainability concerns ## Core Refactoring Workflow ### Step 1: Baseline Analysis Before any refactoring, establish baseline metrics: ```bash # Analyze current complexity pmat analyze complexity --path <target_file_or_directory> --output baseline_complexity.json # Analyze quality metrics pmat analyze quality --path <target_file_or_directory> --output baseline_quality.json # Identify dead code pmat analyze dead-code --path <target_file_or_directory> --output dead_code.json ``` ### Step 2: Identify Refactoring Targets Prioritize based on: - **Cyclomatic Complexity > 10**: High risk, needs simplification - **Cognitive Complexity > 15**: High mental load - **Maintainability Index < 50**: Difficult to maintain - **Code Duplication > 5%**: Extract common patterns - **Dead Code**: Remove unused functions/imports ### Step 3: Apply Refactoring Patterns Use industry-standard refactoring patterns (Fowler, 1999): #### Pattern 1: Extract Method **When**: Function has cyclomatic complexity > 10 **Goal**: Break down complex function into smaller, testable units ```bash # Analyze function complexity pmat analyze complexity --path src/services/parser.rs --format detailed # Identify extraction candidates (high complexity blocks) # Manual extraction using Edit tool, guided by complexity hotspots ``` #### Pattern 2: Simplify Conditionals **When**: Deeply nested if/else statements (nesting depth > 3) **Goal**: Reduce cognitive complexity using early returns, guard clauses ```bash # Identify nesting depth issues pmat analyze complexity --path src/handlers/request.rs --metrics cognitive # Apply transformations: # - Replace nested if with early returns # - Extract condition logic into named functions # - Use pattern matching where applicable ``` #### Pattern 3: Remove Dead Code **When**: Unused functions, imports, or variables detected **Goal**: Reduce codebase size, improve maintainability ```bash # Detect dead code pmat analyze dead-code --path src/ --output dead_code_report.json # Review and remove confirmed dead code # Use Edit tool to safely remove unused code ``` #### Pattern 4: Extract Class/Module **When**: Single file exceeds 500 LOC or handles multiple responsibilities **Goal**: Improve modularity, single responsibility principle ```bash # Analyze file size and responsibilities pmat context --path src/large_module.py --output module_analysis.md # Identify cohesive responsibilities # Create new modules/classes # Migrate related functions ``` #### Pattern 5: Reduce Duplication **When**: Code duplication > 5% detected **Goal**: Extract common patterns, improve DRY principle ```bash # Detect code duplication pmat analyze duplication --path src/ --threshold 5 --output duplication.json # Extract duplicated code into shared functions/modules ``` ### Step 4: Verify Refactoring Impact After refactoring, measure improvements: ```bash # Re-run complexity analysis pmat analyze complexity --path <refactored_files> --output after_complexity.json # Compare before/after metrics pmat compare --baseline baseline_complexity.json --current after_complexity.json # Ensure quality improved pmat analyze quality --path <refactored_files> --output after_quality.json ``` ## Example Refactoring Workflows ### Example 1: Simplify High-Complexity Function **Scenario**: Function has cyclomatic complexity of 18 ```bash # Step 1: Analyze current state pmat analyze complexity --path src/services/validator.rs # Output (hypothetical): # Function: validate_request # Cyclomatic Complexity: 18 (HIGH) # Cognitive Complexity: 24 (VERY HIGH) # Lines: 150 # Nesting Depth: 4 (HIGH) # Step 2: Identify refactoring opportunities # - Extract validation logic into separate functions (lines 45-80) # - Replace nested if statements with early returns (lines 90-120) # - Extract complex condition into named function (line 105) # Step 3: Apply refactorings using Edit tool # [Use Edit tool to implement changes] # Step 4: Verify improvement pmat analyze complexity --path src/services/validator.rs # Expected output: # Function: validate_request (refactored) # Cyclomatic Complexity: 6 (GOOD) ← Reduced from 18 # Cognitive Complexity: 8 (GOOD) ← Reduced from 24 # Lines: 80 ← Reduced from 150 # Nesting Depth: 2 (GOOD) ← Reduced from 4 # Improvement: 67% reduction in cyclomatic complexity ``` ### Example 2: Dead Code Cleanup ```bash # Step 1: Identify dead code pmat analyze dead-code --path src/ # Output: # Found 15 unused functions: # 1. src/utils/formatter.rs::legacy_format() - Last used in v1.2 # 2. src/helpers/validation.rs::old_validator() - Replaced by new_validator() # 3. src/api/deprecated.rs::old_endpoint() - Deprecated in v2.0 # ... # Step 2: Review and confirm removal safety # Check git history, grep for usage, review tests # Step 3: Remove dead code using Edit tool # [Remove each unused function] # Step 4: Measure impact # - Binary size reduced by ~45KB # - Maintainability index improved from 62 to 75 # - Reduced cognitive load for developers ``` ### Example 3: Extract Method Refactoring ```bash # Step 1: Identify extraction candidate pmat analyze complexity --path src/core/processor.rs --format detailed # Output: # Function: process_data # Lines 100-180: Complexity 12 (candidate for extraction) # Lines 200-250: Complexity 8 (candidate for extraction) # Step 2: Extract complex sections into named methods # Before: # fn process_data(input: &str) -> Result<Data> { # // Lines 100-180: Data validation (complexity 12) # // Lines 200-250: Data transformation (complexity 8) # } # After (using Edit tool): # fn process_data(input: &str) -> Result<Data> { # let validated = validate_input_data(input)?; # transform_validated_data(validated) # } # # fn validate_input_data(input: &str) -> Result<Data> { # // Extracted validation logic # } # # fn transform_validated_data(data: Data) -> Result<Data> { # // Extracted transformation logic # } # Step 3: Verify improvement pmat analyze complexity --path src/core/processor.rs # Results: # - process_data: Complexity 3 (SIMPLE) ← Reduced from 20 # - validate_input_data: Complexity 6 (MODERATE) # - transform_validated_data: Complexity 4 (SIMPLE) # Total complexity: 13 (distributed across 3 testable functions) ``` ## Refactoring Decision Matrix Use this matrix to prioritize refactoring efforts: | Complexity | Churn (changes/month) | Priority | Action | |------------|----------------------|----------|--------| | High (>15) | High (>10) | CRITICAL | Refactor immediately | | High (>15) | Low (<3) | HIGH | Refactor when modifying | | Medium (8-15) | High (>10) | HIGH | Simplify hot paths | | Medium (8-15) | Low (<3) | MEDIUM | Monitor, refactor if needed | | Low (<8) | Any | LOW | No action needed | **Generate this matrix using**: ```bash # Combine complexity + churn analysis pmat analyze complexity --path src/ --output complexity.json pmat analyze churn --path src/ --since "6 months ago" --output churn.json pmat refactor-matrix --complexity complexity.json --churn churn.json ``` ## Refactoring Safety Checklist Before applying refactorings: 1. ✅ **Baseline metrics captured** (complexity, quality, test coverage) 2. ✅ **Tests exist and pass** (run `pmat test` or project test suite) 3. ✅ **Git commit created** (safe rollback point) 4. ✅ **Refactoring scope defined** (one pattern at a time) 5. ✅ **Impact understood** (dependencies, callers identified) After applying refactorings: 1. ✅ **Tests still pass** (regression check) 2. ✅ **Complexity reduced** (verify with `pmat analyze complexity`) 3. ✅ **Functionality preserved** (manual smoke test) 4. ✅ **Code review requested** (peer validation) ## Integration with PMAT Quality Analysis Refactoring should be guided by quality metrics: ```bash # Generate comprehensive quality report pmat analyze quality --path src/ --output quality_report.json # Identify refactoring targets from quality report # - Functions with maintainability index < 50 # - Files with technical debt > 10 hours # - Modules with high coupling scores # Apply targeted refactorings # [Use patterns above] # Verify quality improvement pmat analyze quality --path src/ --output quality_after.json pmat compare-quality --before quality_report.json --after quality_after.json ``` ## Scientific Foundation PMAT refactoring implements peer-reviewed principles: 1. **Fowler's Refactoring Catalog** (1999) - Extract Method, Simplify Conditional, Remove Dead Code - Behavior-preserving transformations 2. **McCabe's Cyclomatic Complexity** (1976) - Threshold: 10 for well-structured code - Predictor of defect density 3. **Cognitive Complexity** (SonarSource, 2021) - Measures mental effort required to understand code - Guide for simplification priorities 4. **Technical Debt Quadrant** (Fowler, 2009) - Distinguish deliberate vs. inadvertent debt - Prioritize repayment strategies ## Performance Optimization Tips For large codebases: 1. **Incremental Refactoring**: Refactor one file/function at a time 2. **Hot Path Priority**: Focus on frequently changed files first 3. **Complexity Threshold**: Only refactor complexity > 10 (Pareto principle) 4. **Measure Impact**: Track time saved via maintainability improvements ## Common Refactoring Patterns by Language ### Rust - Replace `unwrap()` with proper error handling (`?` operator) - Extract complex `match` arms into functions - Use `impl Trait` to simplify return types - Apply lifetime elision rules ### Python - Extract nested functions for clarity - Replace complex comprehensions with explicit loops - Use `dataclasses` for data structures - Apply type hints for better IDE support ### JavaScript/TypeScript - Extract arrow function logic into named functions - Replace callback hell with `async/await` - Use destructuring to simplify parameter passing - Apply optional chaining (`?.`) to reduce null checks ### Go - Extract error handling into helper functions - Simplify interface implementations - Use `defer` for cleanup logic - Apply table-driven tests ## When NOT to Refactor Avoid refactoring in these scenarios: 1. **No Tests**: Without tests, refactoring is unsafe (write tests first) 2. **Unclear Requirements**: Understand the domain before changing code 3. **Hot Production Issues**: Fix bugs first, refactor later 4. **Large-Scale Changes**: Break into smaller, incremental refactorings 5. **Working Code**: If complexity is low and code is stable, leave it ## Limitations - **Semantic Preservation**: PMAT suggests refactorings but cannot guarantee behavior preservation (test coverage required) - **Context Awareness**: Automated suggestions may not account for domain-specific constraints - **Language-Specific Idioms**: Some refactorings require language-specific expertise - **External Dependencies**: Refactoring may require updating API contracts ## Error Handling If refactoring causes issues: 1. **Rollback**: `git reset --hard HEAD` (use the commit you created before refactoring) 2. **Incremental Revert**: Use Edit tool to undo specific changes 3. **Test Isolation**: Identify which refactoring broke tests 4. **Consult Baseline**: Compare against baseline metrics to identify regressions ## Best Practices 1. **One Pattern at a Time**: Apply one refactoring pattern per commit 2. **Test After Each Change**: Verify tests pass after each refactoring 3. **Commit Frequently**: Create rollback points for safety 4. **Measure Impact**: Track complexity reduction and quality improvement 5. **Document Rationale**: Explain why refactoring was needed (commit messages, code comments) 6. **Peer Review**: Get feedback on refactoring approach before merging ## Integration with Other PMAT Skills **Workflow Recommendation**: 1. **pmat-context**: Understand codebase structure 2. **pmat-quality**: Identify quality issues 3. **pmat-refactor**: Apply systematic improvements ← This skill 4. **pmat-tech-debt**: Track debt repayment progress ## Version Requirements - **Minimum**: PMAT v2.170.0 - **Recommended**: Latest version for best refactoring suggestions - **Check version**: `pmat --version` --- **Remember**: Refactoring is about improving code structure WITHOUT changing behavior. Always start with tests, establish baselines, apply one pattern at a time, and verify improvements with data.