In case you haven’t seen it, I’ve been diving ever-further down the code research rabbit hole. Today it brings me to the Autofac codebase (found here). But to understand how I’ve arrived here, consider some of the questions that I’ve answered previously.
With each of these studies (and the rest of the series), the research has become more sophisticated. This is because I’ve started working with folks that have a data science and machine learning background. So I’m now having fun assembling measurable codebase properties into broad categories and seeing how my corpus of 500+ open source codebase resolves into patterns.
And that brings me to Autofac.
It caught my eye by ranking in the 85th percentile for what I’m calling “testable” codebases and in the 58th for “readability.” And in general, it scores decently to well in just about every measure. This gave me an idea for a post in the same sort of vein as the one I did about Moq. Let’s do a deep dive into Autofac’s codebase using NDepend.
Continue reading Autofac: A Detailed Look Under the Hood at Its Code Quality
In the spirit of the Agile Manifesto, we’ve reduced our dependence on software documentation. In some ways, this has improved our lives. And in other ways, it’s been taken too far and had the opposite effect.
The manifesto values “working software over comprehensive documentation,” which isn’t to say that documentation isn’t necessary. All too often, the baby is thrown out with the bathwater, and teams produce little to no documentation at all—including the software architecture document.
So which bits of documentation should we throw out and which should we still deliver? Indeed, we should prioritize those deliverables like any other user story. Some organizations will place a higher value on certain documents than others. Nearly all should put more priority on creating a software architecture document. Here’s why…
Continue reading Software Architecture Document? You Don’t Need That
Design patterns seem to be a controversial topic. On one hand, many developers seem to love them and treat the famous book by the Gang of Four like sacred scripture. On the other hand, many developers loath the very idea of design patterns. It’s not too hard to find posts around the web with titles such as “Design Patterns are Bad Design,” “Following Design Patterns Is A Bad Idea,” and of course, the inevitable “Design Patterns Considered Harmful.”
What can we take from that? Well, as it is with pretty much everything in our industry, it’s really hard to reach some form of consensus on design patterns. My take is this: design patterns are tools. Some are more useful, others less useful. Some may be outright harmful. And others may not make sense for your scenario, but maybe for Joe who sits three desks from you, they’re a gift from heaven.
But that’s not what this post is really about (i.e. deciding whether design patterns are “good” or “bad”). As we’ve seen, such discussion is simplistic and misses the point.
What we’re going to do instead is cover three design patterns that haven’t aged quite well. These design patterns are ones that you no longer go around implementing. And if you do, you probably shouldn’t.
Let’s get started.
Continue reading 3 Design Patterns That Have Aged Poorly
Most people that start programming learn to program in an imperative way. Shortly after, they will probably learn a declarative language too. Many developers go a long way without knowing the difference. Many will probably never know. And they could very well be great developers. But knowing the difference could change the way you write code for the better, so let’s dive in.
Continue reading Declarative Programming in Depth
When I was attending night school to become a programmer, I learned several design patterns: singleton, repository, factory, builder, decorator, etc. Design patterns give us a proven solution to existing and recurring problems. What I didn’t learn was that a similar mechanism exists on a higher level: software architecture patterns. These are patterns for the overall layout of your application or applications. They all have advantages and disadvantages. And they all address specific issues.
Continue reading Software Architecture: the 5 Patterns You Need to Know
After a somewhat long delay, it’s time to finally continue our series on clean architecture. This is the second post in the inner series in which we show you a quick implementation of said architecture and the third post in the overall series. In case you haven’t read the previous posts, please do so by using the links in the series layout below:
Without further ado, let’s continue our implementation.
Continue reading Continuing Our Clean Architecture Example in C#
Ah, the old “versus” Google search. Invariably, you’re in the research stage of some decision when you type this word into a search engine. Probably not something like Coke vs Pepsi. Maybe “C# vs Java for enterprise projects” or “angular vs react.” Or if you landed here, perhaps you’re looking at “log4net vs NLog.”
With a search like this, you expect a certain standard script. The writer should describe each one anecdotally, perhaps with a history. Then comes the matrix with a list of features and checks and exes for each one, followed by a sober list of strengths and weaknesses. Then, with a flourish, I should finish with a soggy conclusion that it really depends on your needs, but I maybe kinda sorta like one better.
I’m not going to do any of that. Continue reading Log4net vs NLog: A Comparison of How They Affect Codebases
Not that long ago, we published a post defending the SOLID principles of object-oriented design. In today’s post, we take it a step further: we’re going to present NDepend’s rules that will enable you to measure how SOLID your app is and show you the actions you can take to make it even better. Continue reading Use NDepend to Measure How SOLID Your Code Is
Programming languages come in all shapes and sizes: interpreted vs. compiled, weak vs. strong typing, low-level vs. high-level, terse vs. expressive… There are many buckets you can put a programming language into, even though not all are equally meaningful.
One very common way people classify languages is to organize them into paradigms. You can think of a paradigm as a group of languages that share similar characteristics. There are many paradigms currently in use: procedural, functional, and object-oriented. Many of these terms are often misused or confused; there’s also some degree of overlap between different paradigms, which definitely doesn’t make things easier.
Add all of that together and what you get is a landscape that’s not too easy for a beginner to grasp. In today’s post, we’ll try and fix this situation by giving you a clear picture of the imperative programming paradigm.
Continue reading Imperative Programming in Depth
Software development is a very young field, particularly when you compare it to, say, medicine or law. Despite this, there’s no shortage of wisdom pearls, which accumulated in the decades that preceded us.
One interesting phenomenon I’ve observed in myself over the years—and I’m sure there’s a name for it—is that some of these sayings sound like they must be right, even if I don’t really understand them the first time I hear them. For instance, in my post about the SOLID principles, I mentioned how the SRP’s definition—”each class should have just one reason to change”—just ticks the right boxes for me in some way that I can’t even pinpoint.
Unfortunately, just hearing a phrase and acknowledging that it kind of sounds right doesn’t do much to really make you understand the topic, right?
Then why do so many in our industry act like that’s the case? I’ve lost count of how many times I’ve seen experienced developers toss around catchphrases like this as if they’re able to automatically inject the necessary information into beginners’ heads.
In this spirit, I’ve decided to demystify one of these catchphrases that happens to be one of my favorites: “Separation of Concerns.” What does that mean and why should you care? That’s what today’s post is all about.
Continue reading Separation of Concerns, Explained