Tag: Software Development (Page 6 of 20)

A General Example of the Repository Pattern in WordPress

April 9, 2019 / Tom

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.

Simply Refactoring WordPress-Based Code

November 20, 2018 / Tom

Back in 2011, I was doing a lot of reading on working with legacy code, code quality, and refactoring.

Refactoring WordPress-Based Code

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?

Release Early: A Case for a Strong 1.0

November 15, 2018 / Tom

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?

Aim to Break Programs into Smaller Components

September 5, 2018 / Tom

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.

Breaking Things Into Smaller Components: Monoliths

A monolith ala 2001: A Space Odyssey.

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?

A Simple Guide for Organizing WordPress-centric Classes

August 9, 2018 / Tom

One of the things that I’ve been making a much more concerted effort, likely more so than I’ve ever done before, is managing separation of concerns between the classes responsible for interfacing with WordPress and those responsible for working with the problem domain.

For instance, let’s say that you’re working on a plugin and it’s going to communicate with a third-party API. Additionally, this plugin will also offer menus, post types, taxonomies, and so on within the WordPress administration area.

There are two areas of responsibility here:

the area responsible for generally solving the problem,
the area responsible for interfacing with WordPress.

You can make the case that it’s important to unit test areas that communicate with WordPress, but I also know these are tried and true APIs that have their own set of tests.

Instead, we should be focusing on unit testing and separating our business logic away from WordPress.

But that’s not the point of this post. Instead, it’s more about a way to potentially lay out a project when a portion of it will be interfacing with WordPress.