Its generally not a preferred option to work with legacy codebase, but every now and then you do come across a codebase which hasn’t undergone a overhaul in long long long time. It is very common to lose all your calm on it.. get frustrated, and either do nothing about it or leave the job to do something else.
I had a recent encounter with such a codebase and below are some of my findings and recommendations about handling such a codebase.
Let me start with the definition of the codebase.
It had been written 2 years back and the software has been used since by 2000+ people. There have been multiple revisions of the product and all the changes have made the codebase fairly rigid and incomprehensible. It was supposedly written in hurry, so quality wasn’t taken care (typical of startups). Since then it has not been re-written or even cleaned up.
Long.. huge all powerful classes and methods. No object-orientation whatsoever. All static methods. Algorithms and logic written so beautifully that even the author finds difficult to navigate through them. Messed up assignments and states. It was at times a game to guess what a particular variable would contain after few iterations of the code.
Ok, you get the picture, right?
It is very easy to start criticizing the people who wrote it and make all noise. But, have a look at the good part.
The software has been running pretty successfully for last couple of years. Been used by thousands of people. Been earning money for the organization. Its not all that bad, isn’t it?
So, first step to tackle such codebase is to treat it with respect.
Not easy when you’re supposed to add functionality on top of it. But, appreciate the fact that the product has been useful for a longer period of time. Many software products never get to see the light of the day. Beautifully written, wonderfully functional, but never released. It is much better to release a product and iterate on it than never release at all.
Having said that, lets see some of the ways to tackle that code (in no particular order).
1. Don’t be afraid to change.
It is difficult, but not impossible. Leave the tendency to not touch the existing functions. The sooner you get comfortable with the code, the better chances you have of adding features on top of it.
2. Try to divide the codebase into smaller classes and methods.
Be methodical about it. Make small changes and test frequently. But nothing beats this approach. Separate a big class into multiple smaller ones. Long methods can be broken into more meaningful smaller methods. This will automatically give you a picture of what is going on within the code.
3. Change the names.
Work with the team to change the names to more appropriate ones as and when possible. You’re not only making it easy to understand the code, but, also making yourself comfortable with changing the code, without touching the solution much.
4. Write tests around existing code.
At times it gets difficult. But with some discipline and patience, you can write tests around existing code. It helps a great deal to understand the code and improves your confidence in changing it at a later stage.
5. Understand and manage dependencies.
Try and separate different areas of the code and manage the dependencies between them.
These are few strategies to approach a large legacy codebase. Please share if you’ve come across similar situations and how you handled them.