Refactoring
Also Known As
- Code Cleanup
- Code Optimization
- Creating Abstractions
- Factoring
- Modularisation
- Separation of Concerns
- Technical Debt Management
Related
Addresses / Mitigates
- Complexity Risk: Refactoring is aimed at making code more orthogonal, less duplicative and clearer to understand
- Implementation Risk: Enhances code quality and maintainability.
- Communication Risk: Well-factored code should be easier to understand.
Attendant Risks
- Schedule Risk: Refactoring can be time-consuming and delay project timelines.
- Regression Risk: Done carelessly, refactoring can introduce new issues into the codebase
Used By
- Extreme Programming: XP encourages continuous refactoring to improve the design of existing code and maintain its quality.
- Scrum: Refactoring is encouraged to maintain code quality within Scrum.
Description
"Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring improves nonfunctional attributes of the software." - Code refactoring, Wikipedia
Refactoring involves revising and restructuring existing code to improve its readability, maintainability, and performance without changing its external behavior. This practice helps in reducing technical debt, enhancing code quality, and making the codebase easier to understand and modify.
Abstractions
Refactoring is all about ensuring you have the right abstractions.
"An abstraction" is the outcome of this process—a concept that acts as a common noun for all subordinate concepts and connects any related concepts as a group, field, or category.
See:
External References
- Separation of Concerns Wikipedia Page.
- Refactoring Book by Martin Fowler.
See Also
Extreme Programming
An Agile software development methodology that emphasizes customer satisfaction, teamwork, and frequent delivery of small, functional software increments.
Scrum
An Agile framework for managing and completing complex projects.
Coding Bets
How Coding, Investing and Gambling are similar undertakings.
Complexity Risk
A lot of advice around constructing software comes back to simplicity. Why?