As developers, we all have to deal with ‘legacy’ code at some point in our careers.
I guess the definition of ‘legacy’ code varies from dev to dev. You will have some that claim that code becomes legacy code the minute it’s shipped. Others will claim that legacy code is older code that you inherit from prior devs…from a prior time.
Whatever it is, I can tell you that at least in my experience it’s not been the most pleasant endeavor.
When I started at my current gig a few years ago, one of my first major projects involved fixing and refactoring some parts of an old legacy application written in the early 2000s in Java. There was a series of subtle bugs happening in our production systems and I was asked to track them down and fix them. Of course, as is the case any time I touch any software, I wanted to make the code better, as we should all strive to do when we dig into a codebase that’s not our own and needs some tender loving care.
As the saying goes from boy scouts, always leave a campsite cleaner than how you found it. Same thing should go for anything else in life, including code.
Now, for this codebase that was a lot easier said than done. When I speak about this particular project as ‘legacy’, I mean that in every bad sense of the word. Built in the early 2000s, this project was the very definition of ‘spaghetti code’. I’m talking about methods that are hundreds of lines long and do a hundred different things. Badly named classes and packages along with bad package structure and design to begin with. Very tight coupling throughout and classes that have way too many responsibilities. Explicitly constructed threads, while using non-threadsafe objects. The list goes on…
When you’re staring in the face of such a daunting task, it’s tough to get a handle on where to begin, what to do, how to improve what you’ve got.
Here’s a list of a few things I did to get going with such a task and eventually get some of those subtle bugs fixed.
First, Don’t be afraid to play investigator
Make sure to ask around if it’s feasible. Try and identify what devs may have been around long enough to help with the code in question or better yet, worked on it at some point. Do this before you dive in full force because it could save you a lot of time if you find the right developer who can explain things clearly and/or put you on the right track to begin with.
Get a bird’s eye view of the codebase
First thing’s first, get the lay of the land. Start asking yourself questions about the project. Write the answers down if you need to, but what you are trying to do here is get as intuitive a feel as possible for this project. First and foremost, what does this application do? Does it have one clear purpose, or does it juggle many responsibilities? What are the entry and exit points of the application? What is the package structure? Does the application try to follow any special design patterns on a high level? Once you think you have good grasp of these questions, move on to the hard part.
Try to trace the application from beginning to end
This can be extremely difficult and time consuming. Of course it depends on the application and its size and scope, but for any project that is even moderately large, this step can be the hardest.
You may even want to pull out a good old-fashioned pen and paper. Basically, in the first step you should have identified the entry and exit points. Now, starting at the entry point, begin writing down where the app goes from there. As you get into doing this, you should quickly get a feel and know whether or not you’re dealing with a spaghetti-code monster like I was, or a well written masterpiece. I’d venture to guess it’s probably somewhere in between. If you find you have to start making multiple branches from each method during the trace, well then you’ve got some spaghetti-code on your hands my friend. Well written classes and methods should be loosely-coupled, modular, and have singular responsibilities. Many branches usually will mean many responsibilities and tight-coupling. You’ll soon be ensnared in a rabbit-hole…and the worse part is, each ‘branch’ during that trace could lead to more branches and so on. You get the picture.
Now fix what you need to fix
Once you’ve got the lay of the land and actually painstakingly traced the code and now have a good understanding of the ins and outs, making the changes you need to make should be relatively easy.
Just remember that whatever you need to do with this application, put your stamp on it and make it quality work. Of course that probably goes without saying but…. You may save some other poor soul down the line 🙂
Good luck and hit me up if you have any questions!
That’s it brothers and sisters, thanks for reading \,,/
Also published on Medium.