IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
logo

Critiques des meilleurs livres de conception - Les livres anglais

Dernière mise à jour : 09/12/2009


precedent    sommaire    suivant



couverture du livre 'Cloud Application Architectures'

Note 4.0

Cloud Application Architectures

Building Applications and Infrastructure in the Cloud

de Georges Reese
Public visé : débutant

Résumé de l'éditeur

If you're involved in planning IT infrastructure as a network or system architect, system administrator, or developer, this book will help you adapt your skills to work with these highly scalable, highly redundant infrastructure services. will help you determine whether and how to put your applications into these virtualized services, with critical guidance on issues of cost, availability, performance, scaling, privacy, and security.
Critique du livre par la rédaction (Pierre Chauvin)
Le livre Cloud Application Architectures est idéal pour les lecteurs sans réelles connaissances sur le sujet, plutôt orientés infrastructure que développement. Son faible volume (moins de 200 pages) et la qualité d'écriture de Georges Reese vous invitera à découvrir les concepts et ambitions du Cloud Computing, mais également de mieux comprendre les infrastructures PaaS, IaaS, SaaS.

Georges Reese illustre la description des architectures de Cloud Computing en s'appuyant sur la solution la plus aboutie du marché (à ce jour) : en Amazon Web Services (AWS). Il détaille ainsi les différentes composantes déployées par Amazon pour proposer une plateforme pour le Cloud: EC2, S3, CloudFront, SQS, RDS, EBS.
Le chapitre 3 s'attache à exposer les arguments en faveur des infrastructures de type Cloud par rapport aux anciens modèles. Des informations relatives au calcul du retour sur investissement (ROI), du TCO (Total Cost of Ownership) sont distillées et permettront au décideur de disposer d'une aide pour évaluer son projet de Cloud.

Les chapitres suivants sont consacrés aux images AMI, à la sécurité (données, réseau, corruption), au disaster recovery et à la montée en charge, l'un des intérêts principaux du Cloud. De nombreux conseils et préconisations sont fournis, afin de vous éviter de tomber dans les pièges des débutants et tirer partie de l'intégralité de AWS. De très bonne lecture, je vous invite, administrateurs, décideurs, à feuilleter cet ouvrage.

Sommaire

  • Chapitre 1. Cloud Computing
  • Chapitre 2. Amazon Cloud Computing
  • Chapitre 3. Before the move into the Cloud
  • Chapitre 4. Ready for the Cloud
  • Chapitre 5. Security
  • Chapitre 6. Disaster Recovery
  • Chapitre 7. Scaling a Cloud infrastructure
  • A. Amazon Web Services reference
  • B. Gogrid
  • C. Rackspace

204 pages, 1ère édition, avril 2009 Editions O'Reilly , ISBN10 : 0596156367
Commandez sur www.amazon.fr :
20,13 EUR TTC (prix éditeur 29,99 EUR TTC) - Livraison Gratuite !
couverture du livre '97 Things Every Software Architect Should Know'

Note 4.0

97 Things Every Software Architect Should Know

de Richard Monson-Haefel
Public visé : Tous

Résumé de l'éditeur

In this truly unique technical book, today's leading software architects present valuable principles on key development issues that go way beyond technology. More than four dozen architects -- including Neal Ford, Michael Nygard, and Bill de hOra -- offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they've learned from years of experience. Among the 97 principles in this book, you'll find useful advice such as:

  • Don't Put Your Resume Ahead of the Requirements (Nitin Borwankar)
  • Chances Are, Your Biggest Problem Isn't Technical (Mark Ramm)
  • Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
  • Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
  • For the End User, the Interface Is the System (Vinayak Hegde)
  • It's Never Too Early to Think About Performance (Rebecca Parsons)
To be successful as a software architect, you need to master both business and technology. This book tells you what top software architects think is important and how they approach a project. If you want to enhance your career, 97 Things Every Software Architect Should Know is essential reading.


Critique du livre par la rédaction (Eric Reboisson) (Août 2009)
Pourquoi 97 trucs ? A vrai dire, je ne sais pas et je pense qu'il faut y voir la même astuce que le célèbre slogan de Magritte que l'on trouvera dans un chapitre du livre "Ceci n'est pas une pipe" (je vous laisse découvrir), à savoir que l'essentiel n'est pas toujours dans les apparences.

Un livre court (220 pages) et qui va à l'essentiel, 2 pages et la biographie des auteurs/architectes pour chaque sujet. Pas techniquement orienté, ce livre est plutôt axé sur la communication, et les ressources projet. On trouvera des conseils sur comment choisir les composants d'un projet, la gestion des équipes, savoir convaincre et communiquer au sein d'une équipe mais aussi avec le client.

Parmi mes sujets favoris (seulement quelques uns car j'ai marqué pas mal de pages) :

  • "Stand Up!" de Udi Dahan qui explique que se mettre debout permet de mieux se faire écouter, comprendre, essentiel pour un architecte.
  • "Architects Must Be Hands On" de John Davies expose que l'architecte pour être reconnu, et appuyé dans ses décisions devra faire ses preuves sur le terrain et non depuis sa tour d'ivoire.
  • "Fight Repetition" de Niclas Nillson, un titre pas trop difficile à comprendre, quand on rencontre plus d'une fois la même situation il faut penser à automatiser.
Certains reprocheront que les explications fournies dans cet ouvrage relèvent simplement du bon sens de l'architecte (mais un rappel ne fait pas de mal), sûrement, mais je pense qu'il est bon de mettre le focus sur des points clés qui devraient être un credo pour tous les architectes.

Bien sûr, certains sujets ne m'ont pas intéressés, souvent parce que je n'en ai pas l'utilité actuellement, certains chapitres sont même répétés ("Architects Must Be Hands On" et "Before Anything, an Architect is a Developper") mais au final je pense que ce livre est une très bonne ressource à garder à portée de main. La granularité des sujets est parfaite pour une relecture rapide ultérieure lorsque le besoin de guider ses choix se fera sentir. Facile à lire, j'ai opté pour un rythme de lecture "4 à 5" sujets par soir (en plus les titres font presque penser à des contes), mais "1 ou 2" le matin avant de commencer la journée de travail ira aussi. A mon sens, un bon achat à faire !

220 pages, 1ère édition, 17 mars 2009 Editions O'Reilly, ISBN10 : 059652269X, ISBN13 : 978-0596522698
Commandez sur www.amazon.fr :
31,96 EUR TTC (prix éditeur 31,53 EUR TTC) - Livraison Gratuite !
couverture du livre 'Masterminds of Programming'

Note 5.0

Masterminds of Programming

de Federico Biancuzzi et Shane Warden
Public visé : Initié à Expert

Résumé de l'éditeur

Masterminds or Programming features exclusive interviews with the creators of several historic and highly influential programming languages. In this unique interview collection, you'll lean about the processes that led to specific design decisions, including the goals thes pionners had in mind, the trade-offs they had to make, and how their experiences have made an impact on programming today. This book includes interviews with:

  • Adin D. Falkoff: APL
  • Thomas E. Kurtz: BASIC
  • Charles H. Moore: FORTH
  • Robin Milner: ML
  • Donald D. Chamberlin: SQL
  • Alfred Aho, Peter Weinberger, and Brian Kernighan: AWK
  • Charles Geschke and John Warnock: PostScript
  • Bjarne Stroustrup: C++
  • Bertrand Meyer: Eiffel
  • Brad Cox and Tom Love: Objective-C
  • Larry Wall: Perl
  • Simon Peyton Jones, Paul Hudak, Philip Wadler, and John Hughes: Haskell
  • Guido van Rossum: Python
  • Luiz Herique de Figueiredo and Roberto Ierusalimschy: Lua
  • James Gosling: Java
  • Grady Booch, Ivar Jacobson, and James Rumbaugh: UML
  • Anders Hejlsberg: Delphi inventor and lead developer of C#
If you're interested in the people whose vision and hard work helped shape the computer industry, you'll find Masterminds of Programming fascinating.


Critique du livre par la rédaction (Doeraene Sébastien)
Lors que j'ai lu le résumé de ce livre, j'ai su que je voulais le lire. Et à la fin de ma lecture, je ne suis absolument pas déçu, bien au contraire !

Au contraire des ouvrages habituels sur la programmation, celui-ci ne vous apprendra pas le moins du monde à programmer, ni même à concevoir, ni ne vous apprendra un quelconque nouveau langage. Mais il vous fera découvrir les états d'esprit, de synthèse, de conception, de ce que l'auteur a nommé les masterminds (les génies) de la programmation.

Il est difficile de critiquer ce livre sur la base de son écriture ou de sa pédagogie, qui sont tout simplement sans objet ici. En revanche, je soulignerai la qualité du choix des questions posées en interview, ainsi que l'apport global que le lecteur pourra en tirer, qui sont exceptionnels.

Je recommande en particulier ce livre à tous ceux qui conçoivent - ou qui ont l'intention de concevoir - un langage de programmation. Les conseils, prodigués par les maîtres en la matière, que cet ouvrage nous livre leur seront d'une aide incontestable. Ceci est valable également pour les étudiants pour qui ce serait un projet de cours ou de mémoire.

Ceci ne veut pas dire pour autant que je ne le conseille pas aux autres développeurs. Les discussions avec ces génies de la programmation seront bénéfiques à tous, ne serait-ce que pour comprendre les raisons d'existence des langages qu'ils utilisent au quotidien.

En bref, un livre à lire au moins une fois dans sa vie - si pas plus !

Sommaire

  • C++ - Bjarne Stroustrup
  • PYTHON - Guido von Rossum
  • APL - Adin D. Falkoff
  • FORTH - Charles D. Moore
  • BASIC - Thomas E. Kurtz
  • AWK - Alfred Aho, Peter Weinberger, and Brian Kernighan
  • LUA - Luiz Henrique de Figueiredo and Roberto Ierusalimschy
  • HASKELL - Simon Peyton Jones, Paul Hudak, Philip Wadler, and John Hughes
  • ML - Robin Milner
  • SQL - Don Chamberlin
  • OBJECTIVE-C - Brad Cox and Tom Love
  • JAVA - James Gosling
  • C# - Anders Hejlsberg
  • UML - Ivar Jacobson, James Rumbaugh, and Grady Booch
  • PERL - Larry Wall
  • POSTSCRIPT - Charles Geschke and John Warnock
  • EIFFEL - Bertrand Meyer

494 pages, 1ère édition, Avril 2009 Editions O'Reilly UK, ISBN10 : 0596515170, ISBN13 : 9780596515171
Commandez sur www.amazon.fr :
36,47 EUR TTC (prix éditeur 36,70 EUR TTC) - Livraison Gratuite !
couverture du livre 'Beautiful Architecture'

Note 3.0

Beautiful Architecture

de Diomidis Spinellis, Georgios Gousios
Public visé : Tous

Résumé de l'éditeur

What are the ingredients of robust, elegant, flexible, and maintainable software architecture? Beautiful Architecture answers this question through a collection of intriguing essays from more than a dozen of today's leading software designers and architects. In each essay, contributors present a notable software architecture, and analyze what makes it innovative and ideal for its purpose.


Critique du livre par la rédaction (Eric Reboisson) (Août 2009)
"Beautiful Architecture" est un ouvrage composé de 14 chapitres sur le sujet de l'architecture logicielle. Un vaste domaine de l'industrie logicielle qu'il est assez difficile de définir, si je devais en faire une peinture basique, ce serait l'art de définir la structure d'un système, de ses composants et des relations entre les différents éléments qui la composent.

Le livre commence ainsi sur un premier chapitre qui tente de répondre à la question de ce qu'est l'architecture, question maintes fois posée, mais sur laquelle apparemment plane toujours le doute. Un second chapitre compare 2 applications, un mauvais exemple, puis un bon (selon les auteurs) puis suivent 12 derniers chapitres couvrants des thèmes très différents (facebook, emacs, KDE...) et toujours étroitement liés à l'architecture (quoique).

Les bons points du livre

  • Un contenu plutôt intéressant avec lequel on apprend parfois
  • Des sujets tendances ou qui sauront toucher : facebook , MMORPG, KDE, emacs...
Les moins

  • Une lecture quelque peu ennuyeuse et rébarbative (j'ai eu parfois l'impression d'un simple remplissage des pages)
  • Une mise en page triste
  • Quel crédit donner aux architectes mentionnés dans le livre ?
  • Manque de cohésion entre les chapitres et finalement sur le livre en entier, plusieurs auteurs donc plusieurs visions différentes et pas toujours de concert
  • En principe l'architecture n'est pas le code, on pourrait alors se poser la question de la présence de bout de code dans le livre
  • Un bon bagage est nécessaire avant d'entamer la lecture, développeur junior passe ton chemin...
J'ai au final un avis très mitigé sur cet ouvrage, partagé entre le fait d'avoir appris à la lecture de "Beautiful Architecture" car on a quand même un bon livre pour se donner des idées et de l'information sur l'architecture logicielle, mais l'ennui à la lecture était trop présent pour en faire un "must-have". Comment utiliser ce livre ? pour ma part certains chapitres m'ont plus intéressé et j'en ai retenu de l'information immédiatement, pour d'autres j'ai repéré de l'information qui me servira peut être un jour...

Critique du livre par la rédaction (Matthieu Brucher) (08/2009)
Beautiful Architecture est une sorte de suite de Beautiful Code que j'ai eu l'occasion de lire par le passé. Bien plus petit, ce livre est dédié à l'architecture, même si Beautiful Code proposait aussi certains aspects sur l'architecture. La question qui restait était de savoir si le livre était aussi bon que son prédécesseur.

L'éditeur du livre l'a découpé en 5 parties. La première est très générale et courte. Le principal sujet est la raison pour laquelle il est nécessaire d'avoir une bonne architecture, avec des expériences réelles sur une bonne et une mauvaise architecture. C'est une introduction nécessaire, même si le contenu est plutôt convenu.

La seconde m'a laissé quelque peu déboussolé. Lorsqu'on connait un peu des ouvrages sur l'architecture, on apprend peu. OK, c'est un ouvrage sur l'architecture logicielle, mais de vraies architectures sont attendues, et certaines de celles présentées (comme les web services) sont plutôt évidentes, même si le chapitre sur Facebook est intéressant à ce niveau.

La partie suivante est dédiée au matériel, émulé, virtualisé ou le vrai. Cette partie était vraiment intéressante, avec beaucoup de détails sur des projets connus (Xen) ou moins connu (Guardian, bien connu il y a quelques années et très intéressant quant à sa philosophie). J'ai eu moins d'intérêt pour les deux projets Java, comme il ne s'agit pas d'une technologie que j'utilise tous les jours, mais l'approche était plaisante.

Après le matériel, deux chapitres sont dédiés à deux projets très connus et très différents : Emacs et KDE. Le chapitre est plus consacré à l'équipe et à comment l'architecture a émergé de discussions, qu'à l'architecture elle-même, et je pense que l'autre message derrière cette partie est d'apprendre à communiquer à l'intérieur d'une équipe de développement.

Enfin, la conclusion commence par une discussion sur les langages orientés objet (le type le plus utilisé actuellement) contre les langages fonctionnels, écrite par une référence dans le domaine, Bertrand Meyer. Il faut être bien concentré pour comprendre son message. Pour cette démonstration, Meyer utilise un langage orienté objet réel, Eiffel, non pas un des langages "incomplets" comme C++ ou Java. Par conséquent, certains concepts peuvent échapper au lecteur. Et le dernier chapitre discute des architectures surfaites, générant des programmes incomplets avec des exemples où des architectes en bâtiment célèbres ont créé de superbes architectures tout en perdant de vue l'objectif principal qui était le logement (et non la beauté extérieure). Comme chaque livre sur l'architecture ou la conception logicielle, il est nécessaire d'expliciter que le mieux est l'ennemi du bien.

Moins surprenant que son prédécesseur, plus court et moins impressionnant, ce livre est parfois ennuyeux. D'un point de vue culturel, il est très bon, avec des exemples de domaines différents. Certains chapitres sont trop évidents si on est déjà habitué au sujet, et cela gâche le plaisir de la lecture.

Beautiful Architecture is a kind of follow-up of Beautiful Code, which I reviewed some time ago. Far smaller, the book is aimed at architecture, although Beautiful Code also presented some aspect of architecture. The question I've asked myself whether or not it is as good as its predecessor.

The editor split the different architecture topics in 5 parts. The first is very general, and short. The main topic is why you should have a good architecture, with some real experience with good and bad architectures. It's a necessary introduction, even if the content is to be expected.

The second part left me with mixed feelings. If you're used to architectural readings, you won't learn much, in my opinion. OK, it's a book on software architecture, but actual architectures are expected, and some displayed architectures (like web services) are obvious, although Facebook's chapter is interesting in that matter.

The third part is dedicated to hardware, emulation, virtualization or real one. This was really interesting, with a lot of details on known projects (Xen) or lesser-known ones (Guardian, which I didn't hear about until the book, but which was really interesting in its philosophy). I had less interest in both Java projects, as it's not something I deal with on a regular basis, but the approach was enjoyable.

After the hardware, two chapters are dedicated to two well-known projects with really different teams, Emacs and KDE. KDE's chapter is almost more about the team and how the architecture emerged from team's discussions than architecture itself, and I think that another message behind this part is to learn to communicate inside the developer team.

Finally the conclusion starts with a discussion on object-oriented languages (the kind that is mainly used) versus functional ones, by a reference in that field, Bertrand Meyer. One has to be focused to fully understand Meyer's message. For his demonstration, he uses a real object-oriented language, Eiffel, and not one of the usual not-fully object-oriented languages like C++ or Java. So some concepts may be missing to you. And the last chapter is about overdoing an architecture and finishing with a half-baked software with examples from the buildings architecture where some famous architects overdid their work and losing sight of the buyer's needs. Like every book on architecture or software conception, it is best to explicitely state that too much is the enemy of a good program.

Less surprising than its predecessor, shorter and with less magnificence, this book is sometimes more boring. From a cultural point of view, it's a good one, with examples for very distinct fields. Some chapters are too obvious if one is familiar with the field, and this spoils a little bit the pleasure of reading.

426 pages, 1ère édition, mars 2009 Editions O'Reilly, ISBN10 : 059651798X, ISBN13 : 978-0596517984
Commandez sur www.amazon.fr :
40,14 EUR TTC (prix éditeur 40,86 EUR TTC) - Livraison Gratuite !
couverture du livre 'The Art of Unit Testing'

Note 4.5

The Art of Unit Testing

With Examples in .NET

de Roy Osherove
Public visé : Spécialiste, Expérimenté

Résumé de l'éditeur

Unit testing, done right, can mean the difference between a failed project and a successful one, between a maintainable code base and a code base that no one dares touch, and between getting home at 2 AM or getting home in time for dinner, even before a release deadline.

The Art of Unit Testing builds on top of what's already been written about this important topic. It guides you step by step from simple tests to tests that are maintainable, readable, and trustworthy. It covers advanced subjects like mocks, stubs, and frameworks such as Typemock Isolator and Rhino Mocks. And you'll learn about advanced test patterns and organization, working with legacy code and even untestable code. The book discusses tools you need when testing databases and other technologies. It's written for .NET developers but others will also benefit from this book.


Critique du livre par Philippe Vialatte (26/07/2009)
Version française

On ne présente plus l'intérêt des tests unitaires. En effet, cette technique devient de plus en plus répandue dans le monde informatique, quel que soit le langage, et permet, lorsque ces tests sont bien faits, d'améliorer nettement la qualité du logiciel produit, tout en facilitant la maintenance du produit. Des tests unitaires bien codés permettent de détecter rapidement tout nouveau bug introduit dans le projet, et peuvent donc éviter des régressions dans le code.

La question qui reste souvent en suspens est de savoir comment produire de "bons" tests unitaires. La littérature informatique contient un nombre important de livres parlant de méthodologies (Agile, XP, Scrum), mais il manquait (en tout cas, en .NET), un livre explicitant clairement comment produire des tests unitaires de qualité. C'est l'objectif de The Art Of Unit Testing.

Le livre commence par une introduction aux tests unitaires, à NUnit, et par un ensemble de définitions. On passe ensuite assez vite à un peu de pratique avec un premier test unitaire.

La partie suivante approfondit la notion de mock et de stubs, et aborde en profondeur le Framework Rhino Mocks. Cette partie présente de plus un ensemble de bonnes pratiques liées à l'utilisation de ce Framework, ou de tout autre Framework d'isolation.

Après avoir abordé les éléments constitutifs des tests unitaires, la troisième partie présente un ensemble de bonnes pratiques pour les tests eux-mêmes, pour éviter (entre autres) que le coût de maintenance des tests ne dépasse le gain procuré par leur existence.

Enfin, la dernière partie du livre se place à un niveau au-dessus, et présente les différents points à garder à l'esprit lors de l'introduction des tests unitaires au niveau d'une organisation et plus particulièrement dans un projet déjà existant, ce qui peut représenter une bonne partie des cas lorsque l'on introduit les tests au sein d'une équipe ou d'un ensemble de projets.

Ma plus grande crainte avec ce livre était que, Roy Osherove travaillant pour TypeMock, il parle surtout des outils commerciaux de TypeMock (Isolator, Ivonna et compagnie). En fait, ces outils ne sont que très peu mentionnés dans cet ouvrage, qui se concentre sur les "standards" que sont NUnit et Rhino Mocks.

L'un dans l'autre, ce livre est probablement la meilleure introduction aux tests unitaires que j'ai jamais lue, et devrait, à mon avis, être une lecture obligatoire pour toute équipe décidant de commencer à utiliser les tests unitaires. En tout cas, personnellement, c'est le livre que j'aurais aimé avoir il y a deux ans, quand j'ai commencé à écrire des tests.

Cela dit, ce livre requiert une certaine expérience du développement avec le framework.NET pour l'apprécier correctement, je le conseillerais donc à des personnes ayant au moins 2 ou 3 projets derrière eux.

English version

It is no longer needed to discuss the need for unit tests. Indeed, this technique becomes increasingly widespread in the computer world, whatever the language, and, when those tests are well crafted, they can significantly improve the quality of software, while facilitating the maintenance of the product. Unit tests can detect any new bug introduced in the product, and can therefore avoid regressions in the code.

The question that often remains unresolved is how to produce "good" unit tests. The literature contains a large number of books discussing methods (Agile, XP, Scrum), but there was no (in any case, for. NET) book explaining clearly how to produce some quality unit tests. That is the goal of The Art Of Unit Testing .

The book begins with an introduction to NUnit, and a set of definitions. It then moves quickly enough to a bit of practice with a first unit test.

The next section develops the concept of mock and stubs, and discusses in depth the Rhino Mocks framework. This part furthermore presents a set of good practices related to the use of this Framework, or any other isolation framework.

After discussing the building blocks of unit tests, the third part presents a set of good practice for the tests themselves, to avoid (among other issues) that the maintenance cost of the tests exceeds the advantage gained by their existence.

The last part of the book is looking at a level above, and presents the different points to keep in mind when introducing unit tests in an organization and especially in an existing project, which can represent a large proportion of cases when introducing unit testing in a team or project.

My biggest apprehension with this book was that, with Roy Osherove working for TypeMock, he would speak mostly of the commercial tools develpped by TypeMock (Isolator, Ivonna and co.). In fact, these tools are only marginally mentioned in this book, which focuses on 'standards' such as NUnit and Rhino Mocks.

All in all, this book is probably the best introduction to unit tests I've ever read, and should, in my opinion, be required reading for any team or person decided to start unit tests. In any case, personally, this is the book that I would have loved to have two years ago, when I started writing tests.

That said, this book requires some development experience with the .NET framework to appreciate it properly, therefore I recommend it to people having at least 2 or 3 projects behind them.

Sommaire

Part 1 Getting started

  • 1 The basics of unit testing
  • 2 A first unit test

Part 2 Core techniques

  • 3 Using stubs to break dependencies
  • 4 Interaction testing using mock objects
  • 5 Isolation (mock object) frameworks

Part 3 The test code

  • 6 Test hierarchies and organization
  • 7 The pillars of good tests

Part 4 Design and process

  • 8 Integrating unit testing into the organization
  • 9 Working with legacy code

320 pages, 1 édition, 28/03/2009 Editions Manning, ISBN10 : 1933988274, ISBN13 : 9781933988274, Broché, 898 x 94 x 748
Commandez sur www.manning.com : 39.99  $

Commandez sur www.amazon.fr :
28.57 EUR TTC (prix éditeur 28.16 EUR TTC) - Livraison Gratuite !
couverture du livre 'The Art of Application Performance Testing'

Note 4.5

The Art of Application Performance Testing

Help for Programmers and Quality Assurance

de Ian Molyneaux

Résumé de l'éditeur

The Art of Application Performance Testing provides a step-by-step approach to testing mission-critical applications for scalability and performance before they're deployed -- a critical topic to which other books devote, at most, one chapter. With it, you'll learn the complete life cycle of the testing process, along with best practices to help you plan, gain approval for, coordinate, and conduct performance tests on your applications.


Critique du livre par la rédaction (Matthieu Brucher) (07/2009)
Le livre sur les performances des applications réseau est découpé en 5 chapitres, sur un peu plus de 150 pages.

Le premier chapitre définit les raisons des tests de performance. Malheureusement, ceux-ci sont bien souvent exécutés trop tard ou mal exécutés. C'est l'objectif du livre de présenter les bonnes pratiques.

Le second chapitre est pour le moins imposant puisqu'il occupe la moitié du livre. Il s'agit du coeur du test de performance : que tester ? comment tester ? quels outils sélectionner et sur quels critères ? La présentation est claire, précise et va au but.

Les trois derniers chapitres reprennent les éléments du deuxième chapitre. Tout d'abord, il faut amener la nécessité d'effectuer ces tests de performance, et deux exemples sont donnés, avec toutes les étapes. Il s'agit par la suite d'analyser les résultats, comment récupérer la cause du manque de performance, ... Le dernier chapitre recense quelques technologies qui peuvent impacter les performances.

En définitive, un très bon livre sur les tests de performance des applications réseaux. En plus, il a été imprimé sur du papier recyclable.

158 pages, 1ère édition, Février 2009 Editions O'Reilly, ISBN10 : 0596520662, ISBN13 : 978-0596520663
Commandez sur www.amazon.fr :
25,12 EUR TTC (prix éditeur 27,87 EUR TTC) - Livraison Gratuite !
couverture du livre 'Visualizing Data'

Note 3.5

Visualizing Data

Exploring and Explaining Data with the Processing Environment

de Ben Fry
Public visé : débutant

Résumé de l'éditeur

Enormous quantities of data go unused or underused today, simply because people can't visualize the quantities and relationships in it. Using a downloadable programming environment developed by the author, Visualizing Data demonstrates methods for representing data accurately on the Web and elsewhere, complete with user interaction, animation, and more. How do the 3.1 billion A, C, G and T letters of the human genome compare to those of a chimp or a mouse? What do the paths that millions of visitors take through a web site look like? With Visualizing Data, you learn how to answer complex questions like these with thoroughly interactive displays. We're not talking about cookie-cutter charts and graphs. This book teaches you how to design entire interfaces around large, complex data sets with the help of a powerful new design and prototyping tool called "Processing." Used by many researchers and companies to convey specific data in a clear and understandable manner, the Processing beta is available free. With this tool and Visualizing Data as a guide, you'll learn basic visualization principles, how to choose the right kind of display for your purposes, and how to provide interactive features that will bring users to your site over and over. This book teaches you: The seven stages of visualizing data -- acquire, parse, filter, mine, represent, refine, and interact How all data problems begin with a question and end with a narrative construct that provides a clear answer without extraneous details Several example projects with the code to make them work Positive and negative points of each representation discussed. The focus is on customization so that each one best suits what you want toconvey about your data set The book does not provide ready-made "visualizations" that can be plugged into any data set. Instead, with chapters divided by types of data rather than types of display, you'll learn how each visualization conveys the unique properties of the data it represents -- why the data was collected, what's interesting about it, and what stories it can tell. Visualizing Data teaches you how to answer questions, not simply display information.


Critique du livre par la rédaction (hiko-seijuro)
Visualizing Data est un livre dont l'objectif est d'introduire au lecteur les techniques de visualisations de données. Pour cela, l'auteur se base sur 7 étapes fondamentales qui seront introduites dès le premier chapitre. A chaque introduction d'un nouveau type de données, ou d'un nouveau concept à modéliser, ces étapes seront précisées. Cela permet au lecteur de savoir à quel niveau de la méthode il se situe et donc de pouvoir se référer à la partie du premier chapitre si nécessaire. Je trouve cela plutôt judicieux.

Pour ma part, je dirais que livre se découpe en 3 parties principales: introduction de la méthode (et du langage utilisé), types de donnée/types d'affichage et enfin traitement des données en vue d'un affichage plus approprié.

La première partie présente les 7 étapes de la méthode et le langage utilisé. Il s'agit d'un dialecte Java développé par l'auteur afin de faciliter la visualisation, nommé "processing". Dès cette première partie, le principal défaut de l'ouvrage est présent : l'auteur ne va pas au bout des choses. La méthode est néanmoins présentée de manière compréhensible et claire grâce à l'utilisation d'un exemple extrêmement simple. Et il s'agit ici de l'atout principal du livre : il est riche en exemples.

La seconde partie liste simplement des exemples pour les différents types de donnée. Je pense qu'il aurait été judicieux de rajouter des exemples un peu plus "tordus" afin de montrer comment quelquechose de complexe, une fois bien analysé, peut se représenter de manière extrêment simple. Les exemples, en revanche, couvrent presque tous les domaines et donnent toutes les bases. Par contre, vous risquez d'avoir besoin de complément pour certains problèmes plus spécifiques (toujours le même défaut !).

La dernière partie aurait pu être la plus intéressante, car elle présente comment traiter les données, si elle n'avait pas été si pauvre. Encore une fois, seules les bases d'acquisition et de traitement des données sont présentées. Il faut néammoins laisser à la charge de l'auteur qu'un approfondissement de cette partie revient à écrire un livre traitant de la fouille de données!

En conclusion, je soutiens que le livre est intéressant mais ne présente en réalité qu'un ensemble d'exemples et n'approfondit pas les choses. Il aurait été vraiment intéressant d'aller plus loin, beaucoup plus loin... Ce livre se révèle une excellente acquisition, si il est couplé avec un livre traitant des fouilles et de l'acquisition des données.

Sommaire

  • The seven stages of visualizing data
  • Getting started with processing
  • Mapping
  • Time series
  • Connections and correlations
  • Scatterplot maps
  • Trees, hierarchies and recursion
  • Networks and graphs
  • Acquiring data
  • Parsing data
  • Integrating processing with java

382 pages, 1ère édition, 11 Janvier 2008 Editions O'Reilly UK, ISBN10 : 0596514557, ISBN13 : 9780596514556
Commandez sur www.amazon.fr :
28,83 EUR TTC (prix éditeur 31,85 EUR TTC) - Livraison Gratuite !
couverture du livre 'Becoming Agile'

Note 5.0

Becoming Agile

in an imperfect world

de Greg Smith, Ahmed Sidky
Public visé : Débutant, Intermédiaire

Résumé de l'éditeur

Agile principles have been a breath of fresh air to many development teams stuck in the middle of a rigid, process-driven environment. Unfortunately, it's not easy to bring Agile into an existing organization with established people and practices. Becoming Agile shows you practical techniques and strategies to move from your existing process to an Agile process without starting from scratch.

Many books discuss Agile from a theoretical or academic perspective. Becoming Agile takes a different approach and focuses on explaining Agile from a ground-level point-of-view. Author Greg Smith, a certified ScrumMaster with dozens of Agile projects under his belt, presents Agile principles in the context of a case study that flows throughout the book.

Becoming Agile focuses on the importance of adapting Agile principles to the realities of your environment. While Agile purists have often discouraged a "partial-Agile" approach, the reality is that in many shops a "purist" approach simply isn't a viable option. Over the last few years, Agile authorities have begun to discover that the best deployments of Agile are often customized to the specific situation of a given company.

As well, Becoming Agile addresses the cultural realities of deploying Agile and how to deal with the needs of executives, managers, and the development team during migration. The author discusses employee motivation and establishing incentive that reward support of Agile techniques.

Becoming Agile will show you how to create a custom Agile process that supports the realities of you environment. The process will minimize risk as you transition to Agile iteratively, allowing time for your culture and processes to acclimate to Agile principles.


Critique du livre par la rédaction (Eric Siber) (30/05/2009)
Dans la préface, Mary Poppendieck annonce la couleur : l'agilité ce n'est pas qu'un truc de développeur, ce n'est pas une recette miracle à appliquer de manière normalisée sans tenir compte de la culture d'entreprise et de ses acteurs.
Pour autant, il est rappelé qu'il y a un noyau dur indispensable à la mise en oeuvre d'un environnement agile, résumé par le manifeste agile.

Voilà ce que les auteurs tentent de couvrir dans cet ouvrage, tout en pratique et regorgeant de conseils pour vous aider à mettre en place "un" processus agile adapté à votre entreprise/project.
Becoming Agile n'est pas un autre livre à classer dans la pile des livres traitant des méthodologies agiles, il s'agit d'un des rares ouvrages qui va vous accompagner dans l'adoption et la mise en place / transition vers un processus agile.
Par conséquent, ne vous attendez pas à un contenu exhaustif sur des pratiques agiles précises (TDD, intégration continue, etc.) : d'autres ouvrages en abondance le font déjà très bien.

Au programme de cet accompagnement :
- des conseils et outils pour analyser l'environnement de départ
- accompagnement à la composition du processus agile adapté, et migration sans remise en cause de l'ensemble de l'existant

Après avoir introduit la pensée agile et l'avoir projetée sur les différentes dimensions économiques et stratégiques d'une entreprise, les auteurs introduisent l'étude de cas d'un projet pilote qui nous accompagne tout au long de l'ouvrage à travers 9 étapes d'adoption d'un processus agile.

Le livre se présente certes comme théorique, crainte largement atténuée par la présence de l'étude de cas qui se lit très facilement, comme une histoire.
De plus, les auteurs n'en oublient pas d'introduire un certain nombre d'outils, en particulier un guide méthodologique complet pour évaluer votre potentiel à faire la transition vers un processus agile (pour en savoir plus : en http://www.dragile.com/).
On mentionnera notamment la Tradeoff Matrix (laquelle illustre bien l'importance d'identifier et hiérarchiser les contraintes pour n'en avoir qu'une seule qui guidera l'organisation de projet), les Feature Cards (et leurs équivalents informatisés pouvant par exemple être mises en oeuvres avec des outils comme SharePoint, VersionOne, ou Rally), le Planning Poker (pour en savoir plus : en http://www.planningpoker.com/, le Burndown Chart, ainsi que la Progress Matrix.
On n'oubliera bien sur pas l'équivalent "CMMI" pour les pratiques agiles : le SAMI (Sidky Agile Measurement Index), une initiative de l'un des auteurs.

Cet ouvrage traite à la fois la problématique d'un point de vue organisationnel et d'un point de vue pratique.
Ainsi tout en alimentant la réflexion sur la difficulté dans une entreprise à faire adopter les pratiques agiles (les auteurs soulignent notamment un gouffre entre la population d'Early Adopters et celle d'Early Majority), ils proposent des solutions et une méthodologie (à commencer par exemple par analyser son "potentiel" et se tester via un projet pilote).
Ce véritable Must Have, bible de l'agiliste, se lit très bien et vous accompagnera dans votre transition vers des pratiques agiles, mais bien au delà dans votre quotidien.

English version :

In the foreword, Mary Poppendieck declare trumps: agility is not only a developers thing, it's not a magical recipe to apply in a normalization manner without taking into consideration enterprise and people's culture and knowledges.
Despite that, it's reminded that a fixed core is essential to the setup of an agile environment, summarized by the agile manifesto.

That's exactly what the authors try to cover in this book, very concrete and holding a lot of recommendations to help you setup "an" agile process which fits to your enterprise/project.
Becoming Agile is not another book to be classified in the existing ones handling agile practices, it's one of the rare writings which will go with you in the adoption and setup / migration to an agile process.
As a consequence, don't expect an exhaustive content on some particular agile practices (TDD, continuous integration, etc.) : plenty existing books already handle these topics very well.

What can you find ?
- some advices and tools to analyse your current situation
- a companion guide to build your dedicated agile process, and migration without fully challenging your legacy

After having introduced the agile thinking and projected on different economic and strategic angles a company has, the authors introduce the study case of a pilot project which will help to illustrate the talk all along the book during 9 steps of agile process adoption.

Although the book appears as theoretical, this fear is widely attenuated thanks to this study case which can be read very easily, like a story.
Moreover, the authors don't forgent to introduce a few tools, in particular a complete methodological guide to evaluate your potential to do the transition to an agile process (for more information: en http://www.dragile.com/).
We can also mention the Tradeoff Matrix (which illustrate well the necessity to identify and put an order on the constraints, so that only one will define the guidelines of your project organisation when you will face some hazards), the Feature Cards (and their computerized counterpart which would be manageable thanks to tools like SharePoint, VersionOne, or Rally), the Planning Poker (for more information : en http://www.planningpoker.com/, the Burndown Chart, and also the Progress Matrix.
By the way, I'm not forgetting the "CMMI" like model built for agile practices: the SAMI (Sidky Agile Measurement Index), an initiative of one of the authors.

This publication handles at once the problematic from an organisational point of view and from a practical one.
Thereby, while bringing some input to the reflection on difficulites in companies to have people adopt agile practices (the authors emphasize a chasm between the Early Adopters and the Early Majority), they suggest some solutions and a methodology (which begin by an analysis of a one's "potential" and a first contact through a pilot project).
This real Must Have, agilist's bedside book, reads very well and will companion you in your migration to agile practices, but well beyond in your daily working (or not only) life.

Sommaire

  • Part 1: Agile fundamentals and a supporting case study
    • Chapter 1 Moving to agile
    • Chapter 2 The story of Acme Media
  • Part 2: Getting started
    • Chapter 3 Are you ready for agile ?
    • Chapter 4 The fitness test: all about readiness assessments
    • Chapter 5 The importance of obtaining executive support
    • Chapter 6 Improving buy-in by creating a core team
    • Chapter 7 The mindset of an agile leader
    • Chapter 8 Injecting agility into your current process
    • Chapter 9 Selecting a pilot project
  • Part 3: Kicking off
    • Chapter 10 Feasibility: is this project viable?
    • Chapter 11 Aligning the pilot team with the project
  • Part 4: Populating the product backlog
    • Chapter 12 Feature cards: a tool for "just enough" planning
    • Chapter 13 Prioritizing the backlog
    • Chapter 14 Estimating at the right level with the right people
  • Part 5: Enough information for scheduling
    • Chapter 15 Release planning: envisioning the overall schedule
    • Chapter 16 Iteration planning: the nitty-gritty details
  • Part 6: Building the product
    • Chapter 17 Start your engines: iteration 0
    • Chapter 18 Delivering working software
    • Chapter 19 Testing: did you do it right?
  • Part 7: Embracing change
    • Chapter 20 Adapting: reacting positively to change
    • Chapter 21 Delivery: bringing it all together
    • Chapter 22 The restrospective: working together to improve
  • Part 8: Moving forward
    • Chapter 23 Extending the new process across your company
  • Appendix
    • appendix A: Readiness assessment tables by practice
    • appendix B: Agile concepts from a phase perspective
    • appendix C: Agile process overview in text
    • appendix D: Example: determining process and document needs for a project
    • appendix E: Quantitative feedback on the SAMI

410 pages, 1ère édition, Mai 2009 Editions Manning, ISBN10 : 1933988258, ISBN13 : 978-1933988252
Commandez sur www.manning.com : 44.99  $
Version PDF à $27.50

Livre non disponible neuf sur Amazon.fr ! Achetez d'occasion sur www.amazon.fr
couverture du livre 'SOA Security'

Note 4.0

SOA Security

de Ramarao Kanneganti
Public visé : Intermédiaires / Expérimentés

Résumé de l'éditeur

Anyone seeking to implement SOA Security is forced to dig through a maze of inter-dependent specifications and API docs that assume a lot of prior security knowledge on the part of readers. Getting started on a project is proving to be a huge challenge to practitioners. This book seeks to change that. It provides a bottom-up understanding of security techniques appropriate for use in SOA without assuming any prior familiarity with security topics.

Unlike most other books about SOA that merely describe the standards, this book helps readers learn through action, by walking them through sample code that illustrates how real life problems can be solved using the techniques and best practices described in the standards. It simplifies things: where standards usually discuss many possible variations of each security technique, this book focuses on the 20% of variations that are used 80% of the time. This keeps the material covered useful for all readers except the most advanced.

This book shows you

  • Why SOA Security is different from ordinary computer security, with real life examples from popular domains such as finance, logistics, and Government
  • How things work with open source tools and code examples as well as proprietary tools.
  • How to implement and architect security in enterprises that use SOA. Covers WS-Security, XML Encryption, XML Signatures, and SAML.
Critique du livre par la rédaction (Gildas Cuisinier) (02/2009)
SOA et Sécurité, deux termes très présents et très importants dans le développement en entreprise.
Le titre est donc très prometteur. Mais les auteurs réduisent tout de suite la portée du livre dans l'introduction.

En effet, ce livre n'explique pas l'architecture et les concepts SOA et n'expose pas toutes les notions de sécurité non plus. Le livre portant sur l'intersection de ces deux domaines, une connaissance minimale des deux sujets était nécessaire pour commencer, ce livre s'adresse donc à un public initié, mais sans pour autant expert.
Cela dit, le livre est tout de même bien ficelé et intéressant. Il est composé de trois parties.

La première consiste en un rappel des bases de la SOA et de la sécurité par WebService : SOAP, SOAP Header, WS-Security.

La seconde partie présente les concepts de sécurité : authentification, autorisation, chiffrement,… Cette section est particulièrement intéressante. Elle présente diverses pratiques (utilisateur/mot de passe, Kerberos, PKI ) tout en décrivant leurs avantages et inconvénients.

La dernière partie est légèrement plus complexe et traite réellement de la sécurité orientée service. Encore une fois, les différentes implémentations d'un service de sécurité sont présentées ainsi que les technologies utilisées dans ce but (SAML, WS-Trust, … )

A la fin de la lecture, on a acquis bon nombre d'informations, mais il subsiste toutefois une impression d'insuffisance sur le sujet. Mais encore une fois, c'est volontaire. Au vu de la complexité des sujets, seules les bases sont présentées mais une multitude de liens sont fournis pour ceux qui désirent approfondir un sujet précis.

Au niveau des exemples, une implémentation basée sur Axis est fourni en fin de chapitre. C'est sans doute le seul bémol, Axis étant un peu vieillissant. Cependant, les exemples sont suffisamment explicites pour être adaptables facilement avec n'importe quel autre framework.

Ce livre est donc plus qu'intéressant, même si le titre " Introduction to SOA Security " aurait été plus représentatif.

English version :

SOA and security, two terms very present and important in the enterprise development.
Due to this and its title, this book sounds very promising. However, the authors reduce immediately the scope of the book in the introduction.

Indeed, the book is not intended to explain the SOA architecture and concepts, neither all the security notions.
The book is about the intersection of the two subjects and so a minimal knowledge of these is necessary. The book is aimed at an initiated public, but not an expert one.

However, the book is well put together and interesting. It is composed of three parts.

The first is a reminder of the basics of SOA and WebService security : SOAP Header SOAP, WS-Security.

The second part presents the concepts of security: authentication, authorization, encryption, ... This section is particularly interesting. It introduces various practices (user / password, Kerberos, PKI), while describing their advantages and disadvantages.

The last part is a little more complex and deals with real security-oriented service. Again, the different implementations of a security service are shown together with the technologies used for this purpose (SAML, WS-Trust, ...)

At the end of the reading, we have learnt lots of information, however there is still a feeling of weakness on the subject. But once again, it's voluntary. Given the complexity of the issues, only the fundamentals are presented, but many links are provided for those who wish to deepen a specific topic.

In terms of examples, an implementation based on Axis is provided at the end of the chapter. This is probably the only regret I have : Axis is a little old. However, the examples are explicit enough to be easily adapted with any other framework.

This book is more than interesting, even if the title "Introduction to SOA Security" would have been more representative.

Sommaire

  • Part 1: SOA basics
    • Chapter 1 SOA requires new approaches to security
    • Chapter 2 Getting started with web services
    • Chapter 3 Extending SOAP for security
  • Part 2: Building blocks of SOA security
    • Chapter 4 Claiming and verifying identity with passwords
    • Chapter 5 Secure authentication with Kerberos
    • Chapter 6 Protecting confidentiality of messages using encryption
    • Chapter 7 Using digital signatures
  • Part 3: Enterprise SOA security
    • Chapter 8 Implementing security as a service
    • Chapter 9 Codifying security policies
    • Chapter 10 Designing SOA security for a real-world enterprise
  • Appendix
    • appendix A: Limitations of Apache Axis
    • appendix B: WS-SecureConversation
    • appendix C: Attaching and securing binary data in SOAP
    • appendix D: Securing SAML assertions
    • appendix E: Application-Oriented Networking (AON)

500 pages, 1ère édition, Juin 2008 Editions Manning, ISBN10 : 1932394680, ISBN13 : 978-1932394689
Commandez sur www.manning.com : 59.99  $

Commandez sur www.amazon.fr :
46,53 EUR TTC (prix éditeur EUR TTC) - Livraison Gratuite !
couverture du livre 'The Productive Programmer'

Note 4.0

The Productive Programmer

de Neal Ford

Résumé de l'éditeur

Anyone who develops software for a living needs a proven way to produce it better, faster, and cheaper. The Productive Programmer offers critical timesaving and productivity tools that you can adopt right away, no matter what platform you use. Master developer Neal Ford not only offers advice on the mechanics of productivity-how to work smarter, spurn interruptions, get the most out your computer, and avoid repetition-he also details valuable practices that will help you elude common traps, improve your code, and become more valuable to your team. You'll learn to: Write the test before you write the code Manage the lifecycle of your objects fastidiously Build only what you need now, not what you might need later Apply ancient philosophies to software development Question authority, rather than blindly adhere to standards Make hard things easier and impossible things possible through meta-programming Be sure all code within a method is at the same level of abstraction Pick the right editor and assemble the best tools for the job

This isn't theory, but the fruits of Ford's real-world experience as an Application Architect at the global IT consultancy ThoughtWorks. Whether you're a beginner or a pro with years of experience, you'll improve your work and your career with the simple and straightforward principles in The Productive Programmer.

Critique du livre par la rédaction (Eric Siber) (janvier 2009)
Cet ouvrage est un véritable recueil de bonnes pratiques pour les programmeurs et toute personne souhaitant augmenter sa productivité avec les outils informatiques.
Neal Ford, architecte chez ThoughtWorks et membre du fameux en http://www.nofluffjuststuff.com, nous livre toute sa boîte à outils et prodigue des précieux conseils.

L'ouvrage commence avec un ensemble de chapitres dédié à la productivité sur le poste de travail, ceci donc indépendamment de tout outil ou langage/plateforme spécifique de développement.
C'est en fait la partie que j'ai le plus apprécié, dévorant les premiers chapitres sans retenue : Windows, Linux, Mac, aucun des 3 OS majeurs n'est oublié.
Ils contiennent de nombreux conseils pleins de sens illustrés par des utilitaires permettant de les mettre en oeuvre (raccourcis, navigation, outils d'indexation et de recherche, macros, DRY et conventions, etc.), et surtout une recommandation majeure : lorsqu'on sent qu'on passe son temps à répéter une succession d'opérations ou commandes, il est temps de réfléchir à une optimisation (que cela passe par de l'automatisation ou non), encore plus si on se refuse à le faire par soi disant manque de temps !

Après le chapitre 5 qui est en quelque sorte un chapitre de transition, l'ouvrage prend une tournure beaucoup plus orientée développement avec comme principal langage sous-jacent Java (mais aussi Groovy, Ruby).
L'auteur s'intéresse notamment au TDD (Développement dirigé par les tests), aux outils de qualimétrie (couverture de code, complexité cyclomatique) et illustre de bonnes pratiques de programmation orientée objet.
Comme dans toute approche de développement Agile, l'auteur insiste sur la réduction de complexité et l'utilisation de code simple, avec une utilisation parcimonieuse de frameworks (il témoigne néanmoins de par sa propre expérience des limites d'une approche zéro framework).

Les chapitres (courts le plus souvent) s'enchaînent et introduisent à chaque fois un nouveau concept, généreusement illustré par du code, ce qui rend la lecture aisée.
On notera en particulier le chapitre 14 insistant sur la nécessité d'oser se détacher de son langage de prédilection pour faire le choix du langage approprié pour une tâche / un fragment d'application précis. En effet, il est de nos jours établi que les langages de script améliorent la productivité et peuvent être employés dans certaines parties d'une application (on pensera notamment aux DSLs) et en interaction avec des langages de plus haut niveau (comme Groovy avec Java), mais également pour réaliser rapidement de petits utilitaires comme souvent on peut en avoir besoin (migration, statistiques, etc.).

Vient ensuite un chapitre très intéressant dans lequel l'auteur nous expose un cahier des charges de l'outil parfait, en mettant notamment à l'épreuve VI, Emacs, JEdit et TextMate.

En résumé, c'est un excellent livre qui regorge de bons conseils. J'aurais pu lui mettre cinq étoiles mais je suis un peu resté sur ma faim dans la seconde partie du livre, mais cela n'enlève en rien la qualité des informations condensée dans les 200 pages du livre.
Je ne peux que vous recommander d'aller visiter le en site de l'auteur ainsi que le en Wiki dédié au livre.

Sommaire

  • Introduction
  • Mechanics
    • Acceleration
    • Focus
    • Automation
    • Canonicality
  • Practice
    • Test-driven design
    • Static analysis
    • Good citizenship
    • Yagni
    • Ancient philosophers
    • Question authority
    • Meta-programming
    • Composed method and slap
    • Polyglot programming
    • Find the perfect tools
    • Conclusion: carrying on the conversation

222 pages, 1ère édition, juillet 2008 Editions O'Reilly, ISBN10 : 0596519788, ISBN13 : 978-0596519780
Commandez sur www.amazon.fr :
31,07 EUR TTC (prix éditeur 32 EUR TTC) - Livraison Gratuite !
couverture du livre 'The Art of Agile Development'

Note 4.0

The Art of Agile Development

de James Shore, Shane Warden
Public visé : Débutant, Intermédiaire

Résumé de l'éditeur

The Art of Agile Development contains practical guidance for anyone considering or applying agile development for building valuable software. Plenty of books describe what agile development is or why it helps software projects succeed, but very few combine information for developers, managers, testers, and customers into a single package that they can apply directly.

This book provides no-nonsense advice on agile planning, development, delivery, and management taken from the authors' many years of experience with Extreme Programming (XP). You get a gestalt view of the agile development process, including comprehensive guidance for non-technical readers and hands-on technical practices for developers and testers

The Art of Agile Development gives you clear answers to questions such as:

  • How can we adopt agile development?
  • Do we really need to pair program?
  • What metrics should we report?
  • What if I can't get my customer to participate?
  • How much documentation should we write?
  • When do we design and architect?
  • As a non-developer, how should I work with my agile team?
  • Where is my product roadmap?
  • How does QA fit in?
The book teaches you how to adopt XP practices, describes each practice in detail, then discusses principles that will allow you to modify XP and create your own agile method. In particular, this book tackles the difficult aspects of agile development: the need for cooperation and trust among team members.

Whether you're currently part of an agile team, working with an agile team, or interested in agile development, this book provides the practical tips you need to start practicing agile development. As your experience grows, the book will grow with you, providing exercises and information that will teach you first to understand the rules of agile development, break them, and ultimately abandon rules altogether as you master the art of agile development.

Critique du livre par la rédaction (Gildas CUISINIER (hikage))
Si tout comme moi, vous ne connaissez les méthodes agiles que de nom, ce livre est pour vous. Il est très clair, agréable à lire et honnête.
Au fur et à mesure que l'on avance dans la lecture, on sent que les auteurs ont une expérience certaine des méthodes agiles. Ils proposent des moyens qu'ils ont mis en pratique, ils ne cachent pas les risques, et posent même des conditions pour que cela fonctionne.

Pratiquement, ce livre est composée de trois partie :

La première est une présentation des méthodes agiles, sous une forme très intéressante. En effet, au lieu de faire du bourrage de crâne sur des concepts théoriques, les auteurs présentent l'Extreme Programming par le biais de l'intégration d'un nouveau arrivant dans une équipe agile.
L'équipe nous est présentée petit à petit, au fur et à mesure des rencontres que ce nouvel arrivant fait. Le chef d'équipe lui présentant le rôle de chacun, tout en lui laissant la possibilité de poser des questions.
Le genre de question qu'un non initié se poserait réellement.

La seconde partie présente plus en détail les pratiques des méthodes agiles ( Programmation en binôme, Integration continue, Client sur site, .. ). Les auteurs présentent encore une fois des exemples basés sur leur expérience.
Ils présentent aussi les conditions pour que cela marche, et des alternatives si ces conditions ne sont pas réunies.
De plus, chaque pratique ne s'adresse pas à tout les membres de l'équipe, ils ciblent les rôles intéressés en début de chapitre. Et comme une pratique est souvent en relation avec d'autres, dès que c'est le cas, les auteurs proposent un renvoi vers celles-ci.

La dernière partie est un peu plus poussée, et propose les valeurs sur lesquelles se basent les méthodes agiles.

C'est pour moi, un excellent ouvrage, et en tout cas, il m'a convaincu sur les méthodes agiles, et m'a donné l'envie d'essayer.

Sommaire

  • Part I : Getting Started
    • Chapter 1: Why Agile?
    • Chapter 2: How to Be Agile
    • Chapter 3: Understanding XP
    • Chapter 4: Adopting XP
  • Part II : Practicing XP
    • Chapter 5: Thinking
    • Chapter 6: Collaborating
    • Chapter 7: Releasing
    • Chapter 8: Planning
    • Chapter 9: Developing
  • Part III : Mastering Agility
    • Chapter 10: Values and Principles
    • Chapter 11: Improve the Process
    • Chapter 12: Rely on People

430 pages, 1ere édition, Octobre 2007 Editions O'Reilly, ISBN10 : 0596527675, Broché
Commandez sur www.amazon.fr :
28,60 EUR TTC (prix éditeur 28,60 EUR TTC) - Livraison Gratuite !
couverture du livre 'Test-Driven Development'

Note 4.5

Test-Driven Development

By Example

de Kent Beck
Public visé : Intermédiaire

Résumé de l'éditeur

Du code propre qui fonctionne - tout de suite. Ceci est apparemment une contradiction responsable de beaucoup de souffrances en programmation. Test-Driven Development, ou développement basé sur les tests, répond à cette contradiction par un paradoxe : testez le programme avant de l'écrire.

Une nouvelle idée ? Pas du tout. Depuis l'aube des calculs sur ordinateur, les programmeurs ont spécifié les entrées et les sorties de leur programme avant de l'écrire précisement. TDD reprend cette vieille idée, la mixe avec les langages modernes et les environnements de programmation et en fait un mets vous garantissant d'être rassasié de code clair qui fonctionne - tout de suite.

Les développeurs font tous les jours face à des défis, pourtant ils ne sont pas toujours préparés à trouver la meilleure solution. Le plus souvent, de grands projets génèrent beaucoup de stress et du mauvais code. Pour obtenir la force et le courage de surmonter cette tâche apparemment herculéenne, les programmeurs devrait regarder vers TDD, un jeu de techniques qui encourage les designs simples et les tests qui inspirent confiance.

En développant avec des tests automatiques puis en éliminant les doublons, chaque développeur peut écrire du code dans lequel on peut avoir confiance, sans bug quelque soit sa complexité. De plus, TDD encourage les programmeurs à apprendre rapidement, communiquer plus clairement et à obtenir un feedback constructif.

Les lecteurs apprendront à: Résoudre des tâches compliquées, commençant par la simplicité et continuant vers plus de complexité. Ecrire des tests automatiques avant de programmer Définir un design en refactorant pour ajouter des éléments petit à petit. Créer des tests pour de la logique plus complexe. Utiliser des patterns pour décider quels tests doivent être écrits. Créer des tests à l'aide d'xUnit, l'architecture au coeur de plusieurs outils de tests orientés vers les programmeurs.

Ce livre suit 2 projets à l'aide de TDD, du début à la fin, illustrant les techniques que les programmeurs peuvent utiliser pour améliorer facilement et de manière importante la qualité de leur travail. Les exemples sont suivis de références aux patterns TDD et au refactoring. Avec son accent sur les méthodes dites agiles et les stratégies de développement rapide, TDD encouragera les lecteurs à embrasser ces techniques sous-utilisées mais puissantes.

Critique du livre par la rédaction (Miles)
On parle Java dans tout le livre, mais chaque conseil est pour tous les langages. De plus, le framework a été porté pour fonctionner avec presque tous les langages. L'approche de Kent Beck est agréable et didactique. On construit vraiment au fur et à mesure, petit pas par petit pas. Le premier exemple est simple, gérer de l'argent dans différentes devises, et ce petit exemple nous mène déjà loin.

En fait, les exemples servent juste à bien nous asséner le principe de Beck, tester en construisant progressivement. Si on a compris qu'on doit toujours tout tester et qu'aucun code ne doit être buggé quand on arrête le travail, on a compris le livre. Ensuite, l'auteur nous donne des astuces, des patterns pour avancer, comme écrire des tests isolés, ne dépendant pas de toute l'architecture afin de ne pas déprimer - important... -, faire des raisonnements inductifs pour généraliser une réponse, ...

Depuis la lecture de ce livre, je me suis mis aux tests. J'avoue qu'avant, c'était la dernière de mes préoccupations. Maintenant, mon code est plus propre - on dirait une pub de lessive, là -, et surtout bardé de tests au cas où j'aurai une modification au niveau de l'architecture à faire - refactoring, et ça arrive souvent -. En même temps, je n'applique pas sa solution à 100%, c'est tout de même très difficile, ça demande du temps d'écrire le test avant d'avoir la solution qui va avec, mais on voit aussi comment on avance, c'est bien ;)

Sommaire

  • I. THE MONEY EXAMPLE.
    • 1. Multi-Currency Money.
    • 2. Degenerate Objects.
    • 3. Equality for All.
    • 4. Privacy.
    • 5. Franc-ly Speaking.
    • 6. Equality for All, Redux.
    • 7. Apples and Oranges.
    • 8. Makin' Objects.
    • 9. Times We're Livin' In.
    • 10. Interesting Times.
    • 11. The Root of All Evil.
    • 12. Addition, Finally.
    • 13. Make It.
    • 14. Change.
    • 15. Mixed Currencies.
    • 16. Abstraction, Finally.
    • 17. Money Retrospective.
  • II. The xUnit Example.
    • 18. First Steps to xUnit.
    • 19. Set the Table.
    • 20. Cleaning Up After.
    • 21. Counting.
    • 22. Dealing with Failure.
    • 23. How Suite It Is.
    • 24. xUnit Retrospective.
  • III. Patterns for Test-Driven Development.
    • 25. Test-Driven Development Patterns.
    • 26. Red Bar Patterns.
    • 27. Testing Patterns.
    • 28. Green Bar Patterns.
    • 29. xUnit Patterns.
    • 30. Design Patterns.
    • 31. Refactoring.
    • 32. Mastering TDD.
  • Appendix I: Influence Diagrams.
  • Appendix II: Fibonacci.

240 pages, 1 ère édition, novembre 2002 Editions Pearson Education, ISBN10 : 0321146530
Commandez sur www.amazon.fr :
22,77 EUR TTC (prix éditeur 22,77 EUR TTC) - Livraison Gratuite !
couverture du livre 'SOA In Practice'

Note 4.5

SOA In Practice

The art of Distributed System Design

de Nicolai M. Josuttis

Résumé de l'éditeur

This book demonstrates service-oriented architecture (SOA) as a concrete discipline rather than a hopeful collection of cloud charts. Built upon the author's firsthand experience rolling out a SOA at a major corporation, SOA in Practice explains how SOA can simplify the creation and maintenance of large-scale applications. Whether your project involves a large set of Web Services-based components, or connects legacy applications to modern business processes, this book clarifies how -- and whether -- SOA fits your needs.

SOA has been a vision for years. This book brings it down to earth by describing the real-world problems of implementing and running a SOA in practice. After defining SOA's many facets, examining typical use patterns, and exploring how loose coupling helps build stronger applications, SOA in Practice presents a framework to help you determine when to take advantage of SOA. In this book you will:

Focus squarely on real deployment and technology, not just standards maps

Examine business problems to determine which ones fit a SOA approach before plastering a SOA solution on top of them

Find clear paths for building solutions without getting trapped in the mire of changing web services details

Gain the experience of a systems analyst intimately involved with SOA

Critique du livre par la rédaction (Morgan Bourgeois) (04/2008)
Cet ouvrage a pour objectif de présenter l'ensemble des concepts des architectures orientées services (SOA) en se concentrant sur leurs aspects pratiques. La première constatation est que le livre est bien structuré. Après une présentation générale en quelques pages de SOA, puis ses concepts principaux il se concentre progressivement sur les différents concepts liés à ce type d'architecture. On notera également que l'auteur justifie d'une bonne maîtrise du sujet. .De nombreux exemples tirés de situations professionnelles viennent illustrer l'ensemble des pièges qu'il est possible de rencontrer à la mise en place d'une architecture SOA. L'auteur cherche ici à mettre en avant, pour chaque choix à effectuer, les différentes possibilités en mettant sur la balance les pour et les contres dans un souci constant de neutralité. L'auteur cherche ici à argumenter dans un souci constant de neutralité les avantages et les inconvénients de chaque architecture proposée.

S'il est vrai que cette neutralité nous évite de tomber dans les travers d'une solution présentée comme miracle, sans souci et capable de résoudre tous les maux, il reste cependant qu'au fil de la lecture, on finit parfois par ne plus savoir quel choix serait le plus judicieux dans une situation donnée. En ce sens, cet ouvrage ne peut être considéré comme un guide mais plutôt comme un panorama qui s'adressera essentiellement aux personnes souhaitant se familiariser avec SOA. Il accompagnera ceux qui, ayant jeté leur dévolu sur cette architecture, souhaitent avoir à l'esprit l'ensemble des pièges à éviter. Mais il ne pourra répondre aux attentent de ceux qui tentent de mettre en pratique certains aspects précis d'une architecture SOA. Le titre donné à cet ouvrage "SOA In practice » peut donc induire en erreur.

On pourra reprocher également aux chapitres 2 et 3 de s'appuyer sur l'évolution des définitions Wikipedia pour présenter les concepts de SOA. On regrettera également que, bien que l'auteur nous répète tout au long du livre que les Services Web ne sont pas l'unique moyen d'implémenter des services dans une architecture SOA, on termine l'ouvrage sans avoir une vision claire de ce à quoi peut ressembler un service non web dans SOA. Enfin, bien que l'auteur insiste tout au long du livre que les Services Web ne sont pas l'unique moyen d'implémenter des services dans une architecture SOA, on regrettera de ne pas avoir au final une vision claire de ce à quoi peut ressembler un service non web dans SOA.

Sommaire

  1. Motivation
  2. SOA
  3. SERVICES
  4. LOOSE COUPLING
  5. THE ENTERPRISE SERVICE BUS
  6. SERVICE CLASSIFICATION
  7. BUSINESS PROCESS MANAGEMENT
  8. SOA AND THE ORGANIZATION
  9. SOA IN CONTEXT
  10. MESSAGE EXCHANGE PATTERNS
  11. SERVICE LIFECYCLE
  12. VERSIONNING
  13. SOA AND PERFORMANCE
  14. SOA AND SECURITY
  15. TECHNICAL DETAILS
  16. WEB SERVICES
  17. SERVICE MANAGEMENT
  18. MODEL-DRIVEN SERVICE DEVELOPMENT
  19. ESTABLISHING SERVICE DEVELOPMENT
  20. ESTABLISHING SOA AND SOA GOVERNANCE
  21. EPILOGUE

324 pages, 1ère édition, 09/2007 Editions O'Reilly, ISBN10 : 0596529554, ISBN13 : 9780596529550
Commandez sur www.amazon.fr :
27,66 EUR TTC (prix éditeur EUR TTC) - Livraison Gratuite !
couverture du livre 'Design Patterns'

Note 3.5

Design Patterns

Elements of Reusable Object-Oriented Software

de Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Public visé : Avancé

Résumé de l'éditeur

Maintenant sur CD, the bestseller renommé internationallement a plus de valeur que jamais!

Utilisez le contenu de ce CD pour créer vos propres documents de design et vos composants réutilisables. Le CD contient 23 patterns que vous pouvez copier et coller dans vos propres documents de design, du code d'exemple démontrant l'implémentation du pattern, le contenu complet de Design Pattern au format HTML avec de nombreux liens hyper-textes croisés, accès grâce à un navigateur standard, mécanisme de recherche dynamique en Java, , environnement utilisateur graphique facilitant la navigation.

Publié en 1995, ce travail de fond sur le design de logiciel orienté objet présente un catalogue de solutions simples et succintes aux problèmes de design communs. Créés par 4 designers expérimentés, ces 23 patterns contenus dans ce livre sont devenus une ressource essentielle pour quiconque développe du logiel orienté objet réutilisable. En réponse à la demande des lecteurs, le texte complexe et le catalogue de pattern est maintenant disponible sur CD-ROM. Cette version électronique de Design Patterns permet aux programmeurs d'installer le livre sur un ordinateur ou un réseau pour une utilisation comme référence en ligne pour créer une logiciel orienté objet réutilisable.

Les auteurs décrivent dans un premier temps ce que sont les patterns et comment ils peuvent vous aider dans le processus de design. Par la suite, ils nomment, expliquent, évaluent et cataloguent systématiquement les designs récurrents dans les systèmes orientés objet. Chaque pattern est extrait d'exemple du monde réel et incluent du code qui montrent comment ils peuvent être implémentés dans des langages orientés objet tels C++ ou Smalltalk. Les lecteurs qui ont le livres choisiront le CD pour tirer parti de son mécanisme de recherche dynamique et des patterns prêt à l'installation.

Critique du livre par la rédaction (Miles)
Tout d'abord, je préfère les livres aux versions électroniques, c'est comme ça, c'est personnel, mais ça enlève beaucoup du charme - la version papier est plus difficle à trouver, pas dispo sur Amazon, par ex -. On est obligé d'être scotché à son ordinateur au lieu de pouvoir en profiter dans le train, ... Ensuite, c'est un catalogue de patterns, comme indiqué dans la description, donc on a le droit 23 fois à la même chose, dans le même ordre, juste le contenu qui change, c'est parfois un peu difficile à lire d'une traite, d'où le concept de catalogue !

Passé la première impression un peu limite, on se dit que c'est bien fait. 3 grandes parties pour classer les patterns les plus utilisés. En plus, on commence par un exemple concret où on utilise plusieurs de ces patterns. Enfin, on dit plutôt qu'on peut utiliser tel pattern pour faire ceci ou cela, c'est vrai que c'est pas la même chose. Mais pour celui qui n'a jamais entendu parler de pattern, c'est important de voir comment on peut les utiliser.

Chaque pattern est agrémenté d'un diagramme UML pour savoir comment ça se passe. Mais on est pas obligé de connaître l'UML, un rapide récapitulatif est aussi disponible sur cxe qui sera utilisé dans les diagrammes, ce qui fait que j'ai même compris ce qui se passait :) Un exemple d'implémentation est à chaque fois donné, en C++ et en SmallTalk, ça change du sempiternel Java. Y'a pas que ses programmeurs qui peuvent bénéficier des patterns... Et aussi une petite explication sur ce qu'on fait et comment, c'est bien aussi.

Avec un peu de recul, ce catalogue est bien. Il n'a pas vieilli, la preuve d'une qualité de son contenu, ces patterns sont toujours encore utilisables et à utiliser. D'autres existent aussi, les auteurs en sont bien concients, et c'est bien, ils ne considèrent pas avoir la science infuse. Donc pour conclure, c'est sans doute LA référence en terme de pattern, même si on aurait préféré une version papier.

Sommaire

  • 1. Introduction.
    • What Is a Design Pattern?
    • Design Patterns in Smalltalk MVC.
    • Describing Design Patterns.
    • The Catalog of Design Patterns.
    • Organizing the Catalog.
    • How Design Patterns Solve Design Problems.
    • How to Select a Design Pattern.
    • How to Use a Design Pattern.
  • 2. A Case Study: Designing a Document Editor.
    • Design Problems.
    • Document Structure.
    • Formatting.
    • Embellishing the User Interface.
    • Supporting Multiple Look-and-Feel Standards.
    • Supporting Multiple Window Systems.
    • User Operations.
    • Spelling Checking and Hyphenation.
    • Summary.
  • 3. Creational Patterns.
    • Abstract Factory.
    • Builder.
    • Factory Method.
    • Prototype.
    • Singleton.
    • Discussion of Creational Patterns.
  • 4. Structural Pattern.
    • Adapter.
    • Bridge.
    • Composite.
    • Decorator.
    • Facade.
    • Flyweight.
    • Proxy.
    • Discussion of Structural Patterns.
  • 5. Behavioral Patterns.
    • Chain of Responsibility.
    • Command.
    • Interpreter.
    • Iterator.
    • Mediator.
    • Memento.
    • Observer.
    • State.
    • Strategy.
    • Template Method.
    • Visitor.
    • Discussion of Behavioral Patterns.
  • 6. Conclusion.
    • What to Expect from Design Patterns.
    • A Brief History.
    • The Pattern Community.
    • An Invitation.
    • A Parting Thought.
  • Appendix A: Glossary.
  • Appendix B: Guide to Notation.
    • Class Diagram.
    • Object Diagram.
    • Interaction Diagram.
  • Appendix C: Foundation Classes.
    • List.
    • Iterator.
    • ListIterator.
    • Point.
    • Rect.

0 pages, 1 ère édition, juin 1997 Editions Addison-Wesley Professional, ISBN10 : 0201634988
Commandez sur www.amazon.fr :
39,83 EUR TTC (prix éditeur 39,83 EUR TTC) - Livraison Gratuite !
couverture du livre 'Refactoring to Patterns'

Note 4.5

Refactoring to Patterns

de Joshua Kerievsky
Public visé : Débutant, Intermédiaire

Résumé de l'éditeur

Ce livre traite du mariage du refactoring - le processus d'amélioration du design du code existant - avec des patterns, les solutions classiques aux problèmes récurrents de design. Refactoring to Patterns suggère que l'utilisation des patterns pour améliorer un design existant est meilleur que l'utilisation des patterns tôt dans un nouveau design. Ceci est vrai, que le code soit jeune ou vieux. Nous améliorons les designs avec des patterns en appliquant des séquences de transformations de design de bas niveau, aussi connu sous le nom de refactorings.

Critique du livre par la rédaction (Miles)
Une sorte de suite à Refactoring de Martin Fowler, puisque tous les processus décrits ou presque utilisent des patterns décrits dans ce livre. Les différentes catégories sont aussi bien séparées l'auteur n'oblige pas à aller jusqu'aux patterns décrits dans Design Patterns, on n'en a pas toujours besoin - vive les surpopulations de singletons par exemple -. Selon ce qu'on a à faire, plusieurs solutions sont utilisables, plus ou moins loin de ces patterns.

Le code proposé est du Java, il est parfois un peu difficile de faire le lien avec d'autres langages orientés objet offrant des outils différents. En revanche, pour chaque refactoring to pattern, un petit topo sur pourquoi et comment faire est proposé. Ces petites étapes permettent de s'en sortir. L'introduction du livre est très importante, par exemple, un accent y est mis sur l'élémentarité des étapes, simples de préférence.

Comme précisé ci-dessus, ce livre fait la part belle à Fowler, le livre fait aussi partie de la collection Fowler. Ensuite est-ce que c'est pour la signature Fowler qu'il y a autant de référence au livre Refactoring ? Non, ce dernier est une base, un fondement que Refactoring to Patterns utilise pour aller plus loin, plus vite. Ce que Refactoring ne pouvait aborder par manque de place, Refactoring to Patterns l'aborde et va au bout. Sans imposer, juste en proposant.

Sommaire

  • 1. Why I Wrote This Book.
    • Over-Engineering.
    • The Patterns Panacea.
    • Under-Engineering.
    • Test-Driven Development and Continuous Refactoring.
    • Refactoring and Patterns.
    • Evolutionary Design.
  • 2. Refactoring.
    • What Is Refactoring?
    • What Motivates Us to Refactor?
    • Many Eyes.
    • Human-Readable Code.
    • Keeping It Clean.
    • Small Steps.
    • Design Debt.
    • Evolving a New Architecture.
    • Composite and Test-Driven Refactorings.
    • The Benefits of Composite Refactorings.
    • Refactoring Tools.
  • 3. Patterns.
    • What Is a Pattern?
    • Patterns Happy.
    • There Are Many Ways to Implement a Pattern.
    • Refactoring to, towards, and away from Patterns.
    • Do Patterns Make Code More Complex?
    • Pattern Knowledge.
    • Up-Front Design with Patterns.
  • 4. Code Smells.
    • Duplicated Code.
    • Long Method.
    • Conditional Complexity.
    • Primitive Obsession.
    • Indecent Exposure.
    • Solution Sprawl.
    • Alternative Classes with Different Interfaces.
    • Lazy Class.
    • Large Class.
    • Switch Statements.
    • Combinatorial Explosion.
    • Oddball Solution.
  • 5. A Catalog of Refactorings to Patterns.
    • Format of the Refactorings.
    • Projects Referenced in This Catalog.
    • A Starting Point.
    • A Study Sequence.
  • 6. Creation.
    • Replace Constructors with Creation Methods.
    • Move Creation Knowledge to Factory.
    • Encapsulate Classes with Factory.
    • Introduce Polymorphic Creation with Factory Method.
    • Encapsulate Composite with Builder.
    • Inline Singleton.
  • 7. Simplification.
    • Compose Method.
    • Replace Conditional Logic with Strategy.
    • Move Embellishment to Decorator.
    • Replace State-Altering Conditionals with State 166
    • Replace Implicit Tree with Composite.
    • Replace Conditional Dispatcher with Command.
  • 8. Generalization.
    • Form Template Method.
    • Extract Composite.
    • Replace One/Many Distinctions with Composite.
    • Replace Hard-Coded Notifications with Observer.
    • Unify Interfaces with Adapter.
    • Extract Adapter.
    • Replace Implicit Language with Interpreter.
  • 9. Protection.
    • Replace Type Code with Class.
    • Limit Instantiation with Singleton.
  • 10. Accumulation.
    • Move Accumulation to Collecting Parameter.
    • Move Accumulation to Visitor.
  • 11. Utilities.
    • Chain Constructors.
    • Unify Interfaces.
    • Extract Parameter.

400 pages, 1 ère édition, août 2004 Editions Addison-Wesley Professional, ISBN10 : 0321213351
Commandez sur www.amazon.fr :
42,72 EUR TTC (prix éditeur 42,72 EUR TTC) - Livraison Gratuite !
couverture du livre 'Refactoring'

Note 4.5

Refactoring

Improving the Design of Existing Code

de Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Public visé : Débutant

Résumé de l'éditeur

Pendant que l'application de technologies objet - particulièrement dans le langage de programmation Java - devient courant, un nouveau problème est apparu dans la communauté du développement logiciel. Un nombre significatif de programmes mal designés ont été créés par des développeurs moins expérimentés, se traduisant par des applications qui sont inefficaces et difficiles à maintenir et à étendre. Les professionnels des systèmes logiciels découvrent de plus en plus la difficulté de travailler avec ces applications héritées, "non optimales". Pendant plusieurs années, les programmeurs objets d'un niveau d'expert ont employés une collection grandissante de techniques pour améliorer l'intégrité et la performance de ce genre de programmes existants. Connus sous le nom de "refactoring", ces pratiques sont restées dans le domaine des experts car aucune tentative avait été menée pour les transcrire dans une forme que tous les développeurs pouvaient utiliser... jusqu'à aujourd'hui. Dans Refactoring: Improving the Design of Existing Code, Martin Fowler, mentor renommé de la technologie objet ouvre une nouvelle voie, démystifiant ces pratiques avancées et démontrant comment les développeurs peuvent se rendre compte des bénéfices de ce nouveau processus.

Avec un entraînement adéquat, un designer aguerri de système peut prendre un mauvais design et le transformer en code robuste, bien designé. Dans ce livre, Martin Fowler nous montre où sont traditionnellement les opportunités pour le refactoring et comment passer d'un mauvais design à un bon. Chaque étape de refactoring est simple - apparemment trop simple pour mériter d'être effectuée. Refactorer peut impliquer déplacer un champ d'une classe à une autre, extraire du code d'une méthode pour en faire une nouvelle ou même modifier une hierarchie. Si ces étapes individuelles peuvent sembler élémentaires, l'effet cumulatif de ces petits changements peut améliorer grandement un design. Refactorer est un moyen efficace pour empêcher un logiciel de pérécliter.

Outre les discussions sur les différentes techniques de refactoring, l'auteur donne un catalogue détaillé de plus de 70 étapes avec des références judicieuses pour nous apprendre quand les appliquer, des instructions pas à pas pour chaque application d'un tel pattern et un exemple illustrant comment fonctionne le refactoring. Les exemples illustratifs sont écrits en Java, mais les idées sont applicables à tout langage orienté objet.

Critique du livre par la rédaction (Miles)
Une référence, voilà ce qu'est devenu ce livre pour moi. Le catalogue de patterns - parce que je considère ces petites étapes comme des patterns - est dense, presque exhaustif - je suis sûr qu'on pourrait en trouver d'autres -, mais il y a les patterns les plus simples et les plus utiles. Comme le texte au dos du livre le dit, certaines étapes semblent vraiment trop simples, et c'est le cas. Tout le monde sait inliner une fonction. On a un peu plus de mal en extrayant une méthode d'une autre méthode, mais de manière générale, on serait tomber tôt ou tard sur ces patterns.

L'avantage du livre, ce n'est pas de nous redire ce qu'on sait, c'est de nous montrer une étape à laquelle on n'a pas pensé et qui résoud le problème qu'on a. Enfin, c'est pas un problème, c'est juste que le code commence à sentir mauvais. D'ailleurs, l'odeur du code, c'est une des caractéristiques de ce livre, Martin Fowler nous donne des pistes pour apprendre à reconnaître l'odeur d'un code. Ca m'a fait sourire de se dire que le code avait une odeur. Et c'est vrai que lorsqu'on regarde le code qu'on faisait quand on était plus jeune, on se rend compte qu'il pue.

Un autre point de ce livre, c'est qu'il met l'accent sur les tests, principalement unitaires. Et effectivement, pour un livre qui parle de refactoring, c'est important. Il faut bien que le code après modification ait le même effet que sans modification ! L'exemple qui est donné est aussi explicite, on utilise plusieurs méthodes au fur et à mesure de l'avancement de la procédure, c'est très intéressant de voir comment ça marche.

Enfin, le code est du Java, mais pour quelqu'un qui connait le C++, ça passe sans problème. Chaque opération est suffisemment simple pour être presque identique à son équivalent en C++. Enfin, un petit topo sur ce qui existait à l'époque sur le refactoring est donné, et même s'il est un peu dépassé, ce topo est très instructif.

Sommaire

  • 1. Refactoring, a First Example.
    • The Starting Point.
    • The First Step in Refactoring.
    • Decomposing and Redistributing the Statement Method.
    • Replacing the Conditional Logic on Price Code with Polymorphism.
    • Final Thoughts.
  • 2. Principles in Refactoring.
    • Defining Refactoring.
    • Why Should You Refactor?
    • When Should You Refactor?
    • What Do I Tell My Manager?
    • Problems with Refactoring.
    • Refactoring and Design.
    • Refactoring and Performance.
    • Where Did Refactoring Come From?
  • 3. Bad Smells in Code.
    • Duplicated Code.
    • Long Method.
    • Large Class.
    • Long Parameter List.
    • Divergent Change.
    • Shotgun Surgery.
    • Feature Envy.
    • Data Clumps.
    • Primitive Obsession.
    • Switch Statements.
    • Parallel Inheritance Hierarchies.
    • Lazy Class.
    • Speculative Generality.
    • Temporary Field.
    • Message Chains.
    • Middle Man.
    • Inappropriate Intimacy.
    • Alternative Classes with Different Interfaces.
    • Incomplete Library Class.
    • Data Class.
    • Refused Bequest.
    • Comments.
  • 4. Building Tests.
    • The Value of Self-testing Code.
    • The JUnit Testing Framework.
    • Adding More Tests.
  • 5. Toward a Catalog of Refactorings.
    • Format of the Refactorings.
    • Finding References.
    • How Mature Are These Refactorings?
  • 6. Composing Methods.
    • Extract Method.
    • Inline Method.
    • Inline Temp.
    • Replace Temp with Query.
    • Introduce Explaining Variable.
    • Split Temporary Variable.
    • Remove Assignments to Parameters.
    • Replace Method with Method Object.
    • Substitute Algorithm.
  • 7. Moving Features Between Objects.
    • Move Method.
    • Move Field.
    • Extract Class.
    • Inline Class.
    • Hide Delegate.
    • Remove Middle Man.
    • Introduce Foreign Method.
    • Introduce Local Extension.
  • 8. Organizing Data.
    • Self Encapsulate Field.
    • Replace Data Value with Object.
    • Change Value to Reference.
    • Change Reference to Value.
    • Replace Array with Object.
    • Duplicate Observed Data.
    • Change Unidirectional Association to Bidirectional.
    • Change Bidirectional Association to Unidirectional.
    • Replace Magic Number with Symbolic Constant.
    • Encapsulate Field.
    • Encapsulate Collection.
    • Replace Record with Data Class.
    • Replace Type Code with Class.
    • Replace Type Code with Subclasses.
    • Replace Type Code with State/Strategy.
    • Replace Subclass with Fields.
  • 9. Simplifying Conditional Expressions.
    • Decompose Conditional.
    • Consolidate Conditional Expression.
    • Consolidate Duplicate Conditional Fragments.
    • Remove Control Flag.
    • Replace Nested Conditional with Guard Clauses.
    • Replace Conditional with Polymorphism.
    • Introduce Null Object.
    • Introduce Assertion.
  • 10. Making Method Calls Simpler.
    • Rename Method.
    • Add Parameter.
    • Remove Parameter.
    • Separate Query from Modifier.
    • Parameterize Method.
    • Replace Parameter with Explicit Methods.
    • Preserve Whole Object.
    • Replace Parameter with Method.
    • Introduce Parameter Object.
    • Remove Setting Method.
    • Hide Method.
    • Replace Constructor with Factory Method.
    • Encapsulate Downcast.
    • Replace Error Code with Exception.
    • Replace Exception with Test.
  • 11. Dealing with Generalization.
    • Pull Up Field.
    • Pull Up Method.
    • Pull Up Constructor Body.
    • Push Down Method.
    • Push Down Field.
    • Extract Subclass.
    • Extract Superclass.
    • Extract Interface.
    • Collapse Hierarchy.
    • Form Template Method.
    • Replace Inheritance with Delegation.
    • Replace Delegation with Inheritance.
  • 12. Big Refactorings.
    • Tease Apart Inheritance.
    • Convert Procedural Design to Objects.
    • Separate Domain from Presentation.
    • Extract Hierarchy.
  • 13. Refactoring, Reuse, and Reality.
    • A Reality Check.
    • Why Are Developers Reluctant to Refactor Their Programs?
    • A Reality Check (Revisited).
    • Resources and References for Refactoring.
    • Implications Regarding Software Reuse and Technology Transfer.
    • A Final Note.
    • References.
  • 14. Refactoring Tools.
    • Refactoring with a Tool.
    • Technical Criteria for a Refactoring Tool.
    • Practical Criteria for a Refactoring Tool.
    • Wrap Up.
  • 15. Putting It All Together.

464 pages, 1 ère édition, Juin 1999 Editions Pearson Education, ISBN10 : 0201485672
Commandez sur www.amazon.fr :
42,17 EUR TTC (prix éditeur 42,17 EUR TTC) - Livraison Gratuite !

precedent    sommaire    suivant

Valid XHTML 1.0 TransitionalValid CSS!

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2005 - 2009 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.