Restructuring code before implementing new features
Core Idea: Refactor code to make a change easier before implementing the change itself, producing cleaner, more maintainable code and simpler reviews.
Key Elements
- Based on Martin Fowler's principle: first refactor to make the change easy, then make the easy change
- Refactoring changes are semantics-preserving, making them easier to evaluate than functional changes
- Current LLMs don't naturally decompose changes this way without explicit planning instructions
- Models may act like overeager junior engineers, cleaning up unrelated code while implementing changes
- This complicates code review by mixing refactoring with functional changes
Implementation Strategies
- Explicitly instruct LLMs to separate refactoring from functional changes
- Perform a separate refactoring pass before implementing new features
- Be specific about which code areas should be modified
- Review refactoring changes independently from functional changes
- Be cautious with context that emphasizes "good practices" as this may encourage excessive refactoring
Connections
- Related Concepts: Rule of Three (recognizing when refactoring is needed), Black Box Testing (maintaining proper testing boundaries)
- Broader Context: Clean Code Principles (approaches to maintainable software)
- Applications: LLM Code Review (reviewing AI-generated code changes)
References
- Martin Fowler (2018). "Preparatory Refactoring Example." https://martinfowler.com/articles/preparatory-refactoring-example.html
- Edward Z. Yang (2025). "AI Blindspots" collection, March 2025.
#refactoring #code-quality #software-development #martin-fowler
Connections:
Sources:
- From: AI Blindspots