Lean Architecture: for Agile Software Development (Anglais) Broché – 13 juillet 2010
|Neuf à partir de||Occasion à partir de|
Les clients ayant acheté cet article ont également acheté
Descriptions du produit
Revue de presse
Présentation de l'éditeur
- Still seeking? In this book the authors help you to find your own path
- Taking cues from Lean development, they can help steer your project toward practices with longstanding track records
- Up–front architecture? Sure. You can deliver an architecture as code that compiles and that concretely guides development without bogging it down in a mass of documents and guesses about the implementation
- Documentation? Even a whiteboard diagram, or a CRC card, is documentation: the goal isn′t to avoid documentation, but to document just the right things in just the right amount
- Process? This all works within the frameworks of Scrum, XP, and other Agile approaches
Aucun appareil Kindle n'est requis. Téléchargez l'une des applis Kindle gratuites et commencez à lire les livres Kindle sur votre smartphone, tablette ou ordinateur.
Pour obtenir l'appli gratuite, saisissez votre adresse e-mail ou numéro de téléphone mobile.
Détails sur le produit
En savoir plus sur l'auteur
Dans ce livre(En savoir plus)
Commentaires en ligne
Meilleurs commentaires des clients
This quote from the book will give you a hint as to what to expect : "Architecture is not meant to be cast in stone, but to be an overall guiding light that makes it difficult to create errors of form."
Commentaires client les plus utiles sur Amazon.com (beta)
This is neither a beginner's "how to do it in ten easy lessons" nor is it a design method. It is a book written for the mature professional by two authors whose long experience has given them a deep understanding of what really matters in practical programming.
At a first glance, many methodologies appear as mere fads, but Coplien and Bjørnvig see through the fads and build on their real worth to create a thought-provoking and eminently practical book.
Three random jottings from my first reading:
* Architecture: "No matter how we care to define it, software architecture should support the enterprise value stream even to the extent that the source code itself should reflect the end user's mental model of the world."
* Lean secret: "...unite specialists together in one room: everybody, all together, from early on."
* Form and functionality: "System architecture should reflect the end user's mental model of the world. The model has two parts: The first part relates to the user's thought process when viewing the screen, and to what the system is: its form. The second part relates to what end users do - interacting with the system - and how the system should respond to user input. This is the system functionality. We work with users to elicit and develop these models and to capture them in code as early as possible."
The authors claim that an end user should have a picture in his head that enables him to see the commands that are meaningful in a given situation and to understand what they will do for him. This picture, Jim calls it the end user's mental model, it will be reflected into the actual code in well-built systems.
A few years ago, this reviewer introduced a new programming paradigm that he called Data, Context, and Interaction (DCI). The main feature of this paradigm is that it splits the code into two distinct parts. One part specifies system state; the other part specifies system behavior. Coplien and Bjørnvig use this paradigm to fill in the gap between architecture and code execution. To quote from the book:
* Key building blocks of object-oriented design: "Objects, which are end users' conceptualization of things in their business world; Classes, which provide simple, encapsulated access to the data that represents business information; Roles, which interact in a use case to achieve some business goal."
This book is a MUST read for all who want to understand the true nature of systems development.
It is refreshing to be reminded that OO is not only about subclassing and polymorphism, but one of its initial intent was having same mental (OO) model with your business partners.
I can see how it might not satisfy the most pragmatic programmers (and yes I am aware of the apparent contradiction: "lean and agile are for pragmatic developers!") Ample references are made to a topic carried on from an earlier book: Organizational Patterns, which is basically software architecture reflected in people interactions. Many techniques, habits, narratives, analogies or rules of thumb contribute to the originality of the material and the definition of the elusive features of software architecture.
A great practical description of how the use case evolves and translates directly into code, of how to reflect the end users mental model in code - making it much more readable for both programmers and domain experts. It goes into detail about how use case roles translates to Object Roles playing out their part of a use case algorithm and how they get injected into the domain objects to use their state. And we are presented with how the Context can set up the mapping of Roles to domain Objects in different flexible ways before firing off the trigger Interaction of the use case.
Apart from example code in C++ and Ruby through out the last chapters of the book, it also have a great appendix with coded DCI examples in Scala, Python, C#, Ruby and Squeak.
For anyone interested I can also recommend visiting the Google "object-composition" group where all the concepts are discussed and explored.
This book is a great read if you are an experienced developer. I do not recommend it to people new to the software development industry.
Do not pick this book up and think you are going to learn how to do software architecture. Personally I would have named the book "Thoughts on Lean". I found the book very interesting and found it to contain a lot of great advice, but it does not paint the complete picture of how to accomplish solid software architecture.
I like the DCI coverage, but would only use it if it can be documented better than what is shown in the book. Code is not enough documentation for me.
Personally I will apply the techniques in this book to modular level design and development. Over the years I have found that to be the place agile and lean development practices belong, not at the architecture level. Their programming techniques help to achieve a very modifiable architecture, which to me is the most import quality attribute you should strive for on any project of decent size.
Although my review comes off as a bit negative, the negativity is not a reflection of the quality of this book's wisdom. It is my personal bias against what the agile movement has done to the environments I am constantly finding myself cleaning up. Agile is perceived all to often as the easy road, when in fact it is a road only for the highly experienced and a select few.
All in all I recommend reading this book if you want to broaden your horizon. The personal insight the author provides into building software is worth the time.