Some ideas for this post have been taken from Jordan Powell talk on Angular Tiny Conf.
The goal of refactoring is to improve internal code by making many small changes without altering the code’s external behavior.
Improve Code by
- Making it more Efficient
- Making it more Maintainable
- Making it more Reusable (code that isn’t reusable today might need to be reused it many places, so refactoring is the way.
- Making it cleaner (because tidiness it makes us happy ????)
When Should Code Be Refactored?
After Deployment
After delivering feature, and before new task, revisit the code you shift. Can you refactor it, add quality of life to codebase. This way you can ship faster and the sooner you get feedback whether it delivers the value.
Before New Features
As new features requested or new bugs addressed, you can allocate some time to refactor and just clearing the stage for next big thing.
Regular Part of Software Lifecycle
Just make it a regular part of software lifecycle. A day or two after every Sprint. Or certain percent of sprint work, Every Quarter or when business is slow. The longer you wait to refactor the bigger the mess will be.
Best Practices When Refactoring
- Plan for it
- Refactor first
- Small Steps (smaller refactor smaller PR and easy to merge, larger refactor has more changes to cause regression)
- Test often
- Fix defects separately (when refactoring you came across the code that is necessary or defecting. Because refactoring intention is to only change the internal implementation not the external behavior