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).
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?
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.
The Tension of Refactoring Legacy Code, Part 1 was written by Tom. For more information about WordPress, development, and resources then visit Tom McFarlin’s blog.
Read more here:: The Tension of Refactoring Legacy Code, Part 1