tomevault-io Refactor
Analyze code and suggest refactoring opportunities with rationale. This is an analysis-only skill - it identifies and documents refactoring opportunities but does not execute them.
When to Use
- Reviewing code for improvement opportunities
- Planning a refactoring initiative
- Assessing technical debt in a codebase area
- Evaluating complexity, duplication, or coupling concerns
- Understanding blast radius before making changes
Input
- Target: file path, directory/package, or function/component name
- Optional: specific concern (duplication, complexity, coupling, testability, etc.)
Investigation Strategy
Track 1: Codebase Exploration
- Map dependencies and call sites for target code
- Identify blast radius of potential changes
- Find related code with similar patterns
- Assess test coverage of affected areas
Track 2: Code Analysis
- Deep analysis of code smells and patterns
- Identify refactoring opportunities
- Assess complexity metrics
- Evaluate maintainability concerns
Refactoring Patterns
Universal Patterns
| Pattern | Description |
|---|---|
| Extract function/method | Pull out reusable logic |
| Inline function/variable | Remove unnecessary indirection |
| Rename | Improve clarity (with blast radius assessment) |
| Move | Relocate to better home (file, package, module) |
| Replace conditional with polymorphism | Simplify branching |
| Introduce parameter object | Group related parameters |
| Dependency inversion | Decouple via interfaces/abstractions |
Go-Specific Patterns
| Pattern | Description |
|---|---|
| Extract interface | Define behavior contracts |
| Consolidate error handling | Reduce repetitive error checks |
| Replace concrete with interface | Improve testability |
| Extract middleware | Separate cross-cutting concerns |
| Table-driven refactor | Convert repetitive code to data-driven |
Frontend-Specific Patterns
| Pattern | Description |
|---|---|
| Extract component | Break down large components |
| Extract custom hook | Reuse stateful logic |
| Lift state up | Move state to common ancestor |
| Push state down | Colocate state with usage |
| Extract render function | Simplify complex JSX |
| Memoization | Optimize re-renders |
Output
Document the analysis using the template at references/templates/refactor-analysis.md.
The analysis should include:
- Code smells identified with locations
- Suggested refactorings with risk assessment
- Blast radius for each change
- Recommended order of operations
- Test coverage assessment
Constraints
- Analysis only: Do not execute refactorings - document recommendations
- Blast radius required: Every suggestion must include affected files/functions
- Risk assessment required: Every suggestion must be rated Low/Medium/High
- Order matters: Recommend sequence based on risk and dependencies
- Test awareness: Note test coverage and impact for each suggestion
Example
Refactoring Analysis: pkg/auth/handler.go
Target:
- Path: pkg/auth/handler.go
- Scope: file
- Concern: complexity
Summary:
The auth handler has grown to 450 lines with 3 code smells identified.
Recommend extracting token validation and session management into
separate services. Low-risk changes that improve testability.
Code Smells Identified:
1. Long Function (validateAndCreateSession)
- Location: handler.go:145-280
- Description: 135-line function handling validation, session
creation, and response formatting
- Impact: Hard to test, multiple responsibilities
2. Feature Envy (token validation)
- Location: handler.go:156-198
- Description: Handler reaches into token package internals
- Impact: Tight coupling, changes ripple across packages
Suggested Refactorings:
1. Extract TokenValidator service
- Type: Extract
- Target: handler.go:156-198
- Rationale: Encapsulates token validation logic
- Blast Radius: handler.go, handler_test.go
- Risk: Low — isolated logic, good test coverage
- Test Impact: Add TokenValidator unit tests
2. Extract SessionManager service
- Type: Extract
- Target: handler.go:200-250
- Rationale: Separates session concerns from HTTP handling
- Blast Radius: handler.go, session.go, handler_test.go
- Risk: Medium — touches session storage
- Test Impact: Update integration tests
Recommended Order:
1. TokenValidator first (lowest risk, no dependencies)
2. SessionManager second (depends on cleaner handler)
Begin by identifying the target code and any specific concerns to focus on.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.