Refactor regularly to delay legacy
Nishanth KD
February 1, 2018

Have you ever gone over an application codebase and felt that it should be refactored because it’s poorly written and just doesn’t make any sense? However doing so feels like an enormous task? Read on to make sure your application doesn’t end up like that, Legacy.

Lately, I’ve been consulting someone on a legacy application. The app has built a reputation for being slow, buggy and poorly architected and it is costing the business a lot of money to maintain the application. Needless to say, my clients don’t think very highly of the dev team that built it.

I was going through the codebase today and found something intriguing, a method that does nothing but is used everywhere.

The method had been called in almost 70 odd locations in the codebase.

What went wrong?

Why would someone create a method for this? I checked the history of the file to find out how it looked when the method was created. This is how it was.

The method was created keeping in mind a specific functionality. With time the functionality changed and someone was given the responsibility of modifying it in the codebase. Ideally, the method definition should’ve been removed and the call replaced by assignment.

Why not the right way?

Applications, or rather anything in this world does not go bad all of a sudden in one day. It’s always one day, one act at a time. I find the broken window theory to explain this phenomenon the best. The developer, in this case, also took the route of “Make it work today. I’ll clean it later”.

 

“Make it work today. I’ll clean it later”

 

Such an attitude, always leads to problems piling on and these problems further invite bigger problems.

There are a lot of ways to tackle such problems in software. However, in my opinion, awareness of this human psyche can be a small step in the larger picture. It would lead to not only code corrections but also life corrections.

 

“Refactoring code is not a one-time activity,

it’s an ongoing process.”