As a dev looking to hone your software architecture and design chops, you’ve undoubtedly been recommended the standard set of books: Clean Code (and Coder), Code Complete, Head First Design Patterns, etc, etc…
A (relative) newcomer is the book Adaptive Code via C#: Agile coding with design patterns and SOLID principles by Gary McLean Hall. It’s been recommended more and more frequently because it covers overarching, battle-tested design principles and strategies, but from the context of .NET and C#.
You know, our bread and butter.
I bought this book last year but never got around to opening it…
Oh.. you too?
Oh you mean you haven’t even bought it yet?
Well I’ve got good news for the both of us.
Adaptive Code Chapter Synthesis
Instead of you buying it, I’ll do the reading and share what I’ve found in a concise way.
You may decide to read it on your own anyway, which is a good thing, but these articles can act as a kind of cliff notes, or just to help you decide if you should buy it or not.
I might lump some chapters together, or gloss over parts I find boring, but I’ll do my best to include the good parts.
Adaptive Code Opening and Overview
The book begins by painting a picture for us about what adaptive code really means. In essence, it’s code that is able to adapt to unforeseen requirements and avoids a need for significant rework.
I’ve been a developer for over a decade now and the waterfall method has rarely been spoken of in my career. All my roles have been on an agile team of some sort, so this opening was a bit boring.
Although I didn’t need to be convinced of the benefits of agile over waterfall, the author sets the stage this way because in his idea, the agile method is like the outer layer of the onion for adaptive code.
If the way you organize your work is to be super flexible and ready for change, your code has to be that way too otherwise your words and intent won’t match your capability. See how dependency injection can support flexibility.
Agile is embracing change, and code is not like brick and mortar. It’s malleable, so why not keep it that way?
Bridging Theory and Practice
Continuing to outline the goal of the book, the author reminds us that day to day programming in the trenches rarely matches simple examples or theory.
Ain’t that the truth.
How many tutorials have you followed and then realized the author just told you what to do but not why? If you don’t understand the why, the knowledge rarely sticks.
This book attempts to combine the theory of application design and SOLID principles with practical, real world use cases to bridge the gap between theory and practice for us in the .NET and C# world.
I was excited to find that this book also addresses maladaptive code.
The naughty stuff…
You can’t know your blind spots unless someone else points them out to you, so hopefully this book will uncover some shit code of ours and actually explain why it sucks and how to fix it.
On the subject of inflexible code, my team has some notification email templates that we use in our application that are laced with inline CSS. A simple example of maladaptivity, rather than being able to update them with a single CSS stylesheet, we’ve gotta rework each individual template, and there’s over 100 of ‘em. #TechDebt.
Three Main Parts
The book divided into 3 main parts that build on each other.
In Part 1, the author dives a bit deeper into agile and scrum (snore) but then moves into a focus on interfaces, dependencies and layering, design patterns, refactoring, and unit testing.
Part 2 goes into some core strategies we’ve heard over and over like the single responsibiliity principle, open closed principle, liskov substitution, interface segregation, and dependency injection.
Remember, it’s not just theory. Each section will include practical examples.
And finally, Part 3 attempts to tie everything together with a ton of sample code and a sample application. So this is where we hopefully get to see a fully connected modern application taking advantage of everything we’ve learned and demonstrating the flexibility we’ve earned.
I’m excited to dig in. This book has been on my shelf for too long and I’m thirsting to fill my toolbox with more pro dev strategies.
In the next article we will dive into the book’s take on agile, interfaces, dependencies, and layering. Sign up below to get them as they come out.