In a post last week, I talked about various problem spaces that exist in WordPress, but I also briefly touched on the idea of practical applications as it relates to writing WordPress-specific solutions.

Specifically, I made the comment (more or less in passing):

When I was in school, I had to take a class in Computational Theory. For the most part, I’m more of a fan of practical application, but I know that much of said practical applications are the concrete implementations of proven theories.

And then I went on to talk about more theoretical topics as it relates to solving problems in a given computing space (for us, that’d be WordPress).

Computational Theory

Since I spoke about the previous topic at this particular level, I thought it might be fun talk about a more accurate or more practical approach to writing WordPress-specific software.

Recently, I’ve been working on a codebase that’s a few years old. The desire to want to refactor the whole codebase is strong (and I know I’m not alone in feeling this way when it comes to working with previous projects).

But this is not pragmatic, and it’s not so for some different reasons. So over the next three posts, I thought I’d share a little bit about the state of the project, managing the tension that exists, and how to do what we can when we’re faced with this type of situation.

Refactoring Legacy Code: The Tension

When it comes to working with a project that’s a few months (let alone years) old, we often find ourselves faced with some different things that we immediately want to change.

Sometimes this is a byproduct of the experience we’ve gained thus far; other times, it’s the nature of working with a codebase that was built by someone else who wasn’t necessarily as experienced as we are.

If you’re working specifically with WordPress (and PHP), then there are likely going to be things related to:

  • The WordPress Coding Standards
  • Which version of PHP was used and, thus, which features were used, or weren’t used
  • How business logic was kept separate from the view logic and so on
  • How, if any, unit tests were defined
  • And so on

Obviously, these are just a few of the things that we may stumble across. And though we’d love to refactor, improve, and bring the entire project up to a particular standard, it’s rarely the case that we have the ability to do so.

The Tension That Exists

And that’s where the tension exists: We have knowledge and ability to improve the quality of a project for which we’ve been commissioned to build, but we don’t have the time nor the budget actually to make said changes.

We have knowledge and ability to improve the quality of a project for which we’ve been commissioned to build, but we don’t have the time nor the budget actually to make said changes.

So what are we to do? Over the years, I’ve had a chance to experiment with different ways of handling this, but the primary thing I keep coming back to is quite simple, and it’s something that’s a famous adage within the programming community.

Always leave the campground cleaner than you found it.

It sounds a bit simple, I know, and it’s easy to argue that it’s difficult to find the line on where to draw this. After all, if we inherit a codebase – that is, the campground – shouldn’t we leave it better than we found it?

Refactoring Legacy Code

In theory, yes. But when you’re working on a project, how often do you touch the entire codebase? That is, how many times do you work on every single file that exists in the codebase?

I’d venture to say rarely.

In fact, I think that many of us who inherit these codebases end up working on a small slice of it. Thus, we’re primarily working on a collection of modules that we’re adding functionality to, remove functionality from, and potentially extended.

And in those cases, I think it’s a great move to spend some extra time cleaning up some of the code while we’re there.

What Should We Do?

This raises the question of how we deal with said tension. And in the next post (in this series of three posts) I’m going to take a look at a practical example of doing exactly that.

In the meantime, feel free to chime in with your experiences, questions, or comments and I’ll see about answers them in the feed below or one of the future posts.

Category:
Articles
Tags:
,

Join the conversation! 2 Comments

  1. Never heard of the “Boy scout rule”. It’s such a great philosophy! I’ll have to start promoting it a bit. ;)

    As a side note, I don’t see how you could refactor legacy code without applying something like this. Outside, the complete rewrite scenario which isn’t always possible. You have to just make it a bit better in the areas that you’re working on.

    That’s also the common strategy when trying to add testing a legacy codebase. You can’t add tests everywhere. You just start somewhere. Fix a bug? Make a test for it. Baby steps :)

    • Never heard of the “Boy scout rule”. It’s such a great philosophy! I’ll have to start promoting it a bit. ;)

      I’d heard it befoe somewhere years ago but couldn’t remember the name of it so I basically had to look it up by definition.

      Outside, the complete rewrite scenario which isn’t always possible.

      Yeah, I generally don’t even think a rewrite is possible. I always think about slowly updating a program through the use of adapters and facades (unless you have some type of funding to help cover a brand new version starting from the ground up).

      You just start somewhere. Fix a bug? Make a test for it. Baby steps :)

      Exactly. The industry gets so caught up in having as much test coverage as possible that we forget that starting with just a small percentage can be a really big deal given the right app.

Leave a Reply

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