I know what you’re thinking “double the amount of code?! Who is this nutjob.” And “you’re the reason a clock app takes 20MB.”
But, let's get one thing straight.
Lines of code have never been a good metric for code quality. Ever.
Lots of developers want to skill up and abandon their old ways. Expanding your repertoire of approaches and techniques to eliminate branching is one quick way to do so. Often, your code also becomes cleaner in the process.
Crazy code like the above example needs to go. It’s not readable. It’s not maintainable or flexible. It’s just terrible…
Back when I started programming I ran across concepts and terms I really didn’t understand, like middleware, inversion of control vs dependency injection, traditional branching, service classes, business logic, status codes, and many more.
I’d often interrupt my flow to spend time chasing down the meaning of these — and, maybe that’s exactly why you are here right now.
So here I am trying to make life a tiny bit easier for you junior developers, by attempting to explain, or at least somewhat clarify the meaning behind these terms.
Okay, let’s get into it.
Traditional branching negatively impacts your code…
“Don’t use that construct (syntax, approach, pattern, or whatever), juniors won’t understand it!”
This makes perfect sense from a management point of view since we can get away with hiring less experienced people.
Continuously dumbing down code only makes sure your junior developers stay dumb.
Dumbing down your code to the point where it requires less language-specific knowledge to understand, or, simply overall lower coding literacy is, in my opinion, terrible advice.
Give the same task to a junior, mid-level, and senior developer and you’ll (obviously) receive wildly different solutions.
I think there are some common traits to the code…
But we should’ve known it wouldn’t work out as expected.
There were a bunch of telltale signs along the way… The general lack of standard practices. The genericness of it all. Focusing on following arbitrary, synthetic rules rather than building business-specific APIs.
And then we have perhaps the most conspicuous sign REST wouldn’t work in a modern DDD-driven application:
Applying a document-oriented paradigm to the complex reality of business domains doesn’t work (well) in practice.
Many web developers default to implementing REST APIs in a CRUD-like manner. They’re too focused on sticking with arbitrary, made-up technical rules, losing all sight of the business and its clients.
CRUD over REST might be great for beginner developers and creating PoCs because it’s easy to get started, and you can largely ignore aspects of your business domain.
Alright… so let me state this right off the bat; I (mostly) don’t have an issue with REST.
There’s a general issue with how developers default to creating CRUD-based REST APIs. For some reason, developers have converged on the idea every…
I’ve applied many different programming styles, practices, and approaches to write more readable code throughout the years.
Some initially seemed great but turned out not to be. Others got outdated, and then there are the few practices that I’m still using.
I’ll just enumerate a list of those that have stuck with me and which, in my opinion, works well.
You do need documentation comments, but most comments are completely unnecessary.
There are many different “kinds” of comments that only increase the noise-to-signal ratio.
Here are some of those typical code comments that you might as well just delete on…
I heard about CRUD back when I started learning programming and web development. It was pretty much the approach to use. I’d be spending time thinking about entities as ‘resources’ and how to write awesome CRUD-based applications, where each resource was either created, read, updated, or deleted, and only that. Essentially what’s best described as ‘CRUD-thinking.’
Create, read, update, delete. Simple enough — and that’s exactly the problem.
When did you last think about your domain solely in terms of storage management?
But I can see why beginners like this approach. The CRUD idea translates well into existing programming concepts…
There comes a point when unit tests and mocking just won’t cut it.
Writing unit tests with a mocked database may be great when you want to verify that a piece of code runs correctly, given some expected input.
Using an in-memory provider is the natural next step. But while an in-memory provider is useful, it’s only a hollow shell compared to the real thing. For example, queries that succeed when testing with an in-memory database may fail hard when executed on the real database.
In-memory databases provide you with a false sense of confidence.
You’ll eventually need to be…
I often take jabs at curly braces app coders with no appreciation for reducing complexity, thinking any problem — without side-effects — is solved by piling onto already incomprehensible
But, I never really got around to explaining my underlying reasoning and guiding principles — besides that, traditional branching is equivalent to hardcoding and looks nasty.
Sidebar: I want to keep this practical. I won’t go all academic on you. I’ve provided links at the end if you’re more interested.
If easily comprehensible, extensible, maintainable, and working code is the pinnacle of software development, then why do…
Code often gives rise to “WTF”-moments whenever the reader doesn’t understand a piece of code’s purpose, goal, or the code is overly verbose.
I think you know exactly what I’m talking about.
Reading code, understanding the syntax, patterns applied, etc., is no issue. But, you still wonder, “wtf” is going on here? Why did he write it that way? What’s that conditional checking, and why? The list of questions goes on.
Clean code is all about communicating your intent as clearly as possible.
Sometimes that means writing more code and other times less code. But, most importantly, your code should…