Posted on

Simply Refactoring WordPress-Based Code When it comes to refactoring WordPress-based code, what does that look like?

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?

Continue reading “Simply Refactoring WordPress-Based Code When it comes to refactoring WordPress-based code, what does that look like?“

Posted on

Release Early: A Case for a Strong 1.0 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.

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?

Continue reading “Release Early: A Case for a Strong 1.0 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.“

Posted on

Aim to Break Programs into Smaller Components It's helpful to break programs into smaller components so that it makes them easier to trace, to read, and to debug.

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?

Continue reading “Aim to Break Programs into Smaller Components It’s helpful to break programs into smaller components so that it makes them easier to trace, to read, and to debug.“

Posted on

A Simple Guide for Organizing WordPress-centric Classes Organizing code for WordPress-centric classes helps us to focus more on our domain in multiple ways.

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:

  1. the area responsible for generally solving the problem,
  2. 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.

Continue reading “A Simple Guide for Organizing WordPress-centric Classes Organizing code for WordPress-centric classes helps us to focus more on our domain in multiple ways.“

Posted on

Project Size and “Keeping It Simple” Depending on the size of the project, perhaps the degree to which we focus on keeping it simple matters.

For whatever reason, there is a consistent tension that exists (at least as far as I’m concerned) between the utility of building something for someone and the amount of time it takes to build the said thing.

By that, I mean that when it comes to WordPress, it’s relatively easy to build small, simple plugins and utilities for others that aren’t necessarily following whatever the modern best practices are.

And, as for this post, I’d say that the modern best practices are something like:

  • a server-side package manager,
  • a client-side package manager,
  • proper unit testing,
  • well-designed classes,
  • documented code,
  • and so on.

And all of that is great and arguably necessary for larger projects (especially because maintenance and consistent development are going to play such a significant role).

Continue reading “Project Size and “Keeping It Simple” Depending on the size of the project, perhaps the degree to which we focus on keeping it simple matters.“