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).
Keeping It Simple
But what about smaller projects where you’re more or less the sole steward of the codebase? I’m not saying that good practices shouldn’t be put in place. I think we should:
- have a well-documented code base,
- function or class design that caters to future development,
- and optimization of both client-side and server-side code
But does that mean that these projects need to have large vendor directories or large node_modules directories?
Succinctly put, I don’t think so. I think that gets into over-engineering.
Make things as simple as possible, but not simpler.
This doesn’t mean we forgo the care necessary for writing quality code within the context of our IDE.
But perhaps that’s where it stops. That is to say that maybe a good rule of thumb is:
- If the project is going to require continuous integration, then it should have the necessary guardrails to enforce the quality both locally and in the staging environments and the continuous integration process.
- If the project is going to be built and then released (and iteratively done so), then the majority of the quality should be measured and enforced via the IDE.
I don’t know if this is the best way to approach it, but it’s something I’ve been spending time thinking about and continue to arrive at the set above of proverbial barriers.