Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young.
Henry Ford
Mois : août 2013
Résultats du sondage : comment traduiriez-vous « The People’s Scrum » ?
Tout d’abord un grand merci à tous ceux qui se sont livrés à l’exercice !
Au total, j’ai eu 24 réponses. On peut dire que c’est peu, mais je ne comptais de toute façon pas sur des centaines de réponses, sans compter que nous sommes au milieu de l’été… De toute façon, ce n’est pas la quantité, mais la qualité qui compte !
Une mention spéciale à Julien Tort qui a d’abord lu une partie du livre avant de faire une proposition !
Voici les résultats bruts
C’est à dessein que je n’avais pas laissé visible les résultats, même temporaires afin de n’influencer personne. Cela a peut-être eu un effet sur l’affluence… tant pis !
J’en tire temporairement 3 conclusions :
- Une des propositions n’a pas du tout retenu l’attention : “Scrum et le peuple” n’était de toute manière pas une très bonne proposition. La 5ème proposition apparait aussi avec un total de zéro, mais c’est une erreur due à une mauvaise utilisation de polldady de ma part !
- “Le Scrum du peuple” est largement en tête ! Il faut aussi dire que c’est la traduction la plus littérale. Donc, cela ne veut pas dire que je retiendrais ce résultat, mais je ne peux non plus l’ignorer.
- Il y a un grand nombre de propositions alternatives, elles représentent presque 60% des réponses.
Justement, ces propositions alternatives, quelles sont-elles ? En voici le détail
- Scrum: (Quand) le peuple s’en mêle
- Scrum pour le peuple
- Gens mêlés
- Scrum pour tous (c’est la proposition de Julien Tort que j’avais évoqué précédemment)
- Le Scrum des masses
- Le Scrum populiste
- Scrum pour les individus
- Le peuple du/de Scrum (2 réponses)
- Le Scrum des gens / Scrum sur le terrain / Démocratisation de Scrum ; ces 3 propositions m’ont été faites par une même personne.
- Le Scrum pratiqué par les gens
- Les agilistes
- Scrum : des gens, un mouvement
- Le Scrum des gens
Depuis, j’ai même encore eu une idée carrément différente : Notre Scrum. Reste maintenant à choisir. On en reparle donc plus tard !
Note de lecture : Object oriented I/O using C++ iostreams, par Cameron Hughes, Thomas Hamilton & Tracey Hughes
Note : 5 ; Une source d’information sur les Iostreams moins médiocre que le Teale. Vaut le détour (même si le sujet aurait pu être mieux traité) pour la bibliothèque GDI développée à base de streams !
Très déçu par le médiocre « C++ iostreams handbook » et vu la rareté des ouvrages sur le sujet, il ne m’a pas fallu à l’époque beaucoup de temps pour m’intéresser à celui-ci : il ne pouvait qu’être meilleurs ! En fait, il s’est surtout avéré très différent !
On pourrait appeler ce livre “variations sur les iostreams”. Les auteurs abordent le sujet en développant une bibliothèque iostream pour la GDI Windows. Voyons de plus près le contenu.
Le texte principal de l’ouvrage couvre 300 pages. A hauteur de 10 chapitres, cela nous fit une moyenne un peu élevée de 30 pages par chapitre, mais il faut tenir compte de la proportion importante de code. Il ne faut pas non plus oublier les annexes qui ne sont pas anecdotiques, car elles tiennent 70 pages.
Entrée en douceur pour ce premier chapitre qui présente le concept de streams en commençant par exposer son équivalent avec la bibliothèque C. Bien sur les iostreams sont comparées (aventageusement) par rapport à cette approche et on termine sur quelques perspectives qui annoncent les chapitres futur. Peu de code pour cette introduction de 33 pages, du texte qui se laisse lire, essentiellement.
Le but des 30 pages du chapitre est de faire le lien entre l’approche orienté objet et la bibliothèque iostream. Ce n’est pas tellement réussi et je pense qu’il aurait fallu simplement faire l’impasse sur la description du modèle objet. Les concepts en sont connus du public visé par le texte.
Heureusement les 80 pages du chapitre 3 vient à la rescousse. C’est sans conteste le chapitre le plus utile du livre pour comprendre la librairie iostream, du moins l’ancienne, celle d’avant le standard 98. La structure et l’architecture de la librairie sont très bien expliqués. En fait, c’est la première référence que jai l’heur de croiser qui m’ait apporté une telle clarté. Par contre les détails sont expliqués sinon moins clairement, du moins plus laborieusement.
Les chapitres 4 et 5 nous offrent des interludes d’une dizaine de pages chacun. Le premier pour expliquer simplement le mécanisme de friendship qui permet d’étendre la librairie iostream de manière externe. Le second pour nous présenter un autre concept clé de la librairie : les manipulateurs. C’est mieux fait que dans le Teale, mais hélas encore une fois un peu court.
Etendre la librairie iostream afin de permettre de manipuler les devices graphiques Windows comme des streams est le véritable objectif du livre ! C’est ce qui est abordé dans les 4 chapitres suivants. Le chapitre 6, le premier d’entre eux est là pour expliquer le mécanisme d’évolution de la librairie iostream sur la base des classes ios et streambuf. Hélas c’est loin d’être claire et franchement abstrait. Et bien entendu c’est aussi un pau à réviser avec la norme.
Les 35 pages du chapitre 7 ont pour objectif d’aborder le wrapping des GDI Windows et OS2 en iostream. La plus grande partie de ce chapitre est consacrée à en expliquer le fonctionnement. Il finit par aborder timidement l’implémentation d’une classe de wrapping : textspace (qui étends ostream).
Ce sont 45 pages qui cette fois sont consacrées à la classe ioscontext qui étends ios, au chapitre 8. Ce chapitre est construit sur le même modèle que le précédent.
Le chapitre 9 consacré aux Blobstreams aurait été fort intéressant s’il était allé jusqu’au bout du propos, à savoir l’implémentation sous forme d’extention de la librarie iostream. Mais il fait un boulot décent à présenter les différents formats images et son.
Un peu à part, le chapitre 10 nous présente le wrapping de la gestion du port série RS 232C sous forme d’iostream. C’est original et intéressant (bien que l’on utilise plus guère cette norme). Mais on est hélas frustré car le chapitre ne va pas au bout de la question.
Les annexes, quoi que volumineuses ne s’avèrent guère utiles. Les deux premières expliquent la notation graphique bizarre utilisée tout au long de l’ouvrage, tandis que la troisième se veut un guide de réfernce de la librairie iostream. A l’usage elle ne s’avère guère opérationnelle.
Au final se livre cherche à atteindre 2 cibles :
- Faire comprendre la librarie iostream. Cet objectif est plutôt bien atteint par la première partie du livre. En tout cas, c’est mieux que le Teale !
- Présenter une étude de cas de librarie utilisable sous forme d’interfaces stream. C’est original et même très intelligent et pourrait servir de source d’inspiration pour bon nombre de librarie. Mais le livre est un peu court sur le volet pédagogique pour expliquer la construction de la librarie. Il se noie dans pas mal de sujets connexes comme l’explication de la GDI.
Bref, un avis un peu mitigé au final. Bien sûr l’aspect « manuel de référence » a trouvé mieux depuis, je pense surtout au livre d’Angelika Langer. L’étude de cas aurait mérité un traitement plus structuré, probablement en 3 partie, avec une pour chaque environnement système (Windows et OS2) expliquent le fonctionnement des contexte graphique et permettant d’aborder des wrappers. Et une troisième partie pour construire les extensions de la librarie iostream et des exemples de mise en œuvre.
Le livre échoue finalement à bien sélectionner son objectif. Il y en 2 ici et il ne me semblait guère possible de bien les traitre tous les deux en 300 pages.
Référence complète : Object oriented I/O using C++ iostreams – Cameron Hughes – Thomas Hamilton & Tracey Hughes – John Wiley & sons 1995 – ISBN: 0-471-11809-5
If you wait by the river long enough, the bodies of your enemies will float by.
Sun Tzu in The Art of War
En finir avec la démo ?
Après nous être occupé dernièrement du Scrum Master, j’aimerais maintenant retourner vers les éléments, cérémonies et artéfacts, constitutifs de Scrum. Vous vous rappelez peut-être à cet égard que nous avions abordé le product backlog l’an dernier ?
La démo, puisqu’il le faut…
La démo ? C’est bien !
La démo, c’est vraiment bien !
La démo, c’est du feedback. Et le feedback c’est le nerfs de la guerre des projets agiles.
Alors, si c’est tellement bien, pourquoi ne fait-on cela qu’une fois par itération ? On devrait faire ça tout le temps !
Mais ce n’est pas le cas.
En fait, comme nous le rappellent Emilie Franchomme et Caroline Damour-Nobi, on ne parle pas de démo, mais de revue de Sprint. Ou plutôt, la démo est (ou est sensée être) juste une partie de la revue de Sprint.
Un anthropologue qui butinerait d’équipe Scrum en équipe Scrum rencontrerait 2 types de populations :
- Ceux qui sont heureux d’aller à la démo.
- Ceux qui appréhendent la démo.
En fait, dans les deux cas nous avons un problème. Commençons par le premier, même s’il vous parait probablement curieux d’identifier une équipe heureuse d’aller en démo comme un problème potentiel. Mais ce cas va nous permettre de répondre au point que nous avons laissé en suspens.
La démo c’est cool, on va pouvoir montrer ce que l’on a fait !
Oui, c’est parfois (même souvent) ainsi que l’on aborde la démo : on va dévoiler ce qu’on a réalisé.
Voilà une grave erreur. Nous sommes déjà au coeur du problème. Et ce problème s’appelle “définition of done” !
J’avais abordé il y a quelques temps la question de la définition de terminé. Je vais reprendre ce point de manière légèrement différente :
L’objectif de la démo est de montrer ce qui a été terminé durant l’itération, n’est-ce pas ?
Ce qui est considéré comme terminé doit correspondre à la “définition of done”.
Donc si les utilisateurs (et à fortiori le Product Owner) découvrent en démo les fonctionnalités implémentées, nous avons un problème !
Et ce problème, c’est que la définition de terminé ignore le feedback des personnes utilisant réellement le système. Oh, bien sûr on peut toujours se dire que le trait que nous traçons dans le sable pour délimiter notre responsabilité, c’est l’implémentation du backlog, pas la valeur perçue par les utilisateurs. Ou en tout cas que l’écart de cette valeur perçue sera traité plus tard, à l’itération suivante au mieux.
Bonjour, je voudrais voir mon burndown chart
Bref, si notre objectif c’est de délivrer de la valeur et non du code correspondant à des spécifications nous avons un problème.
Illustrons cela par un bon vieux burndown chart.
Donc, si vous avez tranquillement exclus le feedback utilisateur de la définition de terminé, votre burndown ressemble à la droite en vert. Le petit détail c’est que votre définition de terminé corresponds à de la livraison de fonctionnalité, mais pas nécessairement à de la livraison de valeur.
Si la livraison de valeur est votre focus, justement, alors votre définition de terminé doit inclure ce feedback et à ce moment là votre burndown a l’allure de la courbe en rouge. C’est tout de suite moins classe.
En fait, il y a bien un processus de développement qui met à disposition l’ensemble de produit en fin de cycle de développement : le cycle en cascade !
Grâce à la démo, retrouves le charme oublié du “cycle en V” !
En stigmatisant la démo en fin d’itération, Scrum nous ouvre une brèche pour retomber dans nos vieux démons du cycle en cascade. Oh, bien sûr, telle n’est pas l’intention des géniteurs de Scrum.
En fait, la définition de terminé permet de remettre un poids du bon côté de la balance. Mais la cérémonie de la revue de sprint étant très structurante elle tend à occulter le premier.
La revue de Sprint, en fixant un point de rendez-vous en fin de sprint nous laisse penser que nous pouvons avoir un produit “en chantier” durant l’itération. Traduisez : un produit qui n’est pas stable. Une impression qui est accentuée par l’idée qu’il faut laisser l’équipe tranquille pendant l’itération. On ferme les portes, ce qui se passe pendant cette durée de Sprint ne regarde pas les autres !
Cette pente glissante se traduit par deux symptômes étroitement liés:
- Une difficulté à pouvoir montrer un produit stable à la démo. Un paradoxe !
- Un choix de l’équipe d’établir une “période de freeze” avant la démo pour corriger le tir. C’est parfois quelques heures, le plus souvent une demi-journée, voir une journée. Parfois même on augmente la dose.
Ce n’est pas une bonne façon de faire, ce ne sont pas les bonnes mesures préventives. On a juste transformé le Sprint en mini cycle en V ! Et c’est la démo qui nous a tranquillement amené là.
Oubliez la démo ! Le produit doit être stable tout le temps. Scrum nous dit de faire remonter les problèmes à la surface : supprimez la période de freeze. La démo suivante sera calamiteuse. Travaillez alors la stabilité du produit, non pas une fois par sprint, mais tout le temps.
Nous nous sommes occupé de ceux qui sont heureux d’aller en démo. Que pouvons-nous dire de ceux pour qui c’est la hantise ? Bien sûr, c’est pire !
Direction le tribunal
Parfois, la revue de Sprint, cela ressemble à ça :
Dans ces moments-là, la revue de sprint n’est plus seulement le moment les utilisateurs découvrent ce qui a été fait mais jugent et statuent sur ce qui ne va pas. Je ne parle pas ici de feedback, c’est à dire d’une dynamique où les invités de la revue de sprint aident à identifier les apports positifs et les points sur lesquels il faudra concentrer l’effort, mais d’un simulacre de revue de sprint où les utilisateurs, les consommateurs devrais-je dire, viennent noter ce qui a été réalisé.
Dans les cas extrêmes, certains des invités sont là dans le but de “prendre l’équipe en faute” ! Vous pensez que j’exagère ? Hélas non.
On ne saurait reprocher à Scrum des perversions qui ne viennent pas du framework, mais des personnes qui sont impliquées. Cela pose plusieurs questions :
- Lorsqu’une dynamique des personnes impliquées dans la définition du produit ne fonctionne pas, qui doit corriger le tir ? Le Scrum Master ou le Product Owner (car on est côté définition du produit…) ?
- Le Scrum Master doit-il fixer des protocoles plus cadrés lors de la revue de sprint si elle ne fonctionne pas correctement ?
- Est-ce une option valable de ne plus inviter une partie prenante si elle affiche sciemment une position négative ?
De temps en temps aussi, le biais ne vient pas des invités de la revue de sprint, mais de l’équipe.
Revue de sprint ou réunion de spécification
“dites-nous ce que vous voulez”. C’est ainsi qu’un Scrum Master a ainsi conclut la partie démo d’une revue de Sprint où les invités avaient été particulièrement silencieux.
Ca part d’une bonne intention. Et effectivement il faut à un moment poser la question, même s’il s’agit plus de comprendre ce dont ils ont besoin plus que ce qu’ils veulent.
Hélas cette simple phrase va changer la nature de la revue de sprint en une seconde. On n’y évoque plus ce qui a été fait, mais ce qui aurait pu être fait. C’est parfois, assez souvent même, intéressant. Cela aurait d’avantage sa place dans un atelier du type “design thinking”. Parfois ce travail d’exploration n’a pas été correctement fait et la revue de sprint en est le symptôme. Mais la revue de sprint n’est le lieu, ni pour collecter les spécifications, ni pour refaire le monde.
Micro-démo
Nous avons vu ce que nous ne devons pas faire, et pourquoi la démo de fin de sprint qui donne une odeur de cycle en V me gêne terriblement. Il est temps de voir ce qu’on peut faire.
N’attendez pas pour avoir du feedback sur les fonctionnalités, la démo de fin de sprint. La “définition of done” doit figurer le feedback sur l’utilisation de la story (que ce soit par le PO ou par les utilisateurs), pas seulement les acceptante tests. Pour cela on organise une petite démonstration impromptue dès que la story est achevée et les acceptante test sont passés. C’est ce qu’on appelle parfois la “micro démo”.
Voici la recette dans les grandes lignes:
- La micro-démo s’organise “à la volée” dès la story terminée. Pas le lendemain ou dans 2 jours, mais le jour même et si possible dans l’heure qui suit l’achèvement de la story. Avant que le développeur ou le binôme se soit replongé dans la story suivante…
- Pas de setup particulier: on fait ça sur le poste du développeur, on ne perd pas de temps à mettre des choses en place dans une salle de réunion.
- On va vite, on limite le temps imparti à 10 minutes environ. Pas de bla-bla. On exécute le scénario sur lequel on s’est mis d’accord en début de sprint. On réponds aux questions précises s’il y en a.
- S’il y a des ajustements à faire qui apportent de la valeur, l’équipe discute avec le PO de la pertinence de les prendre en compte (cela remet-il en cause le contenu de l’itération…). Si cela est pertinent, on prends ces modifications en compte et cela donnera lieu à une autre micro-démo.
- Un public limité : développeur, P.O., Scrum Master, testeur, et un ou deux utilisateurs clés s’il y a lieu. Pas plus. De toute façon la place autour du poste du développeur est limitée.
Grâce à la micro-démo, on valide non seulement le fonctionnement de la story (acceptante test), mais son utilisation. Il n’y a plus de surprise lors de la démo.
Mais alors, a-t-on encore besoin de la démo ?
La substantifique moelle de la revue de sprint
La revue de sprint, ce n’est pas seulement la démo. C’est aussi :
- Exposer la vélocité de l’équipe [Aubry12], p. 125
- Demander formellement l’acceptation du produit de l’itération [Lacey12], p. 186 ; franchement, c’est moins difficile si l’on est passé par des micro-démo avant !
- Montrer le produit à des personnes non impliquées dans la définition du produit mais qui ont besoin de constater que celui-ci progresse.
Certes, il n’y a pas que la démo dans la revue de sprint, mais quand même… Cela a-t-il toujours un sens de faire une démo dans la revue de sprint si l’on pratique les micro-démo ?
En fait, oui !
Tout d’abord c’est l’occasion de montrer le produit à des personnes que l’on ne peut toucher qu’occasionnellement, ou qui ne sont pas directement impliquées dans le produit. Ensuite, si la micro-démo permet de voir les fonctionnalités indépendamment, la démo de fin de sprint permet de mettre les pièces du puzzle ensemble et de faire des démonstrations de scénarios plus larges.
Une question de boucle de feedback
En développement agile, tout peut être ramené au niveau de la boucle de feedback. L’achèvement d’une story ne se termine pas avec la boucle de feedback des tests d’acceptance, elle doit inclure celle sur l’utilisation de cette story. Différer ce feedback à la fin d’itération, c’est créer un stock pour la fin d’itération sur lequel on risque de devoir revenir.
Les équipes travaillant en mode Kanban ou en mode mixte Kanban / Scrum tendent à mettre plus d’emphase sur le bouclage des stories, car il y a moins (ou pas) de poids sur ce qui se passe en fin d’itération. En fait, les cérémonies de fin et début d’itération traitent les éléments de travail par lots (un lot étant ce que contiendra le sprint), tandis que le Kanban travaille par flux. Et il est naturellement difficile de combiner travail par flux et travail en lots.
Alors, la démo, c’est mal ?
La démo, ou plutôt la revue de sprint s’avère une bonne chose. Elle permet :
- De montrer l’avancement du produit à un public large.
- De collecter du feedback global sur l’itération et l’état du produit.
- De mettre les pièces du puzzle ensemble
Mais il ne doit pas être l’outil qui transforme le sprint en mini cycle en V. Ne remettez pas le feedback des stories à plus tard, il doit faire partie de la “définition of done” !
Références
[Aubry12] : Scrum, le guide pratique de la méthode agile la plus populaire, 2nd édition – Claude Aubry – Dunod 2011 – ISBN : 978-2-10-056320-3
[Lacey12] : The Scrum Field Guide, practical advice for your first year – Mitch Lacey – Addison Wesley 2012 : ISBN : 978-0-321-55415-4
Note de lecture : SADT, un langage pour communiquer, par I.G.L. Technology
Note : 2 ; Rébarbatif et de peu d’intérêt
Hé oui, j’ai décidé de vous faire lire mes fonds de tiroir ! Celui-ci n’est pas le plus glorieux, je le crains. Mais au début de ma carrière, mon boss a décidé de nous faire suivre une méthode pour le développement de notre projet, et il ne connaissait que SADT ! Ci-git le livre par défaut dont j’ai fait l’acquisition pour me mettre à niveau.
Il y a d’autres méthodes au delà des méthodes objet. Celle-ci, employée dans le monde industriel (sur les automates, entre autre) s’adapte particulièrement mal aux concepts objet. Pour gâter le tout, ce livre qui se rapproche plus du mode d’emploi coréen traduit depuis le serbo-croate, n’a rien pour rendre la méthode sympathique. Voyons ce qu’il a dans les tripes.
La bête accuse un peu plus de 330 pages séparées en 11 chapitres. Mais outre le format légèrement réduit par rapport à la moyenne, il faut notre que le texte est imprimé avec une taille de police assez importante et qu’il s’émaille de tout plein de diagrammes SADT bien sympa. Ce n’est donc pas une lecture très lourde.
Le premier chapitre est une introduction de 3 pages. L’une d’entre-elle est entièrement occupée par un beau diagramme de cycle en V. On sait où on habite ! Le second chapitre est à peine plus long et introduit SADT avec un ensemble de définitions bien chiantes. Pardon ! Le 3ème chapitre rentre un peu plus dans le vif car il introduit les différents concepts et notamment les actigrammes et datagrammes, mais aussi l’équipe SADT … car il y a un concept d’équipe SADT ! Le propos n’est pas palpitant mais au moins est-il raisonnablement clair.
Le chapitre 4 compte 30 pages dont de nombreux diagrammes. On y traite le modèle SADT, donc la notation avec la sémantique associée. Il faut du courage pour aller au bout du texte, car il n’y a apparemment aucune volonté pédagogique sous-jacente ! Cela me rappelle les plus beaux manuels de référence écrits sous la menace…
Le chapitre 5 « création d’un modèle SADT » est la partie processus de la méthode, et plus exactement elle décrit les activités de « l’auteur ». C’est un processus parfaitement prescriptif et les auteurs s’évertue a bien le traiter de manière Tayloriste en décrivant de manière détaillée et décomposée ce que l’Auteur a à faire. Pas de quoi faire briller les yeux. C’est vrai pour la prose aussi, d’ailleurs.
Après les 30 pages du chapitre 5, le chapitre 6 nous offre un interlude d’une douzaine de pages sur le cycle auteur / lecteur. C’est moins pénible à lire, et pas seulement parce que le chapitre est plus court. Je ne parles pas du fond, de toute façon de ce côté, il n’y a rien à sauver.
Le chapitre 7 « comment créer un modèle SADT » couvre 90 pages. C’est simplement le chapitre le plus indigeste que j’ai rencontré dans ma carrière. Apparemment, il s’agit d’une étude de cas. Je dis apparemment, car il n’y a pas un mot d’explication (au sens littéral) simplement une suite de diagramme avec laquelle on doit se débrouiller et dont la séquence doit présenter une logique. Je pense que c’est la photocopie de ce que l’on des auteurs a du produire sur un projet (et dont il a été content car il n’a eu aucune remarque, vu que c’est illisible). Bonne affaire, on a produit une partie du livre à pas cher. Mais comment dire ? Ah oui, je sais : c’est de la merde !
A contrario, le chapitre 8 veut expliquer en 5 pages la notion de « mécanisme SADT ». 3 de ces pages sont occupés par de gros diagrammes incompréhensibles. D’ailleurs, j’ai rien compris.
Le chapitre 9 nous donne un « exemple de kit » sur 55 pages. C’est reparti pour une suite de diagrammes sans explications. C’est pas possible : ce doit être le même larron qu’au chapitre qui a produit cela. Cela n’améliore pas l’odeur de l’ouvrage.
Le chapitre 10 évoque le modèle Entité-Relation pour lever les ambiguïtés du modèle SADT. Et visiblement le marier à SADT ajoute encore à la complexité de la méthode. A moins que ce soit le propos qui ne soit confus. Mais je pense qu’en fait le problème est des deux côtés.
Le chapitre 11 est en fait une annexe qui propose quelques templates SADT, au cas où vous n’en auriez pas bouffé assez…
Je ne me suis pas marré quand je l’ai lu (car je l’ai lu !). La prose est déroulée sans aucun talent ni même une quelconque qualité d’expression. Et je ne parle pas des fameux chapitres 7 et 9 qui atteignent des sommets de nullité. J’ai oublié d’évoqué l’emploi pour le moins excessif des majuscules et du gras (et souvent des deux combinés) qui ajoutent encore un peu plus à l’illisibilité. Vous pensez que j’ai été un peu dur en notant avec un 2 ? Je pense au contraire avoir été assez sympa.
Référence complète : SADT, un langage pour communiquer – I.G.L. Technology – Eyrolles 1989 – ISBN : 9782212081855
Le fait est que l’homme qui veut agir vertueusement en toute
circonstance connaît nécessairement l’échec parmi tant d’hommes qui ne sont pas vertueux
Nicolas Machiavel
C++ en 1983…
J’ai posté il y a peu une note de lecture sur l’Annotated Reference Manual (l’ARM pour les intimes). Cela m’a incité à aller chercher plus loin. C’est ainsi que j’ai mis la main sur un document dont on devine à sa seule apparence qu’il est plutôt ancien. Je ne peux résister au plaisir, en passant, de vous livrer la photo de famille du premier meeting du groupe de travail sur C++.
Bjarne Stroustrup n’a pas tellement changé, vous allez le reconnaitre facilement !
Voici le document en question.
On ne peut pas vraiment parler de norme, ce document décrit le langage C++ d’une manière que l’on dirait aujourd’hui sommaire. Certains éléments du langage sont absent de cette version préhistorique. Les plus remarquables sont l’absence des mots-clé pour les visibilités private et protected !
Yes I can !
Note de lecture : More C++ Gems, Robert C. Martin edt.
Note : 4 ; Compilation hétéroclite
On oublie parfois que Robert Martin a été éditeur en chef de C++ durant plusieurs années ! Les articles regroupés ici sont la seconde fournée des morceaux choisis de plus de 10 ans de C++ Report ! Le premier volume était la sélection de Stanley Lippman, celle-ci vient d’un auteur ayant une sensibilité différente.
Le volume n’est pas anodin : il compte plus de 500 pages divisées en 2 parties inégales : la plus petite « diamonds from deep in the past » est la plus courte tandis que « Present day industrial diamonds » représente la portion congrue. Il y a 24 articles en tout, 6 dans la première partie et 18 dans la seconde.
Tout ne mérite pas le détour dans la première partie. Je passe très vite sur le « finite state machine » qui ne nous apprends pas grand chose, pas plus que l’article traitant des classes abstraites et de fonctions virtuelles pures. L’article de Cay Horstmann sur les smart pointers mérité définitivement plus d’attention car il traite de certains problèmes afférents à leur utilisation. A lire. De même « pointers vs references » c’est un peu du retour aux fondamentaux, mais c’est Stan Lippmann. Il faut toujours lire Stan Lippmann. L’article sur les NULL est rentré par une oreille et sorti par l’autre et la prose de James Coplien sur les patterns oublie d’être passionnante. On termine cette première partie par un article sur les patterns du regrété John Vlissides. Cela a à peine sa place ici, mais c’est tellement agréable à lire…
L’open-close principle qui ouvre la seconde partie du livre (et donc les 400 pages restantes) est bien, mais c’est du réchauffé, non seulement de C++ Report mais des propres livres de Robert Martin ! La prose de John Lakos qui suit est très longue. C’est même le monument de ce livre avec près de 90 pages, mais c’est à lire absolument. Il s’agit d’un condensé de son « large scale C++ design » et l’auteur nous y livre les stratégie de structuration de programmes pour gérer les dépendances, les temps de compilation ou de link. C’est passionnant et excellemment illustré !
Les deux articles qui suivent (taskmaster et monostate class) sont plutôt du domaine des patterns. Ils sont d’un intérêt assez moyen. Par contre celui sur les métriques ABC, sans être grandiose, nous propose une alternative intéressante au LOC. Ce n’est pas le cas du « patterns for mapping OO applications to relational database » qui est très léger et n’aurait pas dû figurer ici.
Heureusement, on arrive en terrain plus sérieux : avec Herb Sutter d’abord : les exception-safe container, c’est du lourd et on en a 30 pages ! L’anatomie de l’opérateur d’affectation, c’est du fondamental mais l’auteur creuse bien le sujet, parfait ! On est plus côté système (avec une pincée de patterns) sur cet article de Doug Schmidt sur les thread local storage. C’est du solide et ça ne se laisse pas lire comme ça. L’article de Matthew Austern sur l’exception safety fait écho à celui de Herb Sutter sur les exception-safe container. Bonne lecture aussi, j’approuve. A propos d’Herb Sutter, deux articles de cet auteur viennent à la suite. C’est du C++ pour les hommes, les vrais : lisez-les !
Je suis un peu désappointé de voir ici « external polymorphism » qui devient réellement un plat réchauffé plusieurs fois… Je passe rapidement sur le « safe deletion » qui a trait au multi-threading (mais pas terrible). Doug Schmidt, encore lui, nous parle de performances avec GPerf. Ce n’est pas de la lecture facile, hélas. L’ouvrage se conclut de nouveau par 2 articles d’Herb Sutter (à lire donc). Le second est un peu frustrant car il ne fait que 3 pages pour nous mettre l’eau à la bouche avec le langage BOOSE, une extension à C++. Mais hélas on n’en sait pas beaucoup à la conclusion de l’article !
Cette compilation manque un peu de cohérence. Il aurait fallu, à mon avis séparer les parties « pur C++ », la partie « patterns » et la partie « système ». Cela aurait déjà été plus clair. Le titre même de l’ouvrage est trompeur eut égard à la place importante consacrée aux patterns. Il aurait dû s’intituler : C++ and Patterns in C++ Gems. Bref, un problème de cohérence pour cette compilation qui se reflète dans la note. Comme je l’ai noté, il y a de bons articles, notamment ceux d’Herb Sutter, mais cet auteur a aussi ses propres ouvrages.
Bref, un ouvrage pas vraiment indispensable.
Référence complète : More C++ Gems – Robert C. Martin – SIGS books / Cambridge University press 2000 – ISBN: 0-521-78618-5
Software Freethinker 
