The Tension of Refactoring Legacy Code, Part 2

In the previous post on refactoring legacy code, I talked a bit about the challenges that we face not only as WordPress developers but as programmers in general as it relates to working with legacy code.

The short of it is that I believe we want to make sure the codebase is as optimized, clean, and well-organized as possible. But the reality of a project prevents us from doing this.

Perhaps it comes in the form of the team we’re on; perhaps it comes from deadlines that are looming, or perhaps it comes from something else.

Whatever the case, we’ve established that a tension exists. And though I’ve talked about some general ideas as to how to deal with it, I haven’t really talked about my own experience in doing so.

The Tension of Refactoring Legacy Code

When I first got into professional software development, I didn’t really think I was in a place to worry about refactoring code. That is, I was the new guy. I was the person who was working on the codebase who had the least amount of experience.

When you’re in that situation, I don’t think you question what you’re reading. Instead, you question your decision-making.

They made the decision to do it that way, so why am I deciding to do it this way?

Programming is weird, isn’t it? It can do a number on your self-confidence, ability, or drive to get better at what you’re doing.

Anyway, when you’re in an office there’s nothing stopping you from asking a person why they made the decisions that they did. And if you opt to do that, you’ll likely be surprised at some of the answers you get:

• “This was the quickest way to solve the problem.”
• “I was up against a deadline.”
• “I knew this is what would work.”
• “I didn’t have time to create a more elegant solution.”
• “I didn’t know any better.”

And there are a plethora of other options. But the thing that you learn is that although people who love and care about writing quality code don’t always have the opportunity to do things the way they’d like because they are constrained.

Perhaps they are constrained by their own ability at that moment in time, or perhaps they are limited by a deadline.

Whatever the case, it’s important to dismiss the notion that you’re doing something wrong because everyone else is better than you. Though some may be better than you sometimes (and that’s when there’s a great opportunity for learning), no one is better than you all the time.

With that said, what about my experience with revisiting my work in an existing WordPress project from years ago?

Case in Point

I was recently working on a project for a client and needed to introduce some similar functionality into the code that would add the functionality as requested.

Since code existed that I could have easily copy and pasted, I ended up created a more general method that took in an argument to identify what it was they needed to retrieve. The implementation of the function then reacted accordingly.

Specifically, it looking at the incoming code, adjusted the arguments for a query, and then returned a collection based on that. Another way this could have been refactored, depending on what you’re facing, would be to take the two similar functions, mark them as private then have the new public function call one or the other based on the incoming parameter.

That’s What We Do?

I know, the above example may sound a little bit too general to be helpful. Maybe not.

Either way, I know the tension that exists that comes with working with legacy code or even a slightly dated, pre-existing codebase.

The best advice I can offer is based the rule mentioned in yesterday’s post:

Just work to keep your area cleaner than when you first found it.

This is the second part in a three-part, series so I’ve a little more to say about the topic before completely wrapping up.

Hopefully, between talking about the state of legacy code, my own experience, and so on, it helps to spark some thoughts or conversation on what you can offer to the industry.