Legacy code: Will it haunt or enhance?
Is it *the* foe? Is it *the* absolute terror? Is it *the* blessing in disguise? Or maybe the *king* of boredom? Its name is legacy code and it’s here to haunt you.
Countless hours of struggle and boredom; Countless minds trying to fathom the unfathomable; countless articles trying to document the terror. And yet, here we are again trying to make sense of what is known to awake the fiercest of fears among developers. So…how do we deal with legacy code?
I don’t know if there is one single “best way” to deal with legacy code, both emotionally and practically. But I will try to present you with some ideas and suggestions. Hopefully, you can find what suits you best. What’s more, at the end of this article, we will have a small poll so you can share your ideas and experiences on how to deal with legacy code.
Feel all the feels
In his adorable and inspiring article, Leonardo Brito explores the 5 stages of grief when dealing with legacy code. From denial to anger, bargaining, and depression to acceptance, Brito offers funny, yet extremely practical suggestions on how to prepare yourself, emotionally and mentally in dealing with legacy code.
It is okay to get through all these phases and it’s definitely okay to feel anger with what you have to deal with, disappointment that you are the one who has to deal with it or be depressed that you, probably, have no way out of it. But after you are done feeling all the feels, clear your mind, brace yourself and get to work!
Test this and that…and that…yeah, this one as well
The most important step in dealing with legacy code is the first step. Characterization tests! Legacy code strikes fear into developers because it is difficult to understand and change without messing up its functions. So the first thing to do is run characterization tests, catalog, document and understand as much of its behavior as possible, before trying to change anything. As Erik Dietrich argued:
“Your goal isn’t to figure out what the system should do but rather what it actually does, hence the name characterization. You’re like a code anthropologist — just there to observe and categorize.”
Don’t kill the messenger
Or in this case, the programmer. There are numerous reasons why this legacy code you’re working on is as messy as it is. And trust me, none of these reasons is because the author of the code is an idiot.
As Brito argued in the same article, the most common reasons behind the enormous mess you see in front of you now are that the developer might have been inexperienced, tired or overworked; or maybe “the libraries that are mature and well-known today might have not even existed”.
For whatever reason, don’t be judgmental towards the author of the code or previous programmers that touched the code before you. Someday, there may be a young bright programmer that will judge the archaic and messy production code you wrote for one of your applications, so play nice!
It’s a blessing in disguise
Before you start yelling, let me explain. Behind all the drama and the struggle of dealing with legacy code, there is a slight ray of light and opportunity; and that is for you to become a better programmer! It may be boring, exhausting and, in a lot of cases, considered the dirtier of the works, however, it gives you the opportunity to learn from the mistakes of others.
Understand how someone else’s mind works and how he or she chose to deal with a certain issue and rejoice when you find the confidence in how much better you can make it!
And frankly, if you can’t avoid it, relax and enjoy it!