Scan barcode
erikars's review against another edition
2.0
All software projects have architecture, but not all have formal Architecture. This is a book for projects of the latter sort. Although the text had gems scattered throughout, much of what was presented was much too formal for the more agile and informal environment I work.
My recommendation is that most people will get the most value by skimming the prologue, especially sections P.2.2 and uses and audiences for architecture documentation, section P.4 on architecture styles, and P.5 on rules for sound documentation[1]. Flip through the chapters on the different view types and read the description of those that feel most relevant (skip the text about the examples and just look at the diagrams). Read chapter 7 on documenting software interfaces. Skim chapter 8 on documenting behavior. Read chapter 11 on reviewing an architecture document.
You won't find all of the gems this way, but you'll get a better value for your time investment than if you were to read the whole thing.
[1] In sum:
1. Write documentation from the reader's point of view
2. Avoid unnecessary repetition
3. Avoid ambiguity
4. Use a standard organization
5. Record rationale
6. Keep documentation current but not too current
7. Review documentation for fitness of purpose.
My recommendation is that most people will get the most value by skimming the prologue, especially sections P.2.2 and uses and audiences for architecture documentation, section P.4 on architecture styles, and P.5 on rules for sound documentation[1]. Flip through the chapters on the different view types and read the description of those that feel most relevant (skip the text about the examples and just look at the diagrams). Read chapter 7 on documenting software interfaces. Skim chapter 8 on documenting behavior. Read chapter 11 on reviewing an architecture document.
You won't find all of the gems this way, but you'll get a better value for your time investment than if you were to read the whole thing.
[1] In sum:
1. Write documentation from the reader's point of view
2. Avoid unnecessary repetition
3. Avoid ambiguity
4. Use a standard organization
5. Record rationale
6. Keep documentation current but not too current
7. Review documentation for fitness of purpose.
riduidel's review against another edition
3.0
Dans ce pavé, on trouvera des informations sur tous els types de vues utilisables dans la documentation d'architecture logicielle, mais aussi des éléments permettant de valider la complétude d'une documentation, avec des méthodes assez intelligentes.
Il y a par ailleurs un chapitre remarquable sur la documentation de décisions d'architecture, qui va bien plus loin que le simple "utilisez des ADR".
Pour le reste, la plupart des vues m'étaient déja bien connues, et ce livre se contentait d'en donner les forces, faiblesses et cas d'application avec un template de document qui, sans être inutile, me paraît assez lourd.
En bonus, deux annexes sur UML et SysML complètent l'ouvrage.
Ca en fait un bon point d'entrée à la documentation d'architecture, avec une méthode peut-être un peu dépassée par la révolution des conteneurs.
Il y a par ailleurs un chapitre remarquable sur la documentation de décisions d'architecture, qui va bien plus loin que le simple "utilisez des ADR".
Pour le reste, la plupart des vues m'étaient déja bien connues, et ce livre se contentait d'en donner les forces, faiblesses et cas d'application avec un template de document qui, sans être inutile, me paraît assez lourd.
En bonus, deux annexes sur UML et SysML complètent l'ouvrage.
Ca en fait un bon point d'entrée à la documentation d'architecture, avec une méthode peut-être un peu dépassée par la révolution des conteneurs.
fcannon's review against another edition
3.0
A good overview of how to formally document your architecture, and why you should care. But I found the terminology a little hard to follow, and I'm not sure I would be able to learn from this book if I didn't already have prior experience with this kind of documentation.
Although not specifically about documenting, I found 'Just Enough Software Architecture' was a more understandable justification for doing it.
Although not specifically about documenting, I found 'Just Enough Software Architecture' was a more understandable justification for doing it.
More...