Factors to refactor your code
Technical debt is like corruption; a necessary evil in fast-paced development but it’s all about not burying the debt so deep.
Well saying that it’s never too late to revisit, architect or refactor and complete the missing pieces to your one shiny repository.
Here are a few questions that can help you decide; whether it’s time to refactor.
Does your code throw unnecessary errors or print logs in production making it almost difficult to debug issue at the time of need?
Yes, you should refactor the code.
Does your executable code eat memory like an elephant would eat grass non-stop?
Then yes, you should refactor.
Have you ever wondered, why the hell was a particular snippet even written when you could have done the same task without it?
Yes, it’s time to give that code a visit and clean up.
Have you been criticising doing a bug fix in code which was written ages back and it takes you 2x less the time you could have written the functionality anew?
Yes, it’s time to refactor.
Do you ever recall a function or a database query you yourself wrote in a hustle, due to a business-critical requirement but deep down a voice calls and says one day with scale; that piece of code will sting?
Well, ok go and rewrite that code snippet; it’s never too late.
Did you ever leave ToDo’s in your functions to do error handling or write better assertions in your automation tests?
Oh, yes, it’s time to finish those ToDos.
Your Instagram post of a beach vacation of the summer can hold but the errors & missing tests won’t.
If you have read the article till now; I am sure there lies at least one repository where there is a need for either re-architecture/major rehaul or a simple refactor.
At least, give 30 mins to it and think of a better solution and you are one step closer to become a better software engineer.
PS: I’m going to head out and watch Hobbs & Shaw; have you?
