Refactoring Code When You’re Trying To Update A Legacy System

You already know you’re in for some crazy code when you inherit a legacy system, especially one that is using a language or library that is outdated. So what do you do when you’ve been asked to both refactor that legacy system and implement new functionality in it? That’s not an unrealistic situation for some web developers. There are plenty of AngularJS applications out there waiting to be switched over to a more modern framework.

When you get into the details of it all, it gets more complicated. You might be moving to a different way of model binding, your data is going to be handled differently, and the new library or language might not let you keep your current architecture in place. Balancing the legacy updates and the new code base takes time and a good strategy. Here are a few tips you can use to make this process easier and more efficient.

Break it down component by component

When you take the time to recreate each component in the new language, you’re giving yourself time to work on refactoring and implementing new features and bug fixes. You have to go through and touch each component in the legacy system to make sure your new system has everything users are familiar with. Even in a system with hundreds of components, it pays to take the time to go through each one because you find ways to optimize the new application.

Refactoring an entire code base while implementing new stuff in the existing code is going to take time. Don’t feel bad if you’re moving “slow” because you are doing things the right way.

Go up to the directory level

When you have to go in and fix bugs in the legacy application, that’s a good time for you to do a directory level check. If there are certain parts of the legacy app you keep hitting for your updates then spend some extra time on refactoring those parts. Looking at a directory as a whole helps you keep your new components in context as you maintain the old ones. It’s also another way you can find places to improve the refactored version of the application.

Figure out your priorities

So in a way you have to update an app that you haven’t finished building. That’s why you as a developer have to know when and where to draw the line. You only have so much time to work on your tasks which means management needs to clearly define what your priorities are and why. Once you have your main priorities set, don’t deviate from them. It’s easy to get in a situation like this and start to flip back and forth between the two systems. That makes it harder for you to focus on a particular library or language and slows you down.

Check the business logic as you go

The business logic is arguably the most important part of a system because it sets the rules for how the system should behave with users. This is important regardless of whether you’re changing up the front-end or back-end. As changes were made to the legacy system over time, the business logic might have gotten fuzzy. Don’t transfer that ambiguity to the new system. Part of a good refactoring is making a new code base that cleans up some of the issues with the old and that’s especially true when it comes to business logic.

Focus on writing the new code well

This is your chance to include all the tests and logging you ever wanted. You can keep the number of dependencies down and work on performance issues you noticed in the old app. Keep this same focus in the legacy app as well. Until you get an official deprecation date and it’s been announced to more than just the engineering group, assume that you will be maintaining the legacy app for the foreseeable future. That means you need to keep that code base as clean as possible so don’t let sloppy code sneak in just because the refactoring efforts have started.

Hands down, this is one of the tougher situations to handle as a developer. Being expected to do regular bug fixes and new feature implementation on an app you are refactoring is frustrating because you know you are doing double the work. It’s one of those weird things that comes with the industry. 🤷🏾‍♀️ Hopefully these tips help make the process a little easier. I’ve been in the refactoring pit with MVC and front-end frameworks and let’s just say it’s not a good idea to stick JavaScript where Razor templates should be.

What’s something else you do when you have to refactor a code base? Do you handle the process differently depending on if it’s a front-end or back-end refactor? Sometimes I’ll refactor my side projects just to compare different languages or frameworks. It’s a useful skill to have because it helps you form opinions about how different libraries implement the same features. Plus it’s another way to practice coding!

Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding

Starting classes soon! | Software/Hardware Engineer | International tech speaker | Random inventor and slightly mad scientist with extra sauce