How many times have you looked at someone’s code and stated:
I’m not using this because it doesn’t look well-written.
And in this case, “look well-written” might either be a substitute for:
“look like how I would write it,”
“seem to make sense to me.”
Sure – there are times where using open source code is risky. We know this from the various software and services that show up with vulnerabilities. But, at least for this post, treat those as the exception – not the rule.
This means we’re left with looking at something we may use but opt not to use because it doesn’t seem to be written in a way that we think it should be written.
In my experience, the way we first interact with the repository design pattern often influences how we think about the pattern. (The whole first impressions are lasting impressions, right?)
The purpose of this post is to show how it can be implemented in WordPress specifically when writing object-oriented plugins to read data (writing data may be covered in another post), but before doing that I tried to think of a few consistencies among the variations of the pattern that I’ve seen.
Generally speaking, this is what I think a repository pattern should do:
provide a single place to read data,
abstract the details of how the data is accessed,
and have a consistent interface for doing so.
This means that whatever it is you need to retrieve from the application can be retrieved from the database. But how its retrieved can be considered a black box. That’s up to the developer implementing the pattern.
And in the case for those who read this post, that’s most likely us.
Back in 2011, I was doing a lot of reading on working with legacy code, code quality, and refactoring.
There’s a quote by Martin Fowler (who literally wrote the book on refactoring) attributed to Uncle Bob that’s stuck with me – and I’m sure many, many programmers – ever since:
always leave the code behind in a better state than you found it
The thing about this particular idea is that I think it might sound a bit more idealistic until you really start to try to practice it in everything that you do.
That is, if you take it at face value it sounds like anytime you need to work on a codebase, then you need to leave the entire codebase better than when you found it. But the more I’ve tried to apply this rule in my day-to-day work, the more practical, the cleaner, and the more maintainable WordPress-specific code has become.
So when it comes to refactoring WordPress-based code, what does that look like?
I am not a fan of the “move fast and break things” mantra that Facebook used to hold and I don’t think there’s a reason to have to justify my opinion on that. I’m glad they’ve sense moved away from it (or appear to have – I don’t know what they do internally).
I am, however, a fan of the “Release Early” idea. Sometimes this is also coupled with “Release Often” so we get the near-infamous “Release Early, Release Often” phrase in the software development nomenclature.
I don’t necessarily think they have to go together.
But when it comes to the idea of “Release Early,” it seems that no matter what you release, if it’s not up to a customer’s expectation, then it’s no good.
And I get it. At least from that perspective.
But what if you’re a fellow software developer and have some insight on to how this kind of stuff works?
One of the things that programmers often talk about is the desire to break programs into smaller components, or functions, so that it makes them easier to trace, easier to read, and easier to debug.
But it’s not all that uncommon to see monolithic functions with a lot of code comments to help explain what’s going on in the program.
I’m not knocking this, really, because I don’t know the constraints under which a programmer was working. That is:
What was the budget s/he had when building the program?
How much time was given to complete the project?
Were there many people working on the project?
Was the programmer given time to write the code so they could unit test it, refactor it, or merely make it easier to read?
In short, there’s a lot of reason – I believe – that we can read “bad code,” and it doesn’t always have to be the fault of the programmer (that’s just the most natural thing we have to throw out when we read something we dislike).
Does this mean, though, that we shouldn’t strive to refactor or write code in such a way that makes it easier to understand? Of course not. Assuming we have the time to do so, how might we do it?
