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? You want to access my private github projects?
Support me via Patreon

Originally published at https://dev.to on January 4, 2020.