Seven ways to make legacy code your friend

This is a simple guide on navigating the jungle. The code jungle. You need to come with the right gear. The right attire and be ready to begin hacking yourself through till you can see the light. It will be hard, your strengths and weakness will be tested but once your are through; many will be able to follow your path. Where there was only tress and plants a clear path emerges one that thousands will follow.

All jokes aside. Lets look at seven things that can help you with legacy code.

Don’t try to understand it all at once.

Photo by Matt Bero on Unsplash

I know! This seems like an obvious one but let me mention it still. You are not going to understand the entire application at once time. Even if its a small application. Be sure to take your time and to give yourself ample time to understand the applications’ in and outs. Legacy code or code on a whole tends to have a personality of its own based on its creator or creators. There maybe quirks that you don’t readily see. Take it function by function. Class by class. Line by line. After, you can join it all together as a whole and it will make sense to you.

This is a lot easier to do than you thing and will get you far better results than you could imagine. Learn to do it properly and you could reverse engineer code with ease. You wouldn’t need to know what it was supposed to do before you understand it. Baby steps though. You’ll get there.

Make small changes and observe

Photo by Michael Longmire on Unsplash

I actually have two more headers. Run Test Frequently and Make Your Own Tests.

How can I explain this section. (that’s a joke).

Make small changes just to see how it affects the application. If there are tests run them or make your own test if necessary. All of this is to get you a feel for the system that you are working with. It will also help keep in your mind the flow of the application and it will bridge the gap between the user interface and the code base if applicable. Regardless of what the code supposed to do, you really only know how your application works when you run it so make sure to run it as many times as possible. So you don’t miss anything important.

Mimic parts of the application using the code provided

Photo by Fatih Kılıç on Unsplash

If applicable of course one thing that really helps is building over the application outside of the application. Create mini applications from the code base and play with the code to see the different results that you can produce. This helps you to get familiar with the style of coding you are working with and the results that are being produced. It will even help you to see where you can improve – in the future of course – one thing at a time.

Another reason why this is helpful is because often the code can be quite intertwined with the entire application and you might have problems tracking all the side effects of a certain action. To totally remove the code gives you certainty about how it will operate so you don’t have to worry about hidden side effects.

Use Pen and paper and a printer

Photo by Aaron Burden on Unsplash

Don’t be afraid to go old fashion. Print out sections of the code. Get it off the screen so you can review it clearly. Align different sections together and manually track them with pen and paper or cool color tags. This could be really helpful to some people. (Like me).

You don’t have to do this though. If you’re too advance to use such techniques. Use your IDE and bookmarks, use split screen and split screens and compare features to give you an upper hand if old school is to old for you. For some the process of seeing it on paper and comparing can reinforce memory recall and overall understanding.

Get a high level explanation of how the application should operate

Photo by Ross Parmly on Unsplash

Event if the application doesn’t operate as it should you still want to find out what was the intention when the application was begin built.

Find out what the application is supposed to do. Not how it actually works. Often there is a difference between the two and you want to keep that in mind. It might explain some weird things you find when going through the code base. Maybe some code code that doesn’t seem to be used, a hard coded feature or function. Anything that says we are going a different way than expected will help in giving you a better understanding.

Pay attention to any comments but don’t take them to seriously

Photo by Christian Wiediger on Unsplash

Comments can give you insight into the developers mind and how they were thinking when building the application. Take note but don’t take them too seriously. Things might change over time so you will still need to understand the application on your own. A comment might hold true or not but don’t right them off as old news. They can help you in ways you might not understand at first.

Don’t fix errors until you understand the system

Photo by Aaron Huber on Unsplash

Until your have a handle of the system you shouldn’t try to fix major errors. They key here is major errors. You can make small changes and your can always revert the code base but if you don’t understand what you are doing you risk creating more problems than solving. This is very easy to happen. This point isn’t without the obvious factors. That you should have a test environment, source control, tests, staging environment and maybe peer code review. Even with all these safe guards in place you still want to make your changes small until you understand the scope of the system. Just like when you start working on a code base in a company you just entered you don’t make major changes at first, the same principle applies. Start small and build your way up until you understand what you are working with fully.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s