There was a time when Linq was a mystery to me. But, now that I’ve learned how to use it, I don’t know how I ever lived without it! You’ll learn Linq with this complete beginner’s gentle introduction. All you need to know before you start is how to code a loop. Heck, I’ll even show you that first. Ready? Let’s get started!
Continue reading Linq Tutorial: A Complete Beginner’s Gentle Introduction
Quite often we talk about architectural concerns on this blog, with topics like application layering or the merits of design patterns. But today I’m going to switch gears a little and talk about your wallet.
Oh, don’t worry. We’re not going too far afield. I’m going to talk about how your developer tools purchases affect your wallet.
When it comes to product support, you probably don’t give this a ton of thought. At least, you’re probably more focused on features, what problems the product solves for you, what the price is, and so on. The support arrangement probably matters somewhat to you, but doesn’t rise to top of mind.
But today, I’m going to ask you to think about it a little bit. And I’m going to suggest that you give a quick consideration during future purchases as to how support works. Simply ask yourself, “does this vendor ask you to pay extra for support?”
If the answer is yes, that’s a smell.
Continue reading You Should Favor Software Products That Include Support in the Price
As an architect, you know that programming to an interface is good. It’s what everyone should do.
But what does that mean? And why should you do it?
Searching the Internet for answers might only cause more confusion. There, you’ll find people arguing over what “programming to an interface” really means. And how everyone else is wrong about it. Yet everyone’s definition sounds pretty much the same. But is supposedly different. Somehow.
Let’s remove the confusion and break it down. In this post, we’ll look at what it means to program to an interface and why you should do it.
Continue reading Programming to an Interface: A Simple Explanation
In this day and age, unit testing isn’t as controversial as it once was. Sure, you still see the occasional inflammatory, clickbait-y, confrontational “unit testing is garbage” type of post on Reddit and Hacker News.
And there are still developers out there ignorant of the existence of unit testing—or any type of automated testing, for what it’s worth. Believe it or not.
However, if we consider the developers that do know about unit testing, I’d say the debate is pretty much over. It’s generally agreed, today, that unit testing has a positive influence on software projects.
With that in mind, the next question then becomes “what makes for a good unit test?” That’s what this post is all about. Today, we present you five must-haves for a great unit test.
Layered architecture gets a lot of flack.
Even though it’s still the most prevalent architecture, we view it as an anti-pattern. It’s old, not scaleable, and anti-SOLID. It encourages (shudder) monoliths!
Yes, I know. Hexagonal architecture is the way to go. Or maybe I’m feeling a taste for onions. But only if it’s clean!
The point is that even though it may not be an object-oriented nirvana, layered architecture is still a useful pattern. And if done right, it paves the way towards more advanced designs and architecture.
So let’s talk about layers.
Continue reading Layered Architecture: Still a Solid Approach
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.
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.
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