Clean Architecture by Robert Martin — A Book Review
Clean Architecture is a third book in Robert C. Martin’s Clean Code collection, first two being Clean Code and Clean Coder. I really like the whole series. To me, Robert Martin writes simply, clearly, with enough examples and without unnecessary complicated details. His books can be read through, as well as used for reference, but I would say that his are the books that are better to be read cover to cover, sequentially, and not just being referenced as parts. Indeed, they not at all huge and are logically constructed in such a way as to provide a completed story.
The three books are talking about:
- Clean Code — how to write software in a clean (that is, readable, reusable, supportable, durable) way;
- Clean Coder — how to be a developer who writes clean code. This book, interestingly, deals mainly not with the coding skills, but with the soft skills and code of conduct required for such a task. Basically, it is a Bushido for the software developer. I would say that in that respect, it is the most interesting book of the series, worth reading and re-reading. This book is about what makes a developer a really great team player;
- Clean Architecture — the book about engineering software in general. It has only a few code examples, because it is really not about the code, but about the higher-order components which the code creates.
I have read the book in a couple of months, in fits and starts, and I think it was not the best way to do it justice. I confess that mainly it was because I read in on the train while commuting to work. However, the book is quite well adapted for being read this way, because the chapters are not long or complicated and I could finish a chapter a day, or sometimes two, on the good days that I was able to find a place to sit down and concentrate.
The pros of the book are, as I’ve said, that it is simply written, one can and should read it in full, it has clear-cut examples and is well structured. It is split into a good number of well-sized chapters that build on each other. It won’t give you a deep knowledge, but it is a stepping stone to understanding architecture — what it is, what are good and bad patterns, how one goes about building an application as a whole. It also has a good deal of real-life “war stories” that help illustrate the principles and their importance.
One of the cons of this books is, to me, an overuse of abbreviations. This is actually something that I don’t like in a lot of programming books. Yes there are some abbreviations that are common knowledge (SOLID principles, CAP theorem, YAGNI principle etc.), but the books usually introduce their own abbreviations, and if you are not reading the book through consistently, it is difficult to keep track of them. Also, they dissolve from your memory quite soon (I still have to look up SOLID principles and CAP theorem periodically — guilty! YAGNI, however, is quite easy to remember because it is a pure mnemonic technique — when it is decoded, it has no underlying meaning inside the elements, whereas in CAP and SOLID, every element, when decoded, requires an additional definition and description, so they are more layered).
‘Nuff said. If you are a software developer, it is well worth reading. And while you are at it, don’t forget about the previous two.
Uncle Bob strikes again.
