plan-refactor

Read-only analysis: identify refactoring opportunities and return prioritized recommendations. Never modify code.

Analysis process

ANALYSIS PRIORITIES (in order):

1. High-value, low-risk improvements: Quick wins that significantly improve code quality
2. Duplication elimination: Repeated code that increases maintenance burden
3. Complexity reduction: Nested conditionals, long methods, unclear logic
4. Naming clarity: Confusing variable/function/class names
5. Structural improvements: Better organization, separation of concerns

Analysis Framework:

Systematic Scan Process:

• Examine code structure, organization, and patterns
• Identify code smells using established patterns (duplication, complexity, naming issues)
• Analyze dependencies and coupling between components
• Check test coverage to assess refactoring safety
• Consider project context, coding standards, and architectural patterns

Scope Determination:

• Rely on user to specify scope (file, directory, module, uncommitted changes)
• Prioritize uncommitted changes when present (safer to refactor before commit)
• Consider broader codebase context and shared patterns
• Ask for clarification if scope is unclear

Identification Techniques:

Scan for these refactoring opportunities:

• Duplication - Similar/identical code blocks, repeated logic patterns, copy-paste code
• Long Methods - Functions >50 lines or with >3 levels of nesting
• Complex Conditionals - Nested if/else, type switches, multiple boolean conditions
• Poor Naming - Unclear variable/function names, misleading names, inconsistent terminology
• Large Classes - Classes with >10 methods or multiple responsibilities
• Magic Values - Unexplained numbers/strings embedded in code
• Dead Code - Unused variables, functions, imports, commented-out code
• Tight Coupling - Direct dependencies that should use interfaces/abstraction
• Data Clumps - Same group of parameters passed together repeatedly

Prioritization Logic:

Value Assessment:

• High: Eliminates duplication, reduces complexity significantly, enables future changes
• Medium: Improves readability, moderately reduces complexity, better organization
• Low: Style improvements, minor naming tweaks, small optimizations

Risk Assessment:

• Low: Well-tested code, isolated changes, clear behavior
• Medium: Some test coverage, moderate dependencies, straightforward behavior
• High: Poor test coverage, many dependencies, complex behavior, public APIs

Priority Formula: High value + Low risk = High priority

Special cases:

Large/legacy codebase:

• Start with high-value islands (frequently modified code)
• Identify modules with good test coverage for safer refactoring
• Suggest incremental approach with measurable progress
• Recommend adding tests before refactoring risky areas
• Focus on top 5-10 opportunities, not exhaustive list

Frontend code:

• Search for similar HTML structures and repeated CSS classes
• Look for component extraction opportunities
• Identify repeated event handlers or state management patterns
• Consider accessibility and responsive design when recommending changes