One of the main bitter truths every developer should learn sooner or later is that no matter how good is the code you have written, the day will come and you will have to change it. This happens majorly not because of developer skills, but to specifics of this job. World is changing, so requirements do. Introducing changes to the code is closely connected with refactoring. Today we will learn how to do it right.
We have gathered 5 main things you need to know about refactoring to make efficient and simply working for your business. These are some insights world-leading developers are sharing. So we gathered their knowledge, spiced it up with a bit of our own and are ready to present it to you.
Tip 1. Why refactoring is important.
Before you even start refactoring, you should understand, why at all you need to come back to the old code and rewrite it. The essence of refactoring is not to make your code better, but to make it easier to understand. So that when future you or other developers will come to change the system behavior, they would easily understand how to do this. So this is not about the code logic, but code style as well.
Refactoring not only simplifies introduction of any changes to the code, but makes the development cost-efficient. Since it’s much easier (and cheaper) to rewrite the code, while you still have all details in mind than come back to it 2 years later with no idea what you meant previously.
Tip 2. Go for ‘shameless green’ first
‘Shameless green’ is a term used by some developers, which means that you should pass test (i.e. get green light) no matter how ugly your code is. When you are writing the code for new functionality don’t overthink it and go for the easiest option available. Simply make it work. But at the same time make sure the code is easy to understand.
So when you go back to refactor it, it wouldn’t take long to figure out what is going on here. But at refactor time you will already have a bigger picture on functionality, so it would be easier to select the most suitable solution.
Tip 3. Don’t be shy to duplicate
This tip goes together with the previous one. When writing new code, don’t be shy to duplicate. Prefer sweet and easy duplication to high-headed abstraction.
‘But why should I do that?’ – you might ask. The reason here is that duplication is extremely easy to understand and it’s hard to do anything wrong with it. And though abstraction is efficient, it is still pretty complex. So it is much better to avoid abstraction before refactoring to make sure everything is taken into account and room for mistakes is minimized.
Tip 4. Safety first
Now that you know how to prepare the code for refactoring, have a look at some tips on how to refactor it right. The first rule of refactoring – make it as safe as possible.
Plenty developers enjoy writing complex code, but in many cases it means that you are creating new bugs and then spend tons of time trying to figure out what’s wrong. This makes refactoring very pricey and inefficient. We are not saying your code shouldn’t be complex, but while refactoring, it’s better to run tests after every change you make.
Of course, it might be not so entertaining, but it would give you good grounds to be sure you haven’t spoiled anything.
Tip 5. Be detached to your code
And finally, though you might see the code you write a your little baby, you should be emotionally detached from it. Don’t be shy (or lazy) to delete it all and start from a blank page. Remember, it is not about repurposing lines of code, but making code easy to scale and understand. And if it requires bold moves, go for it.
Hope now, your refactor skills have improved. Go practice a bit and share what you think in the comments. Or you can always ask our team to help yours 🙂
