What is this?
I’ve been programming for a few decades. In this time, I’ve found that some coding techniques have a dramatic impact on code quality. They often feel like coin flips. “I could do it this one way. Or maybe this other way. It doesn’t seem to matter.” But later you compare two files and ask yourself, “Why is this one so difficult to edit, and why is this other one easier?” It’s often because small differences in techniques have large consequences that aren’t obvious.
So I decided to document these techniques. Some of them are common techniques that are commonplace. Others are opinions of mine.
Posts in the series
Inject dependencies when possible
Dependency injection is a simple technique that has dramatic implications on code maintainability. It means that logic should be passed its dependencies instead of instantiating or accessing them itself. The post contains examples and explains the tradeoffs.
Tests written using automatic mocking frameworks are often fragile compared to those written with real dependencies or test fakes. But it’s not always practical to use anything but a mock. Here, I discuss the tradeoffs and explain why the alternatives are preferred, and why they cannot always be used.
Use plugin architectures to improve encapsulation
Often, the same set of conditions get checked in a bunch of places in the same codebase. By refactoring these into a plugin, the concepts behind the logic differences become a first-class citizen, which makes it less error prone to grow your programs over time.