A few weeks back I noticed that a part of the code that I’d been working on for over a year seemed to be growing in size and needed to be addressed in order to avoid future headaches and pain. The code is by no means monolithic but of a significant size to be a thing in it’s own right and not a quick 15 minute fix. I could see that action was needed in order to support future maintainability and scalability. Here’s 7 tips for refactoring…
If you don’t have unit tests covering the existing code then why not?!. You’re simply not going to be able to confidently refactor without a high percentage of test coverage across the all important business logic. If you don’t have this in place before you begin then you have to either invest in the time now to get the unit tests in or forget it. Seriously, it’s just not worth attempting otherwise.
Ensure that stakeholders are informed of why, what, when. Why you have to do this, what is it you’re doing and when (i.e some form of temporal data on how long the work is going to take and estimated delivery time) Agile/Scrum pointing can play a part here.
It would be crazy/demoralizing/suicidal! to lock yourself away for a few days/weeks and holistically tackle the entire refactor. Break the work down into modular chunks by:-
Depending on the size of the workload it’s worthwhile updating any stakeholders. If you’re following Scrum then you’ll already be doing this in the Stand-ups.
Whilst we’re “in among the weeds” of the code we can sometimes identify areas that haven’t been touched for days/weeks/months. If you see something that can be improved then don’t be afraid to tackle it if it’s a quick fix (or even better) open an improvements style Story into the backlog.
Hand in hand with Point 3 the refactoring changes should be delivered in relatively short-lived chunks. Let the Pull Requests be short and the CI/CD pipelines (and toolset) work to your advantage here.
Once you’re done don’t be afraid to challenge the code and it’s architecture again. Ideally, the upfront planning and architecture should have alleviated the need to have to refactor to made the code scalable however, as a Developer getting Sprints over the line and tackling business requirements, a changing landscape/environment the code can become bloated. If you can see scalability becoming a problem or Class sizes becoming unwieldly then stand up and shout!. It’s better to tackle the issue sooner rather than later.