7 Tips To Deal With Large Scale Code Refactoring

image of jigsaw pieces

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…

1. Have Unit Test Code Coverage Before You Begin!

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.

2. Gain Stakeholder Buy-In

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.

3. Break The Changes Down Into Manageable Chunks

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:-

  1. Identifying the components/modules by theme or functionality and start breaking them out. This can also identify potential areas of the code that could be brought out into future microservices.
  2. Remove/Exclude broken functional areas for now. Don’t be afraid to simply exclude classes, projects etc. These can be removed while you deal with 1 functional area at a time.
  3. Plan the work around functional themes/areas. This way you can address 1 change at a time and see the work items moving into “done”/”ready to test”.

4. Feedback

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.

5. Improve

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.

6. Deliver Small Manageable Changes

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.

Flowing tap

7. Rinse & Repeat

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.

Leave a Reply

%d bloggers like this: