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

Les livres anglaisConsultez tous les livres

Dernière mise à jour : 22 septembre 2013 

precedentsommairesuivant
  1. Advanced Software Testing - Vol. 2 : Guide to the ISTQB Advanced Certification As an Advanced Test Manager
  2. Working Effectively with Legacy Code
  3. Software Testing Foundations - A Study Guide for the Certified Tester Exam
  4. Beautiful Testing - Leading Professionals Reveal How They Improve Software
  5. Version Control With Git: Powerful Tools and Techniques for Collaborative Software Development
  6. 97 Things Every Programmer Should Know
  7. Cloud Application Architectures - Building Applications and Infrastructure in the Cloud
  8. 97 Things Every Software Architect Should Know
  9. Masterminds of Programming
  10. Beautiful Architecture
  11. The Art of Unit Testing - With Examples in .NET
  12. The Art of Application Performance Testing - Help for Programmers and Quality Assurance
  13. Visualizing Data - Exploring and Explaining Data with the Processing Environment
  14. Becoming Agile - in an imperfect world
  15. SOA Security
  16. The Productive Programmer
  17. Object-Oriented Thought Process, 2nd edition
  18. Beautiful Code - Leading Programmers Explain How They Think
  19. The Art of Agile Development
  20. Test-Driven Development - By Example
  21. SOA In Practice - The art of Distributed System Design
  22. Design Patterns - Elements of Reusable Object-Oriented Software
  23. Refactoring to Patterns
  24. Refactoring - Improving the Design of Existing Code
couverture du livre Advanced Software Testing

Note 4.0drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Advanced Software Testing

Vol. 2 : Guide to the ISTQB Advanced Certification As an Advanced Test Manager

de Rex Black
Public visé : Intermédiaire

Résumé de l'éditeur

This book teaches test managers what they need to know to achieve advanced skills in test estimation, test planning, test monitoring, and test control. Readers will learn how to define the overall testing goals and strategies for the systems being tested.

This hands-on, exercise-rich book provides experience with planning, scheduling, and tracking these tasks. You'll be able to describe and organize the necessary activities as well as learn to select, acquire, and assign adequate resources for testing tasks. Learn how to form, organize, and lead testing teams Master the organizing of communication among the members of the testing teams, and between the testing teams and all the other stakeholders. Additionally, you'll learn how to justify decisions and provide adequate reporting information where applicable.

Target Audience : Software Testers, Programmers, System Designers, IT Managers.

200 pages, 6 janvier 2009 

Édition : Rocky Nook

ISBN10 : 1933952369

ISBN13 : 9781933952369

Format : 18,8 x 4,4 x 23,4 cm

Commandez sur www.amazon.fr :

43,10 € TTC (prix éditeur 42,50 € TTC) livraison gratuite !

Sommaire

  1. Test Basics
  2. Testing Processes
  3. Test Management
  4. Test Techniques
  5. Tests of Software Characteristics
  6. Reviews
  7. Incident Management
  8. Standards and Test Process Improvement
  9. Test Tools and Automation
  10. People Skills and Team Composition
  11. Preparing for the Exam

 
Critique du livre par la rédaction Grégory Heitz le 6 août 2010 

Rex Black, ancien président de l'ISTQB, nous propose le seul ouvrage dédié à la préparation de la certification ISTQB « CTAL Test Manager ». Au delà, d'une simple préparation à une certification à l'aide de QCM et d'exercices pratique, ce livre est aussi une solide introduction au management des tests dans les projets actuels. Il offre aussi des pistes intéressantes de réflexion et d'amélioration pour les responsable d'activité(s) de test. Les thèmes abordés mettent l'accent sur les problématiques récurrentes rencontrées lorsque l'on doit gérer les tests : estimation des charges, définition de la stratégie, outsourcing, gestion de l'équipe¿ le tout complété par de nombreux retours d'expérience qui font l'intérêt de ce livre.

La section « Standards and Test Process Improvement » offre un tour d'horizon des normes et méthodologies applicables au test logiciel - en complément des CMMI et ITIL - comme TMMI, TMAP, TPI, CTP, STEP. Et là je suis resté sur ma faim, car l'aspect mise en pratique est mis de côté au profit d'une description comparative de ces méthodes, sans parler des normes qui ne sont que citées. Mais ceci est justifié par le respect du niveau de connaissance attendu pour cette certification (voir le syllabus CTAL).

En résumé, ce livre m'a permis de préparer et passer sereinement la certification ISTQB « CTAL Test Manager », car le CTAL, contrairement à la certification ISTQB CTFL, dispose d'un syllabus CTAL plutôt léger pour se préparer seul à l'examen.

 
couverture du livre Working Effectively with Legacy Code

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Working Effectively with Legacy Code

de Michael C. Feathers
Public visé : Intermédiaire

Résumé de l'éditeur

This book provides programmers with the ability to cost effectively handle common legacy code problems without having to go through the hugely expensive task of rewriting all existing code. It describes a series of practical strategies that developers can employ to bring their existing software applications under control. The author provides useful guidance about how to use these strategies when refactoring or making functional changes to codebases. One of the book's key points is that it teaches developers to write tests that can be used to make sure they are not unintentionally changing the application as they optimize it. Examples are provided in Java, C++, and Csharp, and the book assumes that the reader has some knowledge of UML notation. Strategies using UML and code in C++ and Java primarily while language independent advice will be delivered in side bars and appendices for language specific users.

456 pages, 1re édition, 22 septembre 2004 

Édition : Prentice Hall

ISBN10 : 0131177052

ISBN13 : 9780131177055

Format : 23,1 x 17,5 x 2,5 cm

Commandez sur www.amazon.fr :

32,78 € TTC (prix éditeur 45,90 € TTC) livraison gratuite !

Sommaire

  1. THE MECHANICS OF CHANGE
    1. Changing Software
    2. Working with Feedback
    3. Sensing and Separation
    4. The Seam Model
    5. Tools
  2. CHANGING SOFTWARE
    1. I Don't Have Much Time and I Have To Change It
    2. It Takes Forever To Make a Change
    3. How Do I Add a Feature?
    4. I Can't Get This Class into a Test Harness
    5. I Can't Run This Method into a Test Harness
    6. I Need to Make a Change. What Methods Should I Test?
    7. I Need to Make Many Changes In One Area Do I Have To Break
    8. I Need To Make a Change but I Don't Know What Tests To Write
    9. Dependencies on Libraries Are Killing Me
    10. My Application Is All API Calls
    11. I Don't Understand the Code Well Enough To Change It
    12. My Application Has No Structure
    13. My Test Code Is in the Way
    14. My Project Is Not Object-Oriented. How Do I Make Safe Changes?
    15. This Class Is Too Big and I Don't Want It to Get Any Bigger
    16. I'm Changing The Same Code All Over the Place
    17. I Need To Change a Monster Method and I Can't Write Tests for It
    18. How Do I Know That I'm Not Breaking Anything?
    19. We Feel Overwhelmed. It Isn't Going To Get Any Better
  3. DEPENDENCY BREAKING TECHNIQUES
    1. Dependency Breaking Techniques

 
Critique du livre par la rédaction Pierre Roumagnac le 2 novembre 2012 

Le livre « Test Driven Development By Example » de Kent Beck pose les bases de l'automatisation des tests et donc des méthodes agiles.
Particulièrement simple et didacticiel, le seul faux pas en était de partir exclusivement de nouveaux projets.

Le livre « Working Effectively With Legacy Code » va plus loin, le constat étant : 80% du codage s'effectue sur du code « Legacy » (existant).
Parfois codé par des codeurs inexpérimentés, parfois détérioré simplement par les contraintes de délais imposés, le code Legacy est difficile à maintenir et les risques d'erreurs sont nombreux lors d'intervention.
Comment intervenir sur de tels projets sans détériorer l'existant ? Michael Feather propose des dizaines de méthodes, de trucs et d'astuces afin de :

  • diminuer les dépendances du code ;
  • mettre en place des tests unitaires sur le périmètre d'intervention ;
  • améliorer petit à petit le code existant.

Ce livre s'adresse aux codeurs intermédiaires qui ont déjà une notion du TDD, et qui souhaiteraient le mettre en pratique, y compris sur des projets existants.
Il permet de rendre le code plus modulable et facilement testable.
Les exemples sont en C++, C# ou Java, certaines techniques sont dédiées à un langage (l'usage des Macros en C/C++) mais la plupart sont applicables à tous.

En résumé
Les exemples sont clairs et didactiques, c'est le complément indispensable de « Test Driven Development By Example » pour mettre en oeuvre le TDD et migrer vers de l'agilité sur des projets existants.

Un seul regret, il n'existe qu'en anglais.

 
couverture du livre Software Testing Foundations

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Software Testing Foundations

A Study Guide for the Certified Tester Exam

de Andreas Spillner, Tilo Linz, Hans Schaefer
Public visé : débutant

Résumé de l'éditeur

Professional testing of software has become an increasingly important task that requires a profound knowledge of testing techniques. Recently, an internationally recognized certification program has been developed. This book covers the "Foundations Level" (i.e., entry level) and teaches the most important methods of software testing. It is designed for self-study and provides the necessary knowledge to pass the Certified Tester: Foundations Level exam as defined by the universally recognized ISTQB. It also covers more recent topics, such as test-first approach and risk-based testing.

296 pages, 3e édition, 1er janvier 2011 

Édition : O'Reilly UK

ISBN10 : 1933952784

ISBN13 : 9781933952789

oreilly.com : 20,08 € TTC seulement

Commandez sur www.amazon.fr :

33,20 € TTC (prix éditeur 33,20 € TTC) livraison gratuite !
  • Introduction
  • Fundamentals of Testing
  • Testing in the Software Lifecycle
  • Static Testing
  • Dynamic Analysis - Test Design Techniques
  • Test Management
  • Test Tools
  • Test Plan According to IEEE Standard 829-1998
  • Important Information on the Curriculum and on the Certified Tester Exam
  • Exercises
  • Glossary
  • Literature
  • Index

 
Critique du livre par la rédaction Gomes Rodrigues Antonio le 1er février 2011 

Après avoir entendu plusieurs fois parler de la certification ISTQB, j'ai profité de la sortie de la version 3 du livre qui couvre le syllabus Fondation, version 2010 pour regarder ça d'un peu plus près.

Autant aller directement à l'essentiel : "Software Testing Foundations" est un très bon livre pour les débutants mais pas suffisant pour préparer la certification (aucune indication de son déroulement, aucun examen blanc.) comme le confirme annexe B.

Lors de l'introduction, l'importance des tests est abordée. Dès le premier chapitre on retrouve toutes les qualités du livre, sa facilité de lecture, ses exemples et astuces, ses commentaires dans la marge...

Une autre qualité que l'on trouvera dans la suite est le fait de bien amener les idées. Par exemple dans un premier temps on nous dit que l'on ne peut pas tout tester. Puis que si l'on ne trouve pas de bogue cela ne veut pas dire qu'il n'y en a pas. Pour conclure sur l'importance d'une méthode de test.

L'autre plus du livre est qu'il n'est pas seulement théorique et qu'il tient compte de la réalité avec des conseils pratiques comme le fait que dans un projet le temps consacré aux tests n'est pas toujours suffisant...

Puis les auteurs nous présentent l'exemple qui sera utilisé tout au long du livre.

A la fin du chapitre les auteurs nous ont expliqué leur philosophie du test et tous les termes associés (que l'on retrouve dans le glossaire à la fin du livre).

Dans le chapitre suivant, l'exemple du cycle en V est utilisé pour nous montrer l'utilisation des tests. On a droit aux tests unitaires, tests d'intégration. de manière détaillée avec leurs objectifs, leurs stratégies... Les méthodes agiles sont aussi abordées dans une moindre mesure.

Puis un chapitre entier nous parle des tests statiques avec une partie sur la revue (de code, de documentation.) et l'analyse statique.

Dans la continuité l'analyse dynamique (boite noire, boite blanche.) est traitée.

Enfin de manière sommaire (un autre livre lui est dédié) mais complète, le management des tests est traité.

Un chapitre sur les outils conclut le livre.

En annexe on trouve un exemple de plan de test avec de nombreuses astuces.

 
couverture du livre Beautiful Testing

Note 4.0drapeau
Détails du livre
Critiques (1)
 
 

Beautiful Testing

Leading Professionals Reveal How They Improve Software

de Tim Riley, Adam Goucher

Résumé de l'éditeur

This unique book offers essays from 25 leading software testers that illustrate the qualities and techniques necessary to make software testing an art in itself. The latest entry in O'Reilly's successful series that includes "Beautiful Code" (9780596510046) and "Beautiful Teams" (9780596518028), this book demonstrates through personal stories and many examples the simplicity, maintainability, flexibility, and efficiency required to test every aspect of a software project.

Commentez Donner une note à l´article (4)

352 pages, 1re édition, 1er octobre 2009 

Édition : O'Reilly

ISBN10 : 0596159811

ISBN13 : 9780596159818

Commandez sur www.amazon.fr :

38,33 € TTC (prix éditeur 41,11 € TTC) livraison gratuite !
Critique du livre par la rédaction Matthieu Brucher le 1er septembre 2010 

Tester est une des bases de la création d'applications robustes et efficaces. O'Reilly a publié dans sa série "Beautiful" un grand nombre de livres sur des parties différentes du process de développement. Ici, il s'agit de la partie sur les tests.

D'après ce livre, il y a 3 aspects aux tests : les testeurs, les processus et les outils.

Peut-être que le problème le plus important dans les tests est l'obtention de testeurs motivés. La première partie du livre n'a que 3 chapitres, j'imagine qu'il n'y a pas de baguette magique pour avoir une équipe de testeurs, il faut surtout que les personnes s'entendent.

La deuxième partie est la plus importante, elle a obtenu le plus d'attention dans le livre. Avec du recul, grâce à ce livre, j'ai réalisé que beaucoup d'aspects des tests n'étaient jamais abordés, et je pensais que certains codes ne pouvaient même pas être testés. J'avais naturellement tort. Par exemple, le test de code mathématique peut être effectué, un chapitre donne de bonnes pistes à suivre. D'autres chapitres parlent du fuzzing et donc d'un angle qui est surtout corrigé après la découverte d'un bug (le fuzzing permettrait de corriger le problème avant qu'il ne soit découvert), ou encore le test d'application sur réseau. En fait, l'étendue des projets qui ont participés me donnent de l'espoir et me rendent aussi honteux (parce qu'il y a beaucoup de choses que je n'avais testé, que je n'avais pas anticipé, ...).

La dernière partie s'occupe des outils utilisés pendant les tests. Il ne s'agit pas des usuels xUnit, mais bien de quelques-uns des outils qui ont commencés petits et qui ont fini comme des piliers de leurs projets parents, d'outils Open Source (valgrind, ...) ou encore d'autres.

A champ très large de projets, de personnes et de workflows sont décrits dans ce livre. S'il a beaucoup de beaux processus, il n'y a pas beaucoup de moyens de rassembler de belles personnes dans des équipes de tests. De plus, il semble que beaucoup de beaux outils étaient de petits outils qui étaient écrits pour un objectif très rapidement puis refactorés dans quelque chose bien plus puissant.

J'ai particulièrement apprécié quelques chapitres dans la deuxième partie, et surtout celui sur les tests statisques. Il est parfois très difficile de tester ces codes, et même si le chapitre ne résoud pas le problème des statistiques lui-même, il aide à la création d'un framework qui ressemble à des tests aléatoires réels.

Et je ne verrai plus les équipes de Q&A de la même manière.

Testing is one of the basis to create robust and correct code. O'Reilly has published in its "Beautiful" series a lot of books on different parts of the development process. This is the testing part.

According to this book, testing has three aspects: testers, process and tools.

Perhaps the biggest issue in testing is getting motivated testers. The first part of the book has only three chapters. I guess there is no silver bullet for getting a beautiful team of testers, it's mainly about people getting along.

The second part is the one that got the most attention in the book. In retrospective, thanks to this book, I've discovered many aspects of testing are never addressed , and I thought that some code couldn't even be tested. I was obviously very wrong. For instance, testing mathematical code can be done, a chapter gives a pretty good direction to follow. Several chapters address fuzzing and thus an aspect of testing that is mainly done after discovering a flaw (whereas fuzzing may give a shot at fixing the bug before it is discovered), or also software testing over a network. In fact the broad scope of projects that participated in this part gives me hope and shame at the same time (because there are many things I didn't test for, didn't anticipate, ...).

The last part handles tools that are used during testing. It's not about the usual xUnit, but more about some of the once-upon-a-time small tools that morphed into one of the pillars of testing in its project, or Open Source tools (valgrind, ...) or even others.

A very broad scope of projects, of people and of workflow are depicted inside this book. If there are many beautiful processes out there, there are not so many ways of getting beautiful people inside test teams. Also, it seems that many beautiful tools were mainly small project tools that were written for a simple crude purpose and that were progressively refactored into something more powerful.

I especially liked some chapters in the process part, for instance the statistical one. It's something very difficult to test, and although the chapter doesn't solve the ultimate issue of statistics, it helps creating something that looks like real random tests.

Also, I won't see Q&A the same way now.

 
couverture du livre Version Control With Git: Powerful Tools and Techniques for Collaborative Software Development

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Version Control With Git: Powerful Tools and Techniques for Collaborative Software Development

de Jon Loeliger
Public visé : Débutants,Intermédiaires,Expérimentés

Résumé de l'éditeur

Version Control with Git takes you step-by-step through ways to track, merge, and manage software projects, using this highly flexible, open source version control system.

Git permits virtually an infinite variety of methods for development and collaboration. Created by Linus Torvalds to manage development of the Linux kernel, it's become the principal tool for distributed version control. But Git's flexibility also means that some users don't understand how to use it to their best advantage. Version Control with Git offers tutorials on the most effective ways to use it, as well as friendly yet rigorous advice to help you navigate Git's many functions.

With this book, you will:

  • Learn how to use Git in several real-world development environments
  • Gain insight into Git's common-use cases, initial tasks, and basic functions
  • Understand how to use Git for both centralized and distributed version control
  • Use Git to manage patches, diffs, merges, and conflicts
  • Acquire advanced techniques such as rebasing, hooks, and ways to handle submodules (subprojects)
  • Learn how to use Git with Subversion

Git has earned the respect of developers around the world. Find out how you can benefit from this amazing tool with Version Control with Git.

3 commentaires Donner une note à l´article (4)

336 pages, 1re édition, 1er mai 2009 

Édition : O'Reilly

ISBN10 : 0596520123

ISBN13 : 9780596520120

Commandez sur www.amazon.fr :

28.64 € TTC seulement (au lieu de 28.66  € TTC : prix éditeur) livraison gratuite !
  • Chapter 1 Introduction
  • Chapter 2 Installing Git
  • Chapter 3 Getting Started
  • Chapter 4 Basic Git Concepts
  • Chapter 5 File Management and the Index
  • Chapter 6 Commits
  • Chapter 7 Branches
  • Chapter 8 Diffs
  • Chapter 9 Merges
  • Chapter 10 Altering Commits
  • Chapter 11 Remote Repositories
  • Chapter 12 Repository Management
  • Chapter 13 Patches
  • Chapter 14 Hooks
  • Chapter 15 Combining Projects
  • Chapter 16 Using Git with Subversion Repositories

 
Critique du livre par la rédaction Eric Reboisson le 1er août 2010 

Les DVCS (Git, Mercurial, Bazaar...) sont très à la mode ces derniers temps, pour cette raison, mais aussi car je crois au fort potentiel de Git, j'ai souhaité lire "Version Control With Git" et vous pourrez trouver ici mon avis sur cet ouvrage.

Pour commencer, il faut dire qu'actuellement une utilisation efficace de Git se fait en ligne de commande, les outils comme TortoiseGit (Intégration de Git à l'explorateur de fichier Windows) ou eGit (Plugin Git pour Eclipse) ne sont pas encore au point. Partant de ce constat, je pense qu'un bon livre permet de saisir au mieux les concepts de Git, malgré les nombreuses ressources que l'on peut trouver sur internet (forums, tutoriaux, conférences, blogs). Un livre bien écrit et centralisant le meilleur des possibilités de Git est à mon sens plus efficace dans les premiers temps d'apprentissage d'un nouvel outil (en plus un livre c'est décentralisé, pas besoin de connexion à internet :) ).

Donc, dans "Version Control With Git", on commence par le point de départ qui est l'installation de Git sur les plateformes Linux et Microsoft Windows, puis plusieurs chapitres expliqueront :

  • les concepts généraux de Git et son histoire (son créateur est quand même Linus Torvald), la signification du terme "distribué" et les avantages de l'outil ;
  • la gestion des fichiers au sein d'un repository Git ;
  • le fonctionnement des branches ;
  • les commandes permettant d'obtenir les différences entre objets et la fusion de celles-ci le cas échéant (Egalement un chapitre spécial sur les patchs) ;
  • l'accès et le travail en équipe avec des repository distants ;
  • le couplage de Git avec un repository SVN existant.

J'ai trouvé dans cet ouvrage beaucoup d'exemples jouant le rôle du fil rouge pour une bonne compréhension de l'outil, les commandes fonctionnent et les résultats observés se coordonnent avec ceux du livre, c'est limpide. Tous les aspects importants de Git sont traités de façon claire, j'ai apprécié le style de l'auteur, jamais ennuyant. De plus, on trouvera beaucoup de schémas illustrants les explications théoriques, notamment sur les objets commit et leur organisation. En fait, si on souhaite commencer un projet avec Git, je pense que ce livre explique tout ce qu'il faut savoir pour bien commencer.

Je recommande donc ce livre à tous ceux qui ne connaissent pas les outils de DVCS (notamment Git), livre qui est facile à comprendre et qui aidera beaucoup à la démystification de Git.

 
couverture du livre 97 Things Every Programmer Should Know

Note 4.0drapeau
Détails du livre
Critiques (2)
 
 

97 Things Every Programmer Should Know

de Kevlin Henney (Sous la direction de)

Résumé de l'éditeur

Tap into the wisdom of experts to learn what every programmer should know, no matter what language you use. With the 97 short and extremely useful tips for programmers in this book, you'll expand your skills by adopting new approaches to old problems, learning appropriate best practices, and honing your craft through sound advice.

With contributions from some of the most experienced and respected practitioners in the industry - including Michael Feathers, Pete Goodliffe, Diomidis Spinellis, Cay Horstmann, Verity Stob, and many more - this book contains practical knowledge and principles that you can apply to all kinds of projects.

Commentez Donner une note à l´article (4)

256 pages, 1re édition, 1er mars 2010 

Édition : O'Reilly

ISBN10 : 0596809484

ISBN13 : 9780596809485

Commandez sur www.amazon.fr :

22,84 € TTC (prix éditeur 25,78 € TTC) livraison gratuite !
Critique du livre par la rédaction Eric Reboisson le 1er août 2010 

"97 Things Every Programmer Should Know" présente 97 conseils d'auteurs talentueux et célèbres (Kirk Pepperdine, Uncle Bob Martin...) aux programmeurs de tous horizons.

97 conseils pour 97 chapitres, 2 pages pour chacun, le livre présente 2 sommaires, le premier par ordre alphabétique des titres de chapitres et un second classement par catégories (Bugs and Fixes, Build, Deployment, Desgn, Coding, Error handling, Performance, Testing...) On peut donc lire ce livre linéairement ou par thème, pratique selon son besoin au moment de la lecture.

La lecture est facile, intéressante, passionnante et abordable pour un large panel de lecteurs. Par contre, bien que s'adressant à un public technique, il ne faut pas s'attendre à trouver beaucoup d'exemples de codes (voire quasiment aucun, à part "Code in the Language of the Domain" de Dan North ou "Missing Opportunities for Polymorphism" de Kirk Pepperdine), mais plus généralement des bonnes pratiques à suivre dans le quotidien du développement d'un projet informatique.

Certains conseils se répètent, mais je dirais qu'ils sont présentés sous des angles différents, apportant une certaine ouverture sur l'appréciation d'un conseil. Bien sûr, les développeurs rodés aux bonnes pratiques penseront que les conseils prodigués enfoncent des portes ouvertes, mais applique-t-on toujours réellement ce qu'on peut apprendre en théorie ? La lecture de "97 Things Every Programmer Should Know" sera peut être l'occasion de me faire mentir !

Parfois les auteurs auront des avis contradictoires, c'est aussi la richesse de cet ouvrage, une ouverture à la réflexion et le fait qu'il faille réfléchir avant d'appliquer bêtement la bonne parole.

Mes chapitres préférés ? Ou plutôt quelques uns parmi d'autres :

  • "The Boy Scout Rule" de Robert C. Martin (Uncle Bob), ou comment laisser un code meilleur après que vous l'avez trouvé ;
  • "Check your code first before looking to blame others" de Allan Kelly, ou l'art de balayer devant sa porte avant celles des autres ;
  • "Two heads are often better than one" de Adrian Wible, ou l'art du pair programming ;
  • "Write test for people" de Gerard Mezsaros, ou comment la lecture de ce chapitre par mes prédécesseurs aurait pu m'aider sur un projet actuel pour comprendre mieux l'aspect métier.

Développeur depuis plusieurs années déjà, j'ai retrouvé dans ce livre beaucoup de choses que je pratique déjà mais j'ai également beaucoup appris à la lecture d'autres chapitres et au delà des conseils aux programmeurs on pourra aussi trouver application de certaines bonnes pratiques dans la vie quotidienne.

Pour les débutants en programmation ce livre est à posséder absolument, pour les plus expérimentés je suis sûr qu'ils y trouveront leur compte ou tout du moins se rafraichiront la mémoire avec cette passionnante lecture. À noter également que le contenu de ce livre est sous licence Creative Commons accessible sur le site officiel, ça permet de se donner une idée avant l'achat physique du livre.

Critique du livre par la rédaction Eric Siber le 1er août 2010 

L'idée est simple, le résultat assez intéressant. Prenez une grosse poignée d'experts, demandez leur des conseils, rassemblez le tout sous la forme de 97 fois 2 pages par conseil, et vous voilà avec un contenu tout autant riche que dispersé sur une large gamme de sujets.

Cet ouvrage vous apporte avant tout des sujets de réflexion, certains vous étant peut-être déjà connus : les tests, les pratiques collaboratives, les outils de développement et de productivité, l'apprentissage, le professionnalisme, les performances, la prise en compte des besoins utilisateur, etc.

Selon votre expérience dans le milieu, certains conseils vous paraîtront sans doute évidents (utilisation d'un gestionnaire de sources), d'autres pas assez développés (design d'API) pour vous servir dans l'immédiat.
Difficile dès lors de donner la même satisfaction à tout type de lecteur : les moins expérimentés auront l'occasion d'en faire un livre de chevet qui les accompagnera pendant un bon moment, les plus aguerris seront sans doute confortés dans l'idée qu'ils sont sur la bonne voie.

En ce qui me concerne, si je devais reprendre l'un des conseils, celui qui m'a le plus marqué, ce serait l'un de ceux émanant de Robert C. Martin (Uncle Bob) et intitulé "The professional Programmer".
Robert C. Martin nous y explique que le trait marquant d'un développeur professionnel est son niveau de responsabilité individuelle (par rapport à son évolution de carrière, au code qu'il écrit, au fonctionnement de l'équipe à laquelle il contribue, etc.).
Dans ce qu'il affirme, une seule chose m'a énormement surpris (la culture française ?) et m'a longtemps fait réfléchir : "your are responsible for reading and learning". Uncle Bob nous encourage à ne pas compter sur nos employeurs pour nous former et, en tirant le parallèle avec des métiers comme docteur ou juriste, nous invective sur le fait que notre employeur n'est là que pour nous payer pour faire du bon boulot.
Un peu abrupt..., néanmoins force est de constater que, même si l'employeur joue le jeux des formations, ce sont bien en général ceux qui prennent les choses en main et exploitent les différentes pratiques de veille qui ressortent du lot.

Seule déception, même si un index propose un regroupement des conseils par thème, j'ai regretté que les conseils n'aient pas été regroupés en chapitres. J'ai également eu par moment le sentiment que certains conseils se recoupaient ce qui en soit n'est pas forcement très grave, mais rappelle qu'il ne suffit pas seulement de juxtaposer les différents avis pour créer un ensemble cohérent (les conseils sont classés par ordre alphabétique, selon le titre).

Cela n'enlève pour autant rien au rapport qualité / prix du livre et au contenu que tout professionnel du développement informatique devrait lire.

 
couverture du livre Cloud Application Architectures

Note 4.0drapeau
Détails du livre
Sommaire
Critiques (2)
 
 

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. Cloud Application Architectures 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.

Commentez Donner une note à l´article (4.5)

204 pages, 1re édition, 1er avril 2009 

Édition : O'Reilly

ISBN10 : 0596156367

Commandez sur www.amazon.fr :

20,13 € TTC (prix éditeur 29,99 € TTC) livraison gratuite !
  • 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

 
Critique du livre par la rédaction Pierre Chauvin le 11 mai 2009 

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) : 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.

Critique du livre par la rédaction Eric Reboisson le 1er janvier 2011 

"Cloud Application Architectures" de Georges Reese est un livre d'introduction (200 pages) aux architectures Cloud. L'auteur fait comprendre au travers de l'ouvrage les enjeux de ce nouveau genre d'architectures et montre bien que ce n'est pas seulement un "buzzword" à la mode mais une réelle perspective d'avenir.

Cet ouvrage commence par une définition du Cloud et de son intérêt pour l'entreprise ainsi qu'une explication de ses différents niveaux d'abstraction (SAAS, PAAS, IAAS). Viennent ensuite quelques démonstrations, notamment financières, sur les avantages à l'adoption du Cloud, simplement en comparant son coût à court, moyen et long terme par opposition à une architecture classique. On trouvera également de nombreux exemples pratiques (en ligne de commande et API pour S3, EC2...), principalement sur la plateforme Cloud IAAS d'Amazon, mais les exemples présentés sont également valables dans la forme pour une autre plateforme comme Microsoft Azure.

L'auteur aborde également des points du Cloud sur lesquels les entreprises s'interrogeront : sécurité, fiabilité, performance, scalabilité horizontale et verticale de l'infrastructure, sauvegarde, désastre...et les explications sont encore une fois limpides.

Voilà donc un livre clair, intéressant et rapide à lire, mais précis dans l'information. L'auteur donne d'excellents conseils sur les techniques et bonnes pratiques pour la mise en place d'une architecture Cloud. C'est donc un livre que je conseille à tout le monde en première lecture pour comprendre tous les enjeux d'une architecture qui est inévitable dans notre futur quotidien. Une lecture également intéressante pour ceux qui souhaitent se lancer dans des projets nécessitant une infrastructure que le Cloud pourrait offrir à moindres frais.

 
couverture du livre 97 Things Every Software Architect Should Know

Note 4.0drapeau
Détails du livre
Critiques (1)
 
 

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.

Commentez Donner une note à l´article (4)

220 pages, 1re édition, 17 mars 2009 

Édition : O'Reilly

ISBN10 : 059652269X

ISBN13 : 9780596522698

Commandez sur www.amazon.fr :

31,96 € TTC (prix éditeur 31,53 € TTC) livraison gratuite !
Critique du livre par la rédaction Eric Reboisson le 1er 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 !

 
couverture du livre Masterminds of Programming

Note 5.0drapeau
Détails du livre
Sommaire
Critiques (2)
 
 

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.

3 commentaires Donner une note à l´article (4.5)

494 pages, 1re édition, 1er avril 2009 

Édition : O'Reilly UK

ISBN10 : 0596515170

ISBN13 : 9780596515171

Commandez sur www.amazon.fr :

36,47 € TTC (prix éditeur 36,70 € TTC) livraison gratuite !
  • 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

 
Critique du livre par la rédaction Matthieu Brucher le 1er juillet 2010 

Quand on met ensemble une vingtaine de créateurs de langage, le résultat ne peut être qu'intéressant. C'est un bon révélateur de caractère, comme ils tendent à ouvrir leur coeur. Je pense que c'est exactement ce qui s'est produit ici.

Pas besoin de lister les langages proposés, ils font parti des langages à succès, en terme de qualité ou en terme de renommée, ce qui veut dire que certains peuvent être peu connus. Chaque chapitre est très différent des autres et, comme je l'ai dit auparavant, est très révélateur de leur auteur.

En fonction de la personne interviewée, les topics abordés sont différents. Pour certains auteurs, on a des questions sur des thèmes proches de leurs langages. Pour d'autres, les auteurs parlent de leur vision du futur de la programmation. Certains vont nous dire à quel point leur langage est superbe et que c'est une honte qu'il ne soit pas plus utilisé ou qu'il pourrait tout remplacer. D'autres encore vont vous dire que le langage leur a échappé des mains.

Il n'y a pas une seule ligne de code, c'est surtout un livre de pensées, et c'est le coeur du livre : on n'a pas de conseil sur comment écrire son code ou designer son application. On récupère les raisons fondamentales derrière un langage et leur succès. Des pistes sont données sur le futur de nos programmes, comment les langages vont évoluer et sur quoi il faut potentiellement de focaliser. Malheureusement, le chapitre que j'ai presque le plus apprécié est le dernier (sur Eiffel). C'est drôle que dans ce celui-ci, Bertrand Meyer parle des pépites qu'il a trouvé dans le dernier chapitre d'un autre ouvrage, Structured Programming (Dijkstra et al).

D'un point de vue culturel, ce livre est une mine d'or. D'un point de vue des égos, ce livre est un révélateur. Toutes choses étant égales, un grand nombre de choses peuvent être apprises en lisant ce livre sur l'approche philosophique d'un langage.

When twenty or so langage creators are put together to make a book, it can only be interesting. It's a good revealer of character, as they tend to open their heart. In fact I think that's exactly what happened in this book.

I won't make the list of the chosen langages. They are taken from the successful ones, in terms of quality as well as fame, which means that some are less known than others. Each chapter is very different, and, as I've said, very revealing.

Depending on the interviewed, the addressed topics are different. For some authors, you get questions and answers very close to their langages. For others, you have some feedback on how they see the programming field and its future evolution. Some will tell you how much their langage is great and that is a shame it is not more used or that it could replace almost everything. Other will tell you that they fill their langage slipped through their hands.

There is no single line of code, it's really a thoughts book, and this is the point of the book: you don't get advice on how you will write code or design your application. You get inner reasons for some langages and their success. You get leads for the future of your program, how langages may evolve and on what you may focus your attention. Unfortunately, the chapter I almost liked the most is the last one (on Eiffel). It's funny that in this precise chapter, Bertrand Meyer talks about the treasures he found in the last chapter of Structured Programming (Dijkstra et al).

From a cultural point of view, this book is a gold mine. For an ego point of view, this book is a revealer. All things considered, a lot of things can be learnt by reading this book on the philosophical approach of some langages.

Critique du livre par la rédaction Doeraene Sébastien le 1er avril 2011 

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 !

 
couverture du livre Beautiful Architecture

Note 3.0drapeau
Détails du livre
Critiques (2)
 
 

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.

1 commentaire Donner une note à l´article (3)

426 pages, 1re édition, 1er mars 2009 

Édition : O'Reilly

ISBN10 : 059651798X

ISBN13 : 9780596517984

Commandez sur www.amazon.fr :

40,14 € TTC (prix éditeur 40,86 € TTC) livraison gratuite !
Critique du livre par la rédaction Eric Reboisson le 1er 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 le 1er août 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.

 
couverture du livre The Art of Unit Testing

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

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.

Commentez Donner une note à l´article (5)

320 pages, 1re édition, 28 mars 2009 

Édition : Manning

ISBN10 : 1933988274

ISBN13 : 9781933988274

Broché, 898 x 94 x 748

www.manning.com : 39.99 $ seulement

Commandez sur www.amazon.fr :

28.57 € TTC (prix éditeur 28.16 $) livraison gratuite !

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
  • Appendix A : Design and testability
  • Appendix B : Extra tools and frameworks

 
Critique du livre par la rédaction Philippe Vialatte le 26 juillet 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.

 
couverture du livre The Art of Application Performance Testing

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (2)
 
 

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.

2 commentaires Donner une note à l´article (4)

158 pages, 1re édition, 1er février 2009 

Édition : O'Reilly

ISBN10 : 0596520662

ISBN13 : 9780596520663

Commandez sur www.amazon.fr :

25,12 € TTC (prix éditeur 27,87 € TTC) livraison gratuite !
  • Why Performance Test?
  • The Fundamentals of Effective Application Performance Testing
  • The Process of Performance Testing
  • Interpreting Results: Effective Root-Cause Analysis
  • Application Technology and Its Impact on Performance Testing
  • Appendix Transaction Examples
  • Appendix POC and Performance Test Quick Reference
  • Appendix Automated Tool Vendors
  • Appendix Sample KPI Monitoring Templates
  • Appendix Sample Project Plan

 
Critique du livre par la rédaction Gomes Rodrigues Antonio le 1er octobre 2010 

Lorsqu'on voit le livre pour la première fois, on se retrouve avec un livre de seulement 160 pages, écrit par un spécialiste de la performance qui travaille chez Compuware. Dès le début, on nous informe que ce livre est pour les chefs de projets et les testeurs débutants ou occasionnels et qu'il ne traitera pas de technologie particulière.

Le premier chapitre explique pourquoi il faut faire un test de performance et parle de quelques métriques (KPI). Puis l'explication des mauvaises performances d'une application nous est donnée (pas de prise en compte de la performance dans le design de l'application, test de performance seulement à la fin, pas d'objectif de capacité (nombre d'utilisateurs...), sous-estimation du succès de l'application, maturité du processus de test de performance...).

Le deuxième chapitre entre dans les détails d'une campagne de test de performance. On commence par les questions à se poser en début de campagne, puis les étapes avant de commencer à faire les tests (choisir les bons outils, avoir des SLA réalistes, avoir un jeu de données suffisant et de qualité, identifier les KPI, identifier les scénarios critiques...) sont listées et expliquées une par une. Par exemple pour l'étape « choisir les bons outils », on a droit à :

  • Petit historique.
  • Comment et pourquoi faire un POC.
  • Critères de sélection (support de la technologie utilisé (HTTP, HTTPS...), type de licence, simplicité pour la partie Scripting...).
  • Des conseils (dans la vraie vie, il faut presque toujours obliger de modifier les scripts enregistrés, faire attention au prix qui peut augmenter rapidement (besoin de nombreux tirs car l'application n'est pas stable) si c'est externalisé)...

Les autres étapes sont aussi très bien expliquées avec souvent un retour d'expérience de l'auteur et des check-lists.

Le troisième chapitre est la mise en oeuvre de ce qui a été dit au chapitre 2 et est fini avec deux exemples concrets (une banque en ligne et un centre d'appel). Quoique bien détaillés, je trouve que ces deux exemples auraient mérité plus de détails.

Au chapitre 4, on nous explique comment interpréter les résultats et trouver les problèmes de performance. Malheureusement comme le livre ne traite pas de technologie, cela manque d'exemple concret.

Le chapitre 5 traite de manière succincte l'impact des différentes technologies (Ajax, Citrix, .NET...) sur les tests.

Puis en annexe on retrouve des check-lists, une liste des outils de test et des maquettes/exemples de planning.

On se retrouve avec un bon livre si l'on fait partie de la cible de celui-ci. Une centaine de pages en plus avec plus d'exemples concrets (en traitant un peu plus de technologies) lui aurait valu la note maximale.

Critique du livre par la rédaction Matthieu Brucher le 1er juillet 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.

 
couverture du livre Visualizing Data

Note 3.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

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.

2 commentaires Donner une note à l´article (4)

382 pages, 1re édition, 11 janvier 2008 

Édition : O'Reilly UK

ISBN10 : 0596514557

ISBN13 : 9780596514556

Commandez sur www.amazon.fr :

28,83 € TTC (prix éditeur 31,85 € TTC) livraison gratuite !
  • 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

 
Critique du livre par la rédaction hiko-seijuro le 13 mars 2008 

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.

 
couverture du livre Becoming Agile

Note 5.0drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

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.

Commentez Donner une note à l´article (4)

410 pages, 1re édition, 1er mai 2009 

Édition : Manning

ISBN10 : 1933988258

ISBN13 : 9781933988252

www.manning.com : 44.99 $ seulement
Version PDF à $27.50

  • 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

 
Critique du livre par la rédaction Eric Siber le 30 mai 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 : 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 : 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: 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 : 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.

 
couverture du livre SOA Security

Note 4.0drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

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.
500 pages, 1re édition, 1er juin 2008 

Édition : Manning

ISBN10 : 1932394680

ISBN13 : 9781932394689

www.manning.com : 59.99 $ seulement

Commandez sur www.amazon.fr :

46,53 € TTC (prix éditeur 13.66 $) livraison gratuite !
  • 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)

 
Critique du livre par la rédaction Gildas Cuisinier le 1er février 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.

 
couverture du livre The Productive Programmer

Note 4.0drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

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.

222 pages, 1re édition, 1er juillet 2008 

Édition : O'Reilly

ISBN10 : 0596519788

ISBN13 : 9780596519780

Commandez sur www.amazon.fr :

31,07 € TTC (prix éditeur 32 € TTC) livraison gratuite !
  • 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

 
Critique du livre par la rédaction Eric Siber le 1er 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 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 site de l'auteur ainsi que le Wiki dédié au livre.

 
couverture du livre Object-Oriented Thought Process, 2nd edition

Note 3.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Object-Oriented Thought Process, 2nd edition

de Matt Weisfeld
Public visé : débutant

Résumé de l'éditeur

By the Professional, for the Professional!

The Object-Oriented Thought Process is a concise and readable primer.

Matt Weisfeld's years of programming, teaching, and writing have given him a flair for presenting highly technical topics in a clear and interesting manner. He is able to blend abstract concepts with ingenious examples and clear illustrations to quickly teach powerful OOP techniques.

The code examples are written in Java and UML but are designed in such a way that a reader with no previous experience will still understand them.

The Object-Oriented Thought Process is a clear and accessible alternative to the often dry and overly dense books available on the market today.

Matt Weisfeld has 18 years of software development and project management experience in COBOL, Pascal, C, C++, Smalltalk, and Java. He has taught programming classes for more than 10 years and has been published extensively in leading industry magazines, including Dr. Dobb's and Java Report including many more!

A concise but complete introduction to object-oriented concepts with code examples in Java and UML.

Excellent primer for professional developers moving to object-oriented languages, as well as CS students.

304 pages, 2e édition, 1er décembre 2003 

Édition : Sams Publishing

ISBN10 : 0-672-32611-6

Commandez sur www.amazon.fr :

28,53 € TTC (prix éditeur 28,53 € TTC) livraison gratuite !
  • Introduction to Object-Oriented Concepts
  • How to Think in Terms of Objects
  • Advanced Object-Oriented Concepts
  • The Anatomy of a Class
  • Class Design Guidelines
  • Object-Oriented Modeling
  • Designing with Objects
  • Mastering Inheritance and Composition
  • Frameworks and Reuse: Interfaces and Abstract Classes
  • Building Objects
  • Patterns
  • XML
  • Objects and the Net
  • Objects and the Enterprise
  • Objects and Databases

 
Critique du livre par pseudocode le 13 février 2004 

A mon avis un ouvrage à lire absolument pour comprendre les concepts objets, avant de parcourir des ouvrages plus spécifiques du genre "Object-Oriented Design in Java" ou "Thinking in C++". Même si les exemples dans cet ouvrage sont ecrits en java, les explications sont applicables a tous les langages OO (C++, C#, ...)

Ce livre donne les "clés" pour modéliser et implémenter un logiciel dans un langage Objet. Une mention spéciale pour le chapitre 6 où l'auteur fait l'analyse et la conception d'un jeu de black-jack en partant de la règle du jeu (description textuelle) pour finir aux diagrammes UML en utilisant la méthode des CRC-Cards.

 
couverture du livre Beautiful Code

Note 4.5drapeau
Détails du livre
Critiques (1)
 
 

Beautiful Code

Leading Programmers Explain How They Think

de Andy Oram, Greg Wilson
Public visé : Initié à expert

Résumé de l'éditeur

How do the experts solve difficult problems in software development? In this unique and insightful book, leading computer scientists offer case studies that reveal how they found unusual, carefully designed solutions to high-profile projects. You will be able to look over the shoulder of major coding and design experts as they work through their project's architecture, the tradeoffs made in its construction, and when it was important to break rules.

How do the experts solve difficult problems in software development? In this unique and insightful book, leading computer scientists offer case studies that reveal how they found unusual, carefully designed solutions to high-profile projects. You will be able to look over the shoulder of major coding and design experts to see problems through their eyes.

This is not simply another design patterns book, or another software engineering treatise on the right and wrong way to do things. The authors think aloud as they work through their project's architecture, the tradeoffs made in its construction, and when it was important to break rules. Beautiful Code is an opportunity for master coders to tell their story. All author royalties will be donated to Amnesty International.

618 pages, 1re édition, 1er juillet 2007 

Édition : O'Reilly UK

ISBN10 : 0596510047

Commandez sur www.amazon.fr :

40,56 € TTC (prix éditeur 42,94 € TTC) livraison gratuite !
Critique du livre par la rédaction Matthieu Brucher le 13 août 2008 

Un très grand nombre de contributeurs ont écrit un chapitre pour ce livre. On observe une progression très bien réalisée dans la table des matières à partir de l'analyse de code réel jusqu'à des abstractions.

Les domaines étudiés sont très différents, d'un code de tri au design d'un langage (enfin, pour cette partie là, j'ai trouvé le chapitre un peu creux...), en passant par le débuggage, ... On en trouve pour tous les goûts.

Naturellement, écrire un code "beau" repose toujours sur les mêmes astuces en réalité. Souplesse, robustesse et rapidité en dernier lieu. Pour cela, les design patterns sont naturellement mis en avant (à la fin du livre, avant on parle d'autres choses), ainsi que les meilleurs algorithmes permettant de résoudre un problème précis.

On peut donc dire que le contenu du livre existe déjà un peu partout, mais c'est faux. Celui-ci se construit sur l'expérience de plusieurs dizaines de programmeurs de talent. On mélange dans le même ouvrage tout ce qui fait un code qu'on peut qualifier de beau. Traditionnellement, on ne parle que de l'architecture d'un côté et des bons algorithmes de l'autre. Ici, on est à la limite entre les deux. Pour aller plus loin, il faudra naturellement lire le Cormen pur l'algorithmie et un livre sur l'architecture logiciel, mais le but de ce livre n'est pas, à mon sens, de remplacer ces ouvrages, mais d'en faire la liaison.

Ce n'est donc pas un livre de référence dans un domaine, mais un recueil d'expériences et de pistes à explorer quand on est devant un problème d'écriture de code durable.

 
couverture du livre The Art of Agile Development

Note 4.0drapeau
Détails du livre
Sommaire
Critiques (2)
 
 

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.

430 pages, 1re édition, 1er octobre 2007 

Édition : O'Reilly

ISBN10 : 0596527675

Broché

Commandez sur www.amazon.fr :

28,60 € TTC (prix éditeur 28,60 € TTC) livraison gratuite !
  • 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

 
Critique du livre par la rédaction Gildas CUISINIER (hikage) le 13 janvier 2008 

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.

Critique du livre par la rédaction Pierre Chauvin le 3 mars 2008 

Bien que pas assez synthétique à mon goût, "The art of Agile Development" reste un ouvrage de référence car il contient de très nombreux conseils et rappels sur les bonnes pratiques à adopter pour effectuer un développement logiciel maîtrisé, en amenant de la valeur ajoutée et en se focalisant sur les individus. Vous y retrouverez une analyse des préceptes du Agile Manifesto, croisé avec le "Manifesto for Software Craftsmanship".

Les auteurs ne se sont pas cependant limités à cette analyse et le livre porte également des conseils issus de leur expérience. Il vous aidera à mieux comprendre ce que représente "l'agilité" en termes d'ingénierie logicielle, ce qu'est XP et les analogies avec les autres approches "agiles" comme Scrum ou le Lean. Il est divisé en nombreux sous-chapitres qui contiennent, pour chaque description de la bonne pratique (presque des patterns parfois), les questions les plus fréquentes sur l'application du principe, les résultats attendus et observables, les contre-indications, ainsi que les alternatives. Très "Open-minded" donc.

Concrètement, vous serez amené à découvrir XP et ses différentes phases (Planning, Analysis, Design et Coding, Testing, Deployment), les rôles nécessaires, des recommandations pour renforcer la cohésion des équipes et l'organisation des bureaux, la maîtrise des espaces d'information, l'art d'effectuer des rétrospectives et Kaizen efficaces, les Stands-Up meetings, l'intérêt d'une forge logicielle pratique et résolument orientée vers le testing et l'intégration continue, TDD, etc.

Mon avis est ainsi particulièrement positif, et j'aurai certainement l'occasion de relire des parties de ce référentiel. Une lecture appropriée à tout développeur, mais également aux DSI qui souhaitent développer une informatique reposant sur des valeurs très fortes de participation, de confiance, de développement personnel, et de valeur ajoutée logicielle.

 
couverture du livre Test-Driven Development

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

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.

240 pages, 1re édition, 1er novembre 2002 

Édition : Pearson Education

ISBN10 : 0321146530

Commandez sur www.amazon.fr :

22,77 € TTC (prix éditeur 22,77 € TTC) livraison gratuite !
  • 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.

 
Critique du livre par la rédaction Miles le 13 janvier 2003 

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 ;)

 
couverture du livre SOA In Practice

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

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

324 pages, 1re édition, 1er septembre 2007 

Édition : O'Reilly

ISBN10 : 0596529554

ISBN13 : 9780596529550

Commandez sur www.amazon.fr :

27,66 € TTC (prix éditeur 41,11 € TTC) livraison gratuite !
  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

 
Critique du livre par la rédaction Morgan Bourgeois le 1er avril 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.

 
couverture du livre Design Patterns

Note 3.5drapeaucdrom
Détails du livre
Sommaire
Critiques (1)
 
 

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.

0 pages, 1re édition, 1er juin 1997 

Édition : Addison-Wesley Professional

ISBN10 : 0201634988

Commandez sur www.amazon.fr :

39,83 € TTC (prix éditeur 39,83 € TTC) livraison gratuite !
  • 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.

 
Critique du livre par la rédaction Miles le 27 juillet 2004 

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.

 
couverture du livre Refactoring to Patterns

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

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.

400 pages, 1re édition, 1er août 2004 

Édition : Addison-Wesley Professional

ISBN10 : 0321213351

Commandez sur www.amazon.fr :

42,72 € TTC (prix éditeur 42,72 € TTC) livraison gratuite !
  • 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.

 
Critique du livre par la rédaction Miles le 8 août 2007 

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.

 
couverture du livre Refactoring

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

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.

464 pages, 1re édition, 1er juin 1999 

Édition : Pearson Education

ISBN10 : 0201485672

Commandez sur www.amazon.fr :

42,17 € TTC (prix éditeur 42,17 € TTC) livraison gratuite !
  • 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.

 
Critique du livre par la rédaction Miles le 22 novembre 2006 

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.

 
precedentsommairesuivant

Voir également :
Tous les livres sur UML
  

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 © 2004-2013 Developpez.com 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.