Clean Code: A Handbook of Agile Software Craftsmanship
There is a minimum expectation that, if you are a software developer, irrespective of programming language or discipline that you have actually read this book, at least more than twice! This book should be compulsory reading for anyone, working with code in any capacity.
Why I read this book
When I first picked this book up, back in 2006/7-ish if memory serves, it was around the time when .net MVC 1.0 was starting to make inroads, and developers, in general, were really starting to get in to Agile, the concept of Software Craftmanship was becoming a thing and Web 2.0 was actually a thing!
In truth, I only purchased this book, because a colleague of mine at the time just couldn't keep quiet about it. He often droned on about how the book had changed his outlook on software development and also was responsible for re-igniting his passion for it.
For some context, I am one of the Commodore 64 generation, one of those 80's kids who had nothing better to do with their time, except teaching themselves this computer thing. Everything I ever learned about computers was mostly involved doing it the wrong way until you finally found the right way. I've never had any formal training in software development or computer science for that matter. I've worked my way through thousands of tutorials, manuals, samples, articles etc. Learning more and more as I go and enjoyed every minute of it
When I figured out, that people would pay me money, to do exactly the same thing, I honestly thought I'd won the lottery!
The trouble is, if you think you develop bad habits and have incomplete knowledge as a self-taught computer programmer, that is absolutely nothing compared to when you join the corporate world and it's magnified tenfold! Enterprise development is an absolute cesspit of bad code and some of the worst practices.
I often reflect back on my first day as "Professional Software Developer" and opening up a "Professionally Developed" software application solution. The absolute horror I felt, reading the code and realising I couldn't make head or tail of it. Going home that night, I remember thinking, I better start thinking about getting another job, maybe in a sandwich shop or something because I'm obviously too stupid or just have so much more to learn!
It was only after, I'd finished my first few weeks, I realised that everybody else on my team was in exactly the same boat, irrespective of how long they had been working with the code base. It really was that awful!
If ever there was an over-complicated, over-engineered and for the most part poorly implemented software application, that was it. The trouble is, it was the lifeblood of the organisation. It was how the company made money, it was connected to all areas of the company!
I'd worked on that application for over 18 months in the end and I can honestly say, I don't think I ever really knew what was going on! It was a common occurrence, that developers could never add or change a line of code without it affecting some area of the application they never knew existed!
I was so happy when the day came, I could walk away from the code base, it was such a relief. I remember thinking to myself on the drive home that day - I'd done my apprenticeship and from here on in everything was only going to get better.
The following week, I started my new position, and I have to say, it was as if everything just got worse! The code was worse, things were messier and the one thing I could work out, is that some of the guy I was working with kept saying how much better things were compared to their last place! I went home those first few weeks, and kept scanning the classifieds for that coffee shop job!
It was around that time, I started my search for the Holy Grail - that code base so many folks talk about the one that was a pleasure to work with. I figured that I needed to start reading more books, improve my understanding and learn. For this must be the path to enlightenment!
Unfortunately, this was also around the time, when the internet happened! Suddenly people could make millions overnight if they could get a webpage up! Companies were investing vast amounts of money into E-Business and it seemed like most investors were taken too many E's! There were a whole new set of languages and technologies to learn. Nobody really knew anything, and everything was just kinda thrown together and if it stuck or worked that was deemed good enough!
I was just lost in the wilderness, no real clear direction of where I was heading or really why I was going there!
What I Learned from this book
As you can tell given my background, when you hear a colleague talk about Clean Code as it it was the answer, and there is no mention of the number 42, you'll know how susceptible people can be!
The opening chapter of this book, clearly resonated with me, in part because it clearly articulated all the frustrations I had ever experienced in my career as software developer. In some ways, I felt as if the other had been peering over my shoulder my entire career
The preface of the book will tell you that it is a Hard Book to read, I jokingly snigger to myself that, Bobby hadn't read any of the code bases I'd been reading, so I'm sure I'd find this book to be a walk in the park!
The reality is, that the book is a Hard book to read, hard in the respect, that once you start reading it, you realise that you need to drastically change the way you code! That even if you think the way you do things, is OK or even good enough then you have to re-think this fallacy.
One of the key points, I took away from this book, is the approach to comments. There is an entire chapter devoted to comments and it's actually well worth a read
The Only Truly Good Comment is the Comment You Found a Way Not To Write
This has to be my most favourite comment in the book because after years of reading totally pointless and worthless comments in code bases is I have more or less trained myself not to read them. In fact, one of the first things I do when setting up my IDE is to make to colour of comment text to be the same colour as the background. That was I never have to see them.
If I can't understand the code, then chances are I'm never going to understand the comments and I have very little faith that the comments are even going to be relevant to the code!
It's all in Java
I think what a lot of people miss about the fact the book is all in Java, is that they obviously weren't around when the primary language we were all working in, when Java come out was C++, Java was supposed to make things easier and improve our lives to make coding a pleasure. The reality is, Java only enabled C++ developers to make exactly the same mistakes only this time without having to worry about pointers!
A code smell is a code smell, irrespective of language. Having the ability to identify them, and to think about how to avoid them is essential. When writing a book on software development, you have to pick a language, whichever language you pick, you are going to upset the other tribes.
After reading and understanding the core concepts introduced in this book, you will easily be able to implement and understand the implementation in the programming language of your choice, mainly because the paradigms are all essentially the same. You'll also discover that a vast majority of the authors of various other books on clean code in other languages all cite Uncle Bob as their main influence.
For C# Developers, a great book on Clean Code Principles and applying Agile development techniques is Adaptive Code : Agile Coding with design patterns and SOLID principles.
The downside of this particular book, is that it could probably be considered as a "Gateway Drug" to the world of improving your software development skills.
Why I recommend this book
Regardless of your technology stack or particular focus every developer should read this book. In my opinion, you should read this book then read whichever "Clean Code in [insert language of choice] " book. This book forms the touch point or launch pad for those books, and many of the best practices, strategies and patterns would have originated from this book and then modified, improved or embellished in others. Understanding the root will greatly improve your knowledge of the branch!
Developers should care about the code they leave behind, often you will not be the developer to maintain code you write. The design decisions you make or that are enforced on you will not always be easy to decipher by reading the code. Your code may be easy to understand, but the reasons why will not be easily understood. In my opinion and the big take away that I took from the book, is about leaving codebase that you would like to maintain behind.
If you learn and understand a common set or working practices and ethos, then it will be easier for all developers to work in harmony regardless of technology stack. This book although not a complete comprehensive set of guidelines does form the basis for all developers to work from, so it is well worth taking the time to read this book and to start applying some of the patterns and practices to your development workflow.