Note de lecture : Design Patterns, par Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides

Note : 10+ ; LE livre de la décennie 90 !! Book of the year 1995 & Book of the decade ‘90!

Il y a un « avant » et un « après » Design Patterns. Il y a tellement de choses à dire sur ce livre emblématique qu’il est même difficile de trouver par où commencer. Commençons par « avant ».

Dans les années 80, jusqu’au début des années 90, on parlait bien d’activité de conception (par opposition à l’activité d’analyse) mais sans parvenir vraiment à identifier ce en quoi cela consistait. « montre-moi ton arbre d’héritage » était alors l’aulne à laquelle on mesurait la qualité d’une conception objet. Evidemment un arbre large et profond était jugé meilleur qu’un arbre rabougri. Pour certains gourous, seuls les objets issus du domaine métier étaient des éléments valides de conception. Je garde un souvenir vivace de m’être fait tancé vertement pour avoir introduit dans ma conception des objets qui n’en étaient pas. Bref l’activité de conception était alors généralement considéré comme le tartinage de code dans les classes identifiées en analyse. Sauf pour quelques uns qui se disaient qu’il y avait plus…

Puis est arrivé le Design Patterns. Un ouvrage tellement emblématique qu’il porte même un nom alternatif dans la communauté des patterns : le GoF, c’est à dire le « gang of four » par référence à ses quatre auteurs.

Lire la suite

Note de lecture : MDA, conception orientée objet guidée par les modèles, par Hubert Kadima

Note : 3 ; Trop vague ou trop près du code !

Ce livre est une déception. Tout d’abord, ce n’est pas le bon livre pour comprendre MDA : les chapitre 1 à 3 sensés le décrire sont brumeux, énumérant (répétant même, assez souvent), ce que MDA permet de faire, sans vraiment expliquer la chose. Je n’aurais pas appris MDA par ailleurs, je n’aurais rien compris !

Le chapitre 4 apparaît soudainement, en décalage : alors que l’on dissertait vaguement de principes généraux, voici (boum !) un chapitre est dédié à Rational XDE, qui n’est même pas vraiment un outil MDA. Qu’importe, on nous inonde de copie d’écrans et de scripts de génération de code ! Puis succède le chapitre 5, qui n’est pas non plus dédié à MDA mais au processus de développement.

En fait, les éléments m’intéressant ont débuté au chapitre 6, où l’on présente l’étude de cas de la chaîne logistique. En fait, ce chapitre n’est pas non plus orienté MDA, mais j’ai trouvé l’exposé du sujet intéressant, ainsi que l’évocation des normes s’y rattachant : SCORE, Rosetta Net, etc.. Le chapitre 7, qui lui est vraiment MDA, a l’intérêt de traiter correctement du sujet : l’approche MDA avec le profil J2EE. Au moins entre-t-on dans le vif du sujet.

Les chapitres 8 et 9 (qui sont les derniers) font l’originalité du livre et par là même en relèvent un peu la note. Dans le premier, on évoque le profil UML pour Corba CCM, avec une longue mais très intéressante introduction au modèle CCM. Dommage que le traitement de l’étude de cas sur ce profil soit un peu bâclé. Le dernier chapitre est encore plus intéressant, puisqu’il traite du CWM, le métamodèle dédié aux entrepôts de données. Ce métamodèle, avec ses sous-ensembles est expliqué, tout comme l’est succinctement Jolap, l’interface Java-OLAP. Hélas, la transformation UML – CWM n’est pas évoquée.

En bref, un ouvrage bien décevant, où seul les 3 derniers chapitres présentent quelque intérêt. Pour ce qui est de comprendre MDA, allez voir ailleurs. Et pour ce qui est de comprendre la mise en œuvre, mieux vaut aller voir des outils qui convergent réellement vers MDA et non des AGL générant du code ! Si vous cherchez un livre en français sur MDA, celui de Xavier Blanc est bien meilleur à tous égards.

mda-kadima

Référence complète : MDA, conception orientée objet guidée par les modèles – Hubert Kadima – Dunod 2005 – ISBN : 2-10-007356-7

MDA, conception orientée objet guidée par les modèles


http://www.goodreads.com/book/add_to_books_widget_frame/2100073567?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Blade Servers and Virtualization, par Barb Goldworm & Anne Skamarock

Note : 5 ; Un bon guide pour le décideur, toujours intéressant sur les concepts, vieillissant sur les aspects et peu précis sur la techniques et obsolète sur la 3ème partie.

Cet ouvrage est en fait le seul que j’ai pu trouver traitant des serveurs blade. En fait, peut-être n’y a-t-il pas assez à dire pour susciter une littérature assez large ? Quoi qu’il en soit, celui-ci correspond à mes attentes : évoquer les architectures matérielles à base de serveurs blades. C’est donc assez naturellement que sont évoquées la mutualisation d’infrastructure, et notamment la connectivité, mais aussi l’alimentation électrique et le refroidissement.

Ces deux derniers sujets méritent certainement deux mots d’explications. En effet, les centres de calculs sont connus pour poser de gros problèmes de refroidissement, qui s’accentuent avec la puissance croissante des serveurs. Il est également connu que les coûts d’exploitation sont directement corrélés à la consommation électrique (avec un coût de l’électricité lui-même en forte augmentation). Le dernier paramètre étant l’occupation au sol, qui est lui-même lié aux problématiques de câblages et de refroidissement. Les serveurs blades améliorent la situation sur ces différents paramètres, tandis que la virtualisation améliore l’utilisation des serveurs et par là-même le coûts d’exploitation. La première partie du livre est consacrée à l’ évocation de ces points. Il ne s’agit que de 45 pages, la partie suivante, qui en compte 90, rentre au cœur du sujet.

La seconde partie est consacrée à l’évocation des différents aspects des blades et de la virtualisation. Elle fait bien son œuvre, sauf dans la partie dédiée à la connectivité, où d’avantage de précisions, de schémas et d’exemples auraient été bienvenus. Cette partie s’étend même aux problématiques de stockage (donc la relation avec les SANs), à la supervision et au clustering !

La troisième partie ressemble à un « guide d’achat » » : quelles sont les bonnes questions à se poser, les points à vérifier, le tout complété de matrices de comparaisons sur les différentes solutions du marché. Cela a été une présentation judicieuse du paysage à l’époque, mais elle n’est plus d’actualité.

La quatrième partie consacrée aux solutions s’est fanée avec l’âge, comme on pouvait s’y attendre. C’est dommage, car non seulement le tour du marché nous permet d’appréhender celui-ci, mais surtout les retours d’expérience du chapitre 17 sont particulièrement précieux.

Bref, voici un livre plutôt facile à lire, offrant un bon instantané sur la situation du marché et les tenants et aboutissants d’un choix. J’ai quand même été un peu frustré sur les éléments pouvant me permettre de comprendre la connectivité et donc d’établir un choix d’architecture.

L’obsolescence inévitable de l’ouvrage nécessiterait une nouvelle édition, en fait une nouvelle édition tous les deux ou trois ans au moins. Ce n’est pas le cas et c’est dommage.

blade-servers-virtualization

Référence complète : Blade Servers and Virtualization, transforming enterprise computing while cutting costs – Barb Goldworm & Anne Skamarock – John Wiley & sons 2007 – EAN : 978 0 471 78395 4

Blade Servers and Virtualization: Transforming Enterprise Computing While Cutting Costs


http://www.goodreads.com/book/add_to_books_widget_frame/0471783951?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Lean Software Development, An agile toolkit, par Mary Poppendieck & Tom Poppendieck

Note: 8 ; L’anti-taylorisme tel que nous l’enseigne l’industrie !

Le « Lean Développement » dont Mary Poppendieck est l’une des figures de proue est l’adaptation au monde du développement logiciel du mouvement « Lean production » issue de l’industrie, pratiqué notamment chez 3M et Toyota. L’ouvrage n’hésite d’ailleurs pas à illustrer les concepts évoqués par des exemples tirés de l’histoire de ces 2 sociétés (et d’autres).

Le Lean Développement, comme la plupart des méthodes agiles, ne propose pas un cadre prescriptif pour la construction logicielle, mais un ensemble de 7 principes et de 22 pratiques.

  • Eliminer le déchet : c’est l’un des principes fondamentaux du Lean développement (et des méthodes agiles en général). Il s’agit de se débarrasser de ce qui est inutile et ne participe pas à la chaîne de valeur, en utilisant deux outils que sont le repérage du gâchis et le « value stream map ».
  • Amplifier l’apprentissage : le développement d’un système informatique n’est pas une activité de production, mais un travail de développement (comme son nom l’indique), où la découverte et l’expérience jouent un rôle prépondérant. Ce principe est supporté par des outils tels que le feedback, les itérations, la synchronisation des acteurs et le « set based développement » qui privilégie la communication basé sur les contraintes (qui permet de laisser les options ouvertes) plutôt que celle basée sur les choix (qui ferme ces options).
  • Décider aussi tard que possible : Ne pas s’enfermer dans le choix de certaines options tant que l’on peut garder les options ouvertes ! Ce principe est soutenu par des outils tels que « l’option thinking », le « dernier moment raisonnablement possible » par l’utilisation d’abstraction d’interfaces ou de paramètres lors de la conception
  • Délivrer aussi rapidement que possible : cette pratique dont le nom est auto explicite s‘appuie sur des outils tels que le « pull system », où le travail est tiré, choisi au moment où l’on peut l’effectuer plutôt que d’être assigné à l’avance de façon autoritaire ; une approche directement héritée des « kanban » , la « théorie des queues », le « coût des délais ».
  • « Team empowerment » est un des fondements des méthodes agiles, mais aussi de ce que l’on appelle parfois le « Toyotisme ». Il s’agit ici de descendre le pouvoir de décision au niveau de ceux qui réalisent le travail, une approche servant-based management en rupture totale avec le taylorisme. 
  • L’intégrité : Ce principe se décline en « intégrité conceptuelle » dans laquelle les principes centraux du système fonctionnent de façon cohérente, et en « intégrité perçue » dans laquelle le système assure le bon équilibre entre fonctionnalités, ergonomie, fiabilité et critères économiques.
  • Voir l’ensemble : ce principe nous invite à améliorer le processus de développement en le considérant dans sa globalité plutôt que par optimisations locales, en utilisant des outils tels que les mesures ou les contrats.

Cet ouvrage est à mon avis hautement instructif, pratique et éclairé, il considère le développement logiciel comme une activité exploratoire, donnant la part belle à l’initiative, à l’organisation émergente et au leadership, par opposition aux processus prescriptifs, gérés par le contrôle de la conformité aux plans. Le texte rompt l’idée préconçue que le processus de développement doit être identique au processus de production et que le taylorisme est la réponse ultime de l’organisation, alors même que cette illusion a pris fin depuis plus d’un demi-siècle.

Ce livre n’évite aucun sujet épineux et traite même des aspects contractuels de la réalisation de projets, qui est un sujet hautement problématique des méthodes agiles. Les apports de la logistique industrielle que nous offrent les auteurs sont originaux et particulièrement instructifs, le plus souvent en rupture avec les idées préconçues que nous pouvons avoir sur le sujet.

La compacité du texte (186 pages) sera, j’espère, un argument supplémentaire pour vous décider à en aborder la lecture. A dévorer sans réserve !

lean-soft-dev-toolkit

Référence complète : Lean Software Development, An agile toolkit – Mary Poppendieck & Tom Poppendieck – Addison Wesley / ASD series 2003 – ISBN: 0-321-15078-3

Lean Software Development: An Agile Toolkit for Software Development Managers


http://www.goodreads.com/book/add_to_books_widget_frame/0321150783?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : The Art of Lean Software Development, par Curt Hibbs, Steve Jewett & Mike Sullivan

Note: 3 ; Tour d’horizon superficiel du développement agile .. sans vision particulièrement « lean » !

J’ai l’habitude d’apprécier les livres succincts. Ils ont le bon goût d’aller à l’essentiel et ainsi de distiller efficacement une information utile. J’étais curieux de voir ce qu’il en allait être de cet ouvrage à la fois particulièrement court (120 pages) et pas spécialement bon marché ! Une autre source de curiosité était la juxtaposition des mots « Lean » et « développement ». Si le sujet est à la mode et que l’on développe largement la pensée « lean » dans la communauté agile, j’avoue avoir encore du mal à cerner en quoi le lean influence les pratiques de développement popularisées par les méthodes agiles.

Globalement, ce livre est hélas une déception. Il constitue certainement une bonne approche pour sensibiliser des managers aux grands principes du développement agile : il reste au niveau des grands principes et fait le tour d’horizon des pratiques agiles en expliquant leur utilité. Ainsi 6 chapitres sur les 9 que compte l’ouvrage sont dédiés aux principales pratiques de développement déjà promues par Scrum, XP ou les pragmatiques programmeurs :

  • Scripter les builds et utiliser un gestionnaire de version, plutôt que de compter sur une procédure interactive pour rendre un « build » répétable.
  • Automatiser les tests, au niveau des tests de développements ou des tests comportementaux (tests d’intégration ou de recette). Ce chapitre présente d’ailleurs un condensé plutôt réussi du sujet, même s’il reste un peu superficiel.
  • Mettre en place une intégration continue.
  • Optimiser le volume de code, en ne gardant que le code utile. Ce qu’on appelle le YAGNI (you ain’t gonna need it) dans XP.
  • Petites itérations. Inutile d’épiloguer, le titre parle de lui-même.
  • L’implication continue de l’utilisateur, en l’impliquant dans la boucle de feedback de l’itération. Ce que les auteurs appellent aussi le « CRACK customer » (Collaborative, Representative, Authorized, Commited, Knowledgeable).

Finalement, seul le chapitre 9 approche les pratiques Lean et leur application au développement logiciel. Les auteurs évoquent ici les ateliers Kaizen et le value stream mapping essentiellement et mentionnent les autres pratiques Lean (ainsi que des approches complémentaires comme la théorie des contraintes). 

L’intérêt de sortir un livre de sensibilisation sur les pratiques de développement agile en 2009 alors que le sujet est déjà bien couvert m’échappe un peu, je dois dire. Je mettrais celui-ci au niveau du livre de Craig Larman (agile and iterative development, a manager’s guide) pour ce qui est du public visé, avec un très gros point en faveur de ce dernier ouvrage. Enfin, le titre du livre est assez trompeur, comme j’ai pu le dire.

Sans doute pourrais-je proposer de lire cet opuscule à un développeur ou à un manager désireux d’acquérir une compréhension de premier niveau des principales pratiques agiles. La brièveté du texte sera là une réelle qualité.

En conclusion : un livre bien trop cher eut égard au contenu et dont l’intérêt est peu probant par rapport à la bibliographie existante. Il reste toutefois une petite niche de lecteurs potentiels auxquels je pourrais même conseiller l’ouvrage. Le passionné n’y trouvera pas son compte.

art-of-lean-agile-dev

Référence complète : The Art of Lean Software Development – Curt Hibbs, Steve Jewett & Mike Sullivan – O’Reilly 2009 – EAN : 978 0 596 51731 1

The Art of Lean Software Development: A Practical and Incremental Approach


http://www.goodreads.com/book/add_to_books_widget_frame/0596517319?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : UML Distilled 3rd edition, par Martin Fowler

Note : 9 ; Une édition encore meilleure (si c’est possible) d’un ouvrage qui ne cesse de me surprendre par sa qualité et se concision.

On est toujours en droit de se demander si une nouvelle édition n’est pas un simple lifting, surtout quand il s’agit comme ici d’un best seller. J’en veux pour témoin l’habillage résolument clinquant de la jaquette, on croirait Elvis Presley à sa grande époque !

Ce livre présente UML2, et ce fut l’un des premiers. Outre la présentation précise et efficace d’UML2, les points de différence avec UML1 sont soulignés. Le livre reste toujours aussi agréable à lire. Il est intéressant de noter, tout comme la seconde édition mettait un coup de projecteur sur Unified Process, ce sont ici les méthodes Agiles qui sont mises en lumière. Cela induit un petit travers dans la présentation de la notation dont je me serais bien passé. Il est préférable dans ce type d’ouvrage, de présenter la notation pour elle-même, mais c’est résolument le point de vue adopté par l’auteur : filtrer de la norme UML ce qui est utile et important à utiliser dans le cadre d’un projet. N’attendez donc pas une description exhaustive d’UML 2.0 !

J’ai souvent remarqué que les très bon livres utilisent les pages internes des couvertures comme « cartes de référence ». C’est encore le cas ici : Les éléments constitutifs de la notation sont présentés sous forme graphique, regroupés par type de diagramme, avec le renvoi vers la page descriptive. Vraiment très pratique !

J’ai souvent fait remarqué la concision et la clarté de la prose de Martin Fowler. Il est ici au sommet de son art. On a même peine à croire, la dernière page refermée que tout tient en moins de 200 pages, annexes comprise, le texte étant par ailleurs largement aéré par les nombreux diagrammes illustrant le texte. C’est un tour de force, d’autant qu’au grée des éditions et des normes successives d’UML ajoutant de nouveaux éléments, le volume du livre n’a pas augmenté d’une seule page.

Je ne vais pas détailler le contenu du livre. De manière globale, Martin Fowler a vétillé le volume consacré à chaque sujet en fonction de l’importance relative dans un usage réel au sein d’un projet. Ainsi le diagramme de classe se taille la part du lion. Le diagramme de séquence et le diagramme d’objet (et le diagramme de communication qui est son complément naturel) sont aussi très correctement traités. A l’autre extrémité, le diagramme de déploiement, d’interaction, de temps ou les collaboration sont abordés très succinctement en seulement 2 pages. Pourtant en 2 pages seulement l’auteur concentre l’essence de l’information sur ces digrammes et le lecteur intéressé y trouvera déjà de quoi les utiliser concrètement. De toute manière d’autres livre plus massifs existent pour traiter cette matière plus en profondeur, ce n’est pas le créneau de ce livre.

UML est un bon outil. Pas seulement pour le spécificateur, mais aussi pour le développeur ou toute personne au sein des projets pour simplement communiquer de manière efficace. Mais tout le monde ne peut ou ne veux investir beaucoup de temps à comprendre cet outil. UML distilled est sans contestation possible le livre idéal pour cela. Mon conseil ? Faites figurer ce livre de force dans toute bibliothèque d’un projet. Il contient le substantifique moelle de la notation UML qui peut être acquise avec un investissement de temps complètement optimisé. Ce serait dommage de passer à côté.

UML-distiled-3edt

Référence complète : UML Distilled, a brief Guide to the standard Modeling Language, Third edition – Martin Fowler – Addison Wesley / O.T. series 2003 –ISBN: 0-321-19368-7

UML Distilled: A Brief Guide to the Standard Object Modeling Language


http://www.goodreads.com/book/add_to_books_widget_frame/0321193687?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on