Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series) 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Frequently bought together
What other items do customers buy after viewing this item?
From the Publisher
|A Handbook of Agile Software Craftsmanship||Practical Advice for the Professional Programmer||A Craftsman's Guide to Software Structure and Design||Professionalism, Pragmatism, Pride||Get Better Performance Out of Your Legacy Systems|
|Title||Clean Code||Clean Coder||Clean Architecture||The Software Craftsman||Working Effectively with Legacy Code|
|Core Concept||Best agile practices of cleaning code “on the fly” that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.||Robert C. Martin introduces the disciplines, techniques, tools, and practices of true software craftsmanship. This book is packed with practical advice–about everything from estimating and coding to refactoring and testing.||Uncle Bob presents the universal rules of software architecture that will help you dramatically improve developer productivity throughout the life of any software system.||Sandro Mancuso helped found the world’s largest organization of software craftsmen; now, he shares what he’s learned through inspiring examples and pragmatic advice you can use in your company, your projects, and your career.||Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts. Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases.|
|Endoresement||"It is the best pragmatic application of Lean principles to software I have ever seen in print." —James O. Coplien, Founder of the Pasteur Organizational Patterns project||“Some technical books inspire and teach; some delight and amuse. Rarely does a technical book do all four of these things. Read, learn, and live the lessons in this book and you can accurately call yourself a software professional.” —George Bullock Senior Program Manager Microsoft Corp.||"A good architecture comes from understanding it more as a journey than as a destination, more as an ongoing process of enquiry than as a frozen artifact." -- Kevlin Henney||"If you are the type of programmer, team lead, or manager who craves to be able to go home after a long day of work, look in the mirror, and say, 'Damn, I did a good job today!' then this is the book for you." -- Robert C. Martin||"This book describes a set of disciplines, concepts, and attitudes that you will carry with you for the rest of your career and that will help you to turn systems that gradually degrade into systems that gradually improve." --- Robert C. Martin|
About the Author
There was a problem filtering reviews right now. Please try again later.
The book starts with 3 myths we developers live in:
1. Myth: We just need to get to market first and we clean it up later.
2. Myth: Messy code makes us faster today and slows us later. Myth: We can switch mode from making messes to cleaning messes. (making messes is always slower, even in very short term as shown in example of a simple kata in the book)
3. Myth: Starting from scratch is a solution.
There is a well written history lesson in the next part. Uncle Bob presents Structured Programming, OOP and Functional Programming and says there is nothing else (programming paradigm-wise) to be invented. Part 3 is about SOLID principles from architecture point of view and part 4 are his Component Principles about component cohesion and coupling from his Agile Software Development book.
Part 5 is about Architecture and was the most interesting to read. Most memorable chapters for me were the Screaming Architecture and the Clean Architecture. Both of them are not new, you could have seen them in his videos or the article from 8thlight. The point of Screaming Architecture is that when a new developer joins a health-care project, he should be able to immediately tell "this is a health-care project" just from the project structure. Another topic which was part of multiple chapters, are micro-services. I felt that Robert Martin is not very fond of starting with them. He says services are little more than expensive function calls and as a communication mechanism between the project boundaries (i.e. a detail), they are a decision which should be deffered as far as possible.
Part 6, the Details, are a detailed explanations of his article Clean Architecture from 2012. There is a little gem in there, the Missing Chapter 34 written by Simon Brown. I liked his explanation of 4 different kinds of packaging classes together to form components.
Most of first one third of the book provides overview of programming paradigms such as structured design, object oriented, and functional decomposition. He then covers SOLID principles that he is best known for, i.e. single responsibility principle (SRP), open-close principle, liskov substitution principle, interface separation principle (ISP) and dependency inversion principle. In my opinion, these principles can be boiled down to interface/implementation separation and using composition over inheritance (concrete). He then applies these principles to components design such as reuse/release equivalence principle for releasing same component together, common closure principle similar to SRP and common reuse principle for using interfaces similar to ISP. Uncle Bob provides useful advice for using acyclic dependency principle for dependencies between components and ensuring that abstract/interfaces are used in stable components and volatile components (concrete implementation) should depend on stable components and not otherwise.
The last one quarter of the book finally starts with explanation on clean architecture that uses hexagonal architecture. He states that architecture should be independent of frameworks, UI and database. His definition of architecture only focuses on component design and communication but I use architecture as any design decision that is costly to change and often that include choice of databases, frameworks and UI. He uses layers and boundaries to divide system into various components and recommends use of entities for business policies, using techniques such as humble object pattern for testing hard to test components. In final chapters, he proposed designing components based on use cases instead of horizontal, which has worked better in my experience when working on a large system.
In the end, this book has plenty of nuggets on design of components but take this advice with a grain of salt. Uncle Bob’s militant views on clean design, test driven development and his abhorrence for tools is not very pragmatic. For example, he doesn’t mention technical debt, refactoring or dealing with legacy systems. Though, he pays attention to maintainability but he ignores most of other non functional requirements such as scalability, availability, reliability and ignores emphasis on developer productivity. In my experience, software design and development should start with the business requirements, constraints and organization structure. You may be working in a startup that needs to prove an idea with minimal effort or you may be working on designing a service with a large number of users. Similarly, you may be working with a small team or on a large project that needs to interact with a number of teams where you may need to apply Conway’s law to design the system. In real world, you face these choices instead of writing perfect components with 100% test coverage, which may be maintainable but not useful to anyone and thus killing your company and leaving you without work.
My caveat is that, having gone through so much of Bob's previous material, there was unfortunately much here that was already familiar to me, including some sections that are taken almost verbatim from his previous writings. In itself this is no problem - had it been the first I ever read of the man I would be totally ecstatic about it, and it's reasonable of him to assume that most readers would not have followed him around the internets as assiduously as I have. But I was hoping to hear more about topics he only hinted at in his blog posts, e.g. the different kinds of architecture implied by different desired user experiences. I read him mention event-driven, request-based, and batch processing, and I was assuming he would elaborate on these ideas in this book, which he does not. There are many other details I wish he'd gone into or at least offered good follow-up reading on, such as presenters and the creation of use cases.
Finally, he does not appear to provide the name of the stellar body on the cover, which is an unfortunate break with custom.
Top international reviews
At the end there is a 50-pages appendix where Robert Martin describes many of the projects he worked on, from the early 1970s to the 1990s. Many of the problems from those projects are interesting case studies that you can learn from - I quite enjoyed reading those stories (somewhat to my own surprise).
Die ersten Kapitel waren wirklich sehr dünn, als Quereinsteiger eventuell hilfreich aber zum Großteil allgemein bekannte Dinge.
Ab dem Kapitel "Clean Architecture" geht es dann wirklich los. Es wird viel über Boundaries gesprochen und häufig wiederholt, dass man Designentscheidungen möglichst vermeidet und alle Optionen offen lässt. Das ist ein guter Rat, hat aber mit Software Architektur nicht besonders viel zu tun, denn diese Endscheidungen zu treffen ist ja genau der Punkt. Es bleibt auch alles wenig konkret. Die Kernaussage ist, dass man sich seine Businesslogik frei von Abhängigkeiten halten soll und das wird auch mit trivialen Beispielen gezeigt. Leider ist die Welt nicht so trivial und auch die Case Study gibt keine konkreten Tipps.
Ja die Dinge, die angesprochen werden, kann man so unterschreiben, aber der große Erkenntnisgewinn bleibt aus. Letztlich keine Kaufempfehlung, da gibt es bessere Bücher. Beispielsweise Game Engine Architecture, was zwar auf die Spieleentwicklung abzielt aber auch für andere Bereiche interessant ist. Hier geht es es ins Detail und die konkrete Umsetzung.
This book is nothing than an over verbose description of the SOLID principles.
You have to admire the author though. Converting a 2 pages document into a 300+ book require skills rarely seen outside politics
1.1: x-axis not defined, y-axis no measure,
1.2 x-axis not defined, title is Productivity over the same period of time. What do you mean ‘same period’? The previous chart had no title of x-axis that mentioned ‘time’.
1.3 x-axis is named ‘Major release’, the title is Cost per line of code over time (is it ‘Major release’ or is it ‘time’?), Y-axis: no unit.
1.4 x-axis: no mentioning. Y-axis not defined.
How sloppy can you be? Is there no editor involved?
I quite enjoyed reading it, which is rare with technical books.
I think it is very good for someone that has some idea of clean code, design patterns and software architecture principles already and wants to understand where these ideas come from and how they fit together.