Refactor risk assessment
Refactoring can provide many benefits for an engineering team, including improved readability, maintainability, security, scalability, and performance. In short, refactor should improve the quality of the software.
Careless refactoring can introduce bugs from regression as well as new bugs, rendering quality improvements moot and inducing more load on the team.
Here is one way to evaluate risk induced by refactoring.
Details
No tests with new code: change existing code while adding new, untested code. This risks adding new bugs resulting from changes to existing code as well as changes from newly written code.
- Risks: regression and new bugs.
- Benefits: fastest.
- Use case: MVP, prototyping.
No tests without new code: make changes to existing code without adding new code.
- Risks: regression bugs.
- Benefits: speed.
- Use case: MVP.
With tests and new code: change the existing code adding tests during the changes.
- Risks: speed, new bugs related to new code.
- Benefits: minimizes regression bugs.
- Use case: feature development.
With tests, no new code: ensure the existing code is fully line and branch covered, that the covered code is running correctly in production, then refactor such that all tests pass without changing any of the tests.
- Risks: speed, unless test coverage is already in place.
- Benefits: minimizes regression risk.
- Use case: mature production systems.
QA forms an orthogonal axis to “testing” and “new code,” and can reduce risk even further at the expense of time spent for the QA work. Any refactor which triggers formal QA needs to account for that during the planning phase.