Tips for a Successful Refactor

Lately we finished a big refactor in one of our products and I want to share with you my insights on the process we did, and my tips for better refactor

What is your Why?

So the Why question is very important, you want to refactor your code because it will:

• enable your to add features you can't add now with your current technology
• make your UX better
• help your system stability
• Etc..

So think about those questions:

• Why you want to do this refactor?
• What are the consequences of the refactor?
• What are the consequences if you WON'T do this refactor?

we need to remember - our customer doesn't see if the code we wrote is clean or beautiful, this is something we as the developers see, and because of that he couldn't care less how we wrote our code, he wants a working product

Not each and every "Why"s is a good "Why", if the refactor won't impact your product and so our customer we might want to keep this one in our backlog for another day

How?

The How is very complicated question, because it is really depends on your use case.
you might want to open a new code base for a big refactor like separate your current monolithic into micro-services or you just want to do a small refactor, and for that I will split it into two tips

Planing

Before you do any work you want to plan your refactor, what is the utopia we want to achieve? think about it and get the approval and commitment from your team,
because if you won't do it, and they will need to add a new feature or fix a bug they will have two options:

1. keep the code the same
2. change the code to the their utopia

If you won't get the approval and commitment from your team they will randomly choose one of those two options, and it doesn't matter which option they chose we will probably refactor this code later, if they chose option 1 we will refactor this code and will implement that feature again, and if they chose option 2 we don't know what is their utopia, and we maybe chose another utopia we want our code to be in, so we will probably refactor this code also

What I recommend to do is to gather your team, tell them your thoughts and think together on the utopia you want to achieve, and make it your destination, and than the next developer that will want to write a new feature will keep this utopia in mind and will get you one step closer and not two steps back

Testings

You want to make sure what you did is working and you didn't break anything,
That's why I recommend you to test your code, mainly to use

• Integration tests are tests that we do in order to a component to make sure it works
• End to End tests are tests that we do in order to make sure that the whole system works, from the user request and to the user response

when we refactor our code we will probably break the Unit tests are tests that we do in order to check a function in our code and only this particular function, when we refactor our code we will maybe delete some of the functions or change the way they works and probably most of the unit tests will break, and we want them to break because we changed our code, but, we don't want our component or the entire product interface to break

Get the approval

In this step you already know what is your Why, and How it will be done,
now you need to explain it to your stakeholders and customers, because it will affect them, the obvious is slowdown or delay for new features, they are the one who pay us so they need to allow us to refactor

And basically after we got the approval, we know everything we need to refactor our code 😄
We know that we won't break our code, and to where we want to get with this refactor

Like this post?
Support me via Patreon
Subscribe to my YouTube Channel

Comments

[Mateusz Gajda]

A big advantage of refactorization for the customer is the reduction of the cost of introducing new changes. This is one of the arguments that can actually convince them. Nothing convinces business as much as money :)

[Corey McCarty]

While time and money are synonymous I find that explaining that the change will make it faster for you to in mplement changes in the future can make business a bit more open to the idea of 'wasting' time with a refractor.

[eranelbaz]

But the real question, it is the true reason you are doing this refactor?
or it is a cover-up?

[Corey McCarty]

Yes and no. I want to refractor because the code base is terrible to try and understand. It takes far too long to walk through. A refractor will keep me from taking a week to understand the flow which will save money. Personally I'm more concerned by the headache of trying to follow the code flow.