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.

Deadlines can prevent us from refactoring legacy code.

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.

Time is but one of the constraints we have when refactoring legacy code.

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.

4 Replies to “The Tension of Refactoring Legacy Code, Part 2”

  1. This whole aspect of refactoring code is just another reminder of the “design” in software design. Design is about decisions and tradeoffs. There’s also a temporality to it as well.

    The design decisions of the past were taken with the constraints, known facts and technical ability (just to name a few factors) of that time. Odds are that these aren’t the same today. Things change. :)

    Your discussion also reminded me of an article discussing new developers and their need to change/critique the work of past developers. There are a few parallels with what you talked about here. You can find it here:

    https://medium.com/things-developers-care-about/why-your-previous-developer-was-terrible-506a06ae35ea

    1. The design decisions of the past were taken with the constraints, known facts and technical ability (just to name a few factors) of that time. Odds are that these aren’t the same today. Things change. :)

      This is a good point.

      On the converse side of it, sometimes I think younger developers who have some type of certification or who are simply just more “green” have a level of confidence in terms of how something should be and when something doesn’t align with how they think it should be, they write it off as bad.

      But constraints – both technical, temporal, and financial – dictate a lot more than a project, a test, or something similar.

      There are a few parallels with what you talked about here.

      I’m throwing this article in Pocket to read soon. I’m eager to see what it has to say.

  2. “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.”

    It could also be that in the past the “team” was just the original developer with a deadline as you said. If there are now 5 people using the API then you almost have to go the private/public route to avoid code breakage. Sometimes the scope/budget/future, whatever you want to call it, does not warrant implementing everything you know.

    I think “Just work to keep your area cleaner than when you first found it.” is real solid advice.

    1. It could also be that in the past the “team” was just the original developer with a deadline as you said. If there are now 5 people using the API then you almost have to go the private/public route to avoid code breakage.

      This is true. Though the ideal situation would almost always call for some type of refactoring in order to handle this kind of stuff, constraints often prevent us from doing what we’d like.

      That’s one thing about development that’s a frequent frustration but this isn’t the place for me to air those grievances ;).

      But you basically nailed it too in this:

      Sometimes the scope/budget/future, whatever you want to call it, does not warrant implementing everything you know.

      Oh — and yeah, I dig on the Boy Scout rule, too :).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.