The last two posts have talked specifically about what it’s like to work specifically on refactoring legacy code whether it be something that we’ve previously worked on or something that we’ve inherited from someone else.

  • In the first post, I talked about the idea of “leaving the campground cleaner than you found it” which is the Boy Scout rule applied to programming.
  • In the second post, I talked about getting a bit reflective about the choices we’ve made as it relates to some of the code we encounter in our work and how it can affect our self-confidence or our ability.

And though I think there’s more than can be said as it relates to this topic (I mean, it has the potential to be a very long discussion, doesn’t it?). I want to shift gears a little bit and talk about what it’s like to try to more modern code on top of what’s essentially a legacy application.

Specifically, I want to share a few thoughts on what it means to write code (that will likely need refactoring at some point) on top of WordPress.

Note: This post ended up being much longer than I anticipated, but I hope you read it in its entirety, enjoy it, and feel free to comment on it, as well.

Refactoring Legacy Code: On Modern Code

What is modern code, anyway? I’m hesitant to use that phrase even because I’m not sure I even like it. It feels as if it’s become a bit of a buzzword in the industry.

That is, developers and the like will often use “modern” to describe some framework, library, set of tools or approach that hasn’t been around all that long.

And don’t get me wrong, that isn’t necessarily a bad thing. But here’s one of the questions that I always have about anything that’s modern.

If “modern” refers to something that’s new, how do we know it will be around for a long time when it’s yet to stand the test of time?

That is, we know certain paradigms such as object-oriented programming and certain design patterns aren’t going to go anywhere. They’ve stood the test of time. They aren’t modern, but they are tried and true. And though we still may be exploring what all we can do with them, the fundamentals aren’t going to change.

But can the same be said about some of the things that we’re working on today? Case in point, I saw this from Sam Stephenson on Twitter yesterday, and it struck a chord with me:

Which one of these would involve refactoring legacy code? And which would be easier?

This is what “modern” has brought us (at least on the front-end).

I’m say saying that it’s necessarily wrong, but I do call into question the complexities that we’ve introduced for the sake of making more modern frameworks and methodologies for building applications.

And before moving forward, I want to share the following:

It does still apply. And there’s something a bit freeing about that, isn’t there?

I’ll come back to this point in a bit.

The Legacy That Is WordPress

One of the things that I think anyone working within the WordPress economy should accept is that WordPress is a legacy application. Though there are some things that can be used to support this, I believe it can be defended and proven by its commitment to backward compatibility.

This is modern, right? Though not exactly what I mean.

This is modern, right? Though not exactly what I mean.

For whatever reason you may have (and there are plenty), people dislike calling WordPress a legacy application. Perhaps this is because it feels old, it feels outdated, it doesn’t feel as fresh as some of what the peers in our industry are working on, and so on.

Whatever the case, some people get defensive about working with a legacy application.

To a degree, I understand: We don’t want to be the type of programmers who are stuck working with something that’s decades old when there are far newer technologies to be learning.

And on one hand, I get it. Our generation doesn’t want to be the next generation of, say, COBOL programmers (no offense to the COBOL programmer who is reading this :). But the thing is that the languages on which WordPress is built are moving forward.

  • There are new versions of PHP.
  • Advancements are being made with JavaScript.
  • Though the future is uncertain, this is an API that’s going to free us from the dashboard of WordPress should we so choose.

I know, I know (but there are solutions!):

  • The features of PHP we can use are limited by the hosts available. So choose modern hosts.
  • JavaScript is only going to be as supported as the browsers that implement the new features. Luckily, the adopting rate of new features in the browser is pretty high.
  • If you want to use the REST API, then install the plugin and use it. Don’t worry too much about the core merge or not, for now.

No, this does not magically solve all of our problems. There are always going to be points about which we can complain, so the discussions that we often have oriented about the complaints that we have with WordPress can be just as fruitless as they can be fruitful.

It’s all in how they are framed.

And clearly, I love WordPress. I earn my living with it. Obviously, I’m on its side. But in the past few years, I’ve set some boundaries for myself for how I want to manage this particular tension.

Working with Legacy Code

Though the whole idea of the past three posts has been around working with legacy code, I thought it might be worth sharing how I approach building things both for our plugins and for our clients as it relates to working with legacy code.

First, the general rules that we follow are:

  • Adherence to the WordPress Coding Standards. Always.
  • An attempt to adhere to the SOLID principles as deadlines allow.
  • Unit Testing, as deadlines allow.
  • Organizing code in a modular way (with views, business logic, and classes binding hook registration to WordPress).
  • Use the existing APIs.
  • Composer for package management, as needed.

I don’t worry much about the state of WordPress, the quality of the code that exists in the core of the application, nor do I worry much about what’s coming in the future version of WordPress.

Some of the WordPress source code.

Some of the WordPress source code.

Regarding that last sentence, what I mean is that I care about new features and APIs and things that may be useful. But when it comes to things like The Customizer and the never-ending debate that exists around that, it doesn’t impact what I opt to do one way or the other (at least right now) so I don’t have an opinion on it here or there.

It’s not for me to sort out.

Secondly, and at a more general level, I’ve gotten to where I treat WordPress more of a black-box than anything else. That is, it’s a foundation on which solutions are built for others.

It’s important to know the APIs, the coding standards, and the aforementioned points, but regarding how it processes, information that’s handed to it from an API call is then the responsibility of the core application.

It’s my job to make sure the data is in the best possible state that it can be in before handing it to WordPress. Anything less than this would be irresponsible (and arguably lazy).

This is still predicated on the idea that I’m staying up-to-date with the state of the APIs, what’s new, what’s deprecated, and all that jazz. But assuming that’s being done, I’m primarily focused on the design, architecture, and organization of the code over which I have control.

That’s Refactoring Legacy Code?

What I’ve written here really has nothing do with refactoring legacy code, but it does have to do with how I work with building my solutions on top of the legacy code.

And to be fair, not all of WordPress is legacy. That is, there are a lot of new parts and newer technologies being used. But it also has a strong focus on compatibility with prior versions of PHP and so on.

Depending on how much control of the environment you have that this runs dictates much of what you can do.

Finally, depending on how complex you want to make your application (as shared in the diagram above) is up to you. But I can say that after years of doing this, it’s a lot of fun to mess around with new architectures, libraries, tools, and more “modern frameworks” to handle the complexities that we’ve introduced

But after a certain point, it becomes exhausting. This isn’t an excuse to write it off or not be familiar with what’s going on, but it’s a reminder than sticking with the basics can be freeing.

Because when it comes to providing value for our customers and clients, they don’t care how complex we’ve had to wrangle the browser and its components into submission. They care that their solution works.

And I’d argue that we care how easy it is to manage over time. And that trumps whatever is “cool” for a given moment in time.