Jamais le maïs n’a raison contre la poule.
Proverbe Africain
Note de lecture : Stratégies & tactiques C++, par Robert B. Murray
Note : 7 ; Des conseils d’expert sur l’utilisation avancée du C++, pour le développeur émérite. N’est toutefois pas à la hauteur des ouvrages de Scott Meyers.
Ce livre fait également partie de la série à laquelle appartiennent les ouvrages de Tom Cargill et Scott Meyers. Il s’agissait à l’époque de produire une série d’ouvrage donnant des avis d’experts. Si « effective C++ » donna non seulement naissance à une série de texte mais aussi inspira d’autres auteurs, celui-ci reste plus qu’honorable. Ecrit par le créateur de C++ Report et chroniqueur de “C++ obfuscated” dans cette même revue, ce livre s’attaque à des préoccupations très techniques : effet de bord des initialisations, de l’héritage virtuel, etc… Chaque chapitre se termine par un paragraphe “En bref” qui résume celui-ci, et par un paragraphe “Questions” qui permet au lecteur de faire le point sur ses connaissances acquises.
C’est la traduction Française que j’ai acquise. Dans cette version, le livre compte quand même 280 pages réparties en 11 chapitres.
Plus que de langage, c’est de conception dont nous parle le chapitre 1 et plus particulièrement d’abstraction (et aussi d’héritage, donc). Mais point de code C++ ou à peine, mais un bref aperçu des cartes CRC.
Long de plus de 40 pages, le chapitre 2 évoque les classes et de nombreux aspects de conception et de comportements qui tournent autour : constructeurs par défaut ou de copie (et donc forcément opérateur d’affectation), on y traite précisément la différence entre initialisation et affectation. Bien d’autres subtilités (constance, membres de type référence, etc…) sont couvertes. Je trouve un peu dommage que l’auteur, s’il présente avec brio le comportement du langage ne prenne pas plus position.
Le titre du chapitre 3 est un peu abscons car il parle de « descripteurs », en fait il s’agit de stratégies de pointeurs intelligents tels que le « copy on write » ou le comptage de références. L’utilité pratique de ces techniques a baissé avec le temps, du fait de la baisse des coûts d’allocation, de l’augmentation des tailles mémoire, mais surtout de l’avènement du multi-threading et des architectures multi-cœurs. Mais la compréhension de ces mécanismes reste un excellent exercice, lui-même excellemment expliqué.
Le chapitre 4 traite en profondeur le cas de l’héritage simple, qu’il soit public, privé… ou protégé. C’est l’un des rares ouvrages de ma connaissance traitant de ce dernier cas il est vrai pas très utile. L’auteur n’oublie pas de parler des méthodes virtuelles et virtuelles pure et explique précisément le fonctionnement des constructeurs et destructeurs dans ces situations. Rien à redire.
C’est à l’héritage virtuel qu’est consacré le chapitre 5 et seulement à cela. Bob Murray utilise abondamment les diagrammes de Venn pour expliquer les principes sous-jacents. Bien sûr on n’échappe pas à l’héritage en diamant et à son corolaire : l’héritage virtuel. Si le cas de classes de bases héritées différemment (public, protégé, privé) est mentionné, l’auteur ne rentre pas dedans plus avant, par contre il évoque la dominance d’héritage ce qui est rare. Ici aussi, l’auteur excelle à expliquer les choses en détail, mais moins à prendre position.
C’est toujours d’héritage dont il est question au chapitre 6. Ici l’auteur rentre dans des questions de conception : quand et comment concevoir pour l’héritage ? L’héritage peut-il induire des comportements erronés ? Et plus précisément comment se comportent constructeurs et destructeurs. J’ai été surpris de ne pas voir évoqué l’héritage privé dans le cas de classes fournissant des services non virtuels aux classes dérivées, et de ne pas voir trace de l’usage du « template method ».
Le chapitre 7 est le premier à évoquer les templates. On reste en zone de sécurité avec la démonstration de template sur des smart pointeurs ou sur des fonctions. Les exemples de code deviennent aussi non triviaux. A l’époque où le texte fut écrit, le comportement des templates était peu spécifié, on n’est donc pas étonné de ne pas voir l’auteur y entrer en profondeur. L’impact sur l’instanciation de code est toutefois débattue.
C’est encore de templates dont parle le chapitre 8. Faisant suite au chapitre précédent, celui-ci est entièrement dévolu aux problématiques d’implémentation de conteneurs avec des éléments homogènes ou non et aux sémantiques de conteneurs par valeur ou par référence. Une lecture franchement difficile à suivre.
On passe aux questions de réutilisabilité au chapitre 9. Ici on se situe plus au niveau des pratiques permettant la réutilisation au niveau d’une classe : celle-ci est-elle bien documentée, avec de bons nommages ? Qu’en est-il de sa robustesse, celle-ci est-elle éprouvée avec des assertions (on ne parlait pas de tests unitaires à cette époque) ? Une grande partie du chapitre est dédiée aux questions de débogage et comment rendre son code monitorable dans ces conditions. La partie consacrée aux allocateurs et à la façon de les rendre parlant est particulièrement intéressante, y compris aujourd’hui.
On ne pouvait échapper à un chapitre consacré aux exceptions. C’est le chapitre 10. La prose n’est pas exceptionnelle, si je puis dire, même si c’est la première fois qu’on y évoque le « les exceptions doivent être exceptionnelles ».
Le livre se termine avec un chapitre sur la migration d’applications vers C++. Il s’agit en fait de considérations et d’un ensemble de conseils (de bons conseils) pour ceux passant du C au C++.
Cette ouvrage est d’une lecture aisée, du moins pour le développeur déjà expérimenté en C++, et se consomme rapidement en une semaine ou deux, ce qui n’est pas la moindre de ses qualités. La petite surprise est que le texte ne se focalise pas uniquement sur le langage mais aussi sur son usage et sur une bonne compréhension de la conception : qu’est-ce qu’une bonne classe, une bonne abstraction, etc… Le texte mériterait un bon rafraichissement car il accuse maintenant 2 décennies, mais il reste de très bonne tenue.
Référence complète : Stratégies & tactiques C++ – Robert B. Murray – Addison Wesley 1994 (V.O. : C++, Strategies & Tactics ; Addison Wesley 1993 ; ISBN : 9780201563825) – ISBN : 2-87908-066-5
Origin of NoSQL
Where NoSQL comes from:
Original title and link: Origin of NoSQL (NoSQL databases © myNoSQL)
Note de lecture : Conception orientée objet, pratique de la méthode HOOD par Michel Lai
Note : 3 ; Dense et pas très engageant
Bien sûr, aller regarder aujourd’hui un texte aussi ancien n’a pas forcément beaucoup de valeur (quoique certains textes vieillissent fort peu). Non, ici la motivation est historique, car ce livre est l’un des seuls traitant de la méthode Hood, spécifiquement développée pour le langage Ada.
L’ouvrage débute par une introduction à la conception objet et aux objets, assez formelle je dois dire, mais illustrée de code Ada. Vient ensuite la présentation de la méthode Hood proprement dite. Celle-ci n’est pas didactique à mon goût, car les éléments sont présentés sous l’angle de leur définition, c’est difficile à digérer, même si je dois admettre que ce n’est certainement pas une approche superficielle. Curieusement, si des exemples de syntaxe Hood sont fréquemment fournis, ce n’est pas le cas de la notation graphique ! Petite curiosité : en plein milieu de l’ouvrage, un chapitre est consacré à un outil : HyperHood ! Généralement, ce genre de chapitre est mis en fin d’ouvrage, voir en annexe, mais comme on dit : on va survivre à ça. La lecture reprend avec un chapitre complémentaire sur la méthode, que j’aurai vu personnellement en tête d’ouvrage, car elle illustre (enfin) la méthode avec un cas d’utilisation : le poste de conduite d’une voiture. Hood+ et H+ complètent le tour d’horizon de la méthode avec ce faisant un retour au style rébarbatif, accompagnés de chapitres sur des métriques et des retours d’expérience.
On ne saurait prétendre que ce livre est creux : au contraire, il y a pas mal de matière, c’est même un peu dense à la matière d’un porridge. Et tout aussi indigeste, d’ailleurs. Si vous souhaitez vous cultiver, et avoir juste une idée de Hood, vous trouverez ce livre peu engageant : il n’y a pas de doute, pour rentrer dans ce livre, il faut de la volonté. Je soupçonne que celui-ci ait été conçu comme complément à un cours magistral, ce qui expliquerai bien des choses… Bref : pas très engageant, mail il y a pire…
Référence complète : Conception orientée objet, pratique de la méthode HOOD – Michel Lai – Dunod 1991 – ISBN : 2-10-000250-3
Il semble que le monde soit divisé entre bons et méchants : Les bons dorment mieux… mais les méchants profitent beaucoup plus de leurs heures de veille.
Woody Allen
97 Things Every Software Architect Should Know
Disponible en version papier (il a fait l’objet d’une note de lecture), cet ouvrage l’est aussi en version électronique. La licence Créative Commons nous permet de profiter de son contenu.
Un Wiki a été créé pour permettre l’élaboration de cet ouvrage collectif.
L’humour est la forme la plus saine de la lucidité.
Jacques Brel
Rencontre avec Meryem Le Saget : Entreprise collaborative et vision partagée
Cette nouvelle rencontre nous était proposée dans la continuité de celles proposées par Christine Koehler. Ce 5 Juillet, c’est donc avec Meryem Le Saget que nous avions rendez-vous.
Pourquoi construire une vision partagée ?
Le plan stratégique dans sa forme classique montre ses limites depuis un certain temps déjà. Pourtant il s’est un peu adapté au fil du temps. Ce n’est plus le bon vieux plan quinquénal, il est devenu incrémental. mais voilà :
- On ne sait pas de quoi sera fait demain.
- Il faut aussi prendre en compte l’innovation et celle-ci ne se commande pas !
Par ailleurs, les compétences clés n’existent pas seulement au comité de direction. Elles peuvent exister n’importe où dans l’entreprise. Et elles s’avèrent importantes, sinon vitales, pour éclairer le futur.
Si utiliser les bons savoirs et les bonnes connaissances / compétences sont une des motivations premières pour engager le reste de l’entreprise dans la vision partagée, ce n’est pas la seule. Cette démarche peut aussi être motivée par le souhait de voir s’engager les employés, de créer de la motivation en les rendant acteurs du destin de l’entreprise.
Que doit-on en attendre ?
L’entreprise monolithique et pyramidale vit ses dernières années. La Vision partagée est un moyen d’insuffler de l’esprit startup dans l’entreprise, en créant une latéralisation des activités. Mais ceci doit être fait avec un horizon commun et une feuille de route commune.
D’après Meryem Le Saget, cette Vision “profonde” est un processus long. Mais ce n’est pas son aboutissement qui est l’apport le plus important, mais la transformation que ce processus induit.
Avec quelle démarche
… Et tout d’abord, les démarches qui ne marchent pas ! Pour l’oratrice, les travaux de Visionning “rapides” ne marchent pas. On pense bien sûr aux innovation games et aux démarches issues de l’agilité. J’écoute donc cela avec perplexité, surtout lorsque l’on me parle d’un processus de 2 ans ou plus qui doit donner une vision pour les 10 prochaines années… C’est surtout l’absence d’un processus d’analyse préalable que reproche Mme Le Saget.
- On débute par un exercice des forces & faiblesses de l’entreprise. Quelque chose qui tourne autour du fameux SWOT.
- Ensuite, il s’agit de se livrer à un retour à l’histoire de l’entreprise. Comment a-t-elle naquit ? Quel en était le but ? En quoi a-t-elle changé, les aspirations ont-elles changé ?
C’est le retour à ce qu’on appelle l’ADN de l’entreprise, son énergie fondatrice. La Vision ne consiste pas à partir d’une page blanche.
Et comment s’y prend-t-on ?
Comme on l’a évoqué, le “deep visionning” comme l’appelle Meryem Le Saget requiert une analyse préalable de la situation actuelle via une analyse 360, qui va impliquer
- L’ensemble des collaborateurs
- Les clients, les fournisseurs et les partenaires.
On utilise les mécanismes d’intelligence collective pour cimenter cette analyse. Ne me demandez pas comment, je n’en sais rien… Quoi qu’il en soit, l’implication de l’ensemble des acteurs aide à placer la barre haut.
Il faut aussi du temps pour mener à bien cette démarche. Pour une entreprise de 15000 personnes souhaitant impliquer tout le monde, l’oratrice nous assène que le processus prendra 4 à 5 ans !
Des conditions initiales sont également nécessaires:
- Un comité de direction fort et qui ose.
- Une continuité d’action de l’équipe dirigeant qui va de pair avec une certaine stabilité.
- Une stabilité de l’actionnariat, si possible. Les rachats, ça n’aide pas !
Il faut aussi parler actions. On aboutira à 2 type d’actions:
- Des actions court terme, qui pourront être déclenchées avant l’aboutissement du processus de Vision.
- Des actions long terme.
L’aboutissement de ce processus ne se fait pas non plus de façon abstraite. Cette Vision doit être recardée en fonction des réalités de l’entreprise. Pour cela :
- Le dirigeant a le contrôle du processus à chaque moment. Ce n’est pas un “lâcher prise” imposé par le consultant. Mais il peut être consentit par le dirigeant.
- Le consultant doit parfois se faire expert pour lever des points de vigilance. Ce n’est pas un pur travail de facilitation en permanence.
“Ce n’est pas un cadeau de laisser les gens rêver de manière illusoire.”
Quand ce travail est fait au sein d’un département d’une entreprise, ces contraintes se font d’ailleurs plus fortes, car il faut prendre en compte le contexte stratégique de l’entreprise. Surtout quand celui-ci est réajusté.
Et pendant ce temps, en France…
Les entreprises Françaises sont-elles prêtes ?
Meryem Le Saget avoue un certain recul de ce côté dans l’hexagone. Deux points sont particulièrement soulevés :
- Ce travail n’est pas possible en période d’élagage des effectifs. Les conditions économiques jouent un rôle.
- Il y a une croyance dans la “pensée magique” : Ca va aller vite, etc..
Pour autant l’oratrice fait aussi valoir l’expérience Leroy Merlin, comptée dans un livre qu’elle a co-écrit avec Edith Luc et considère même cette entreprise comme les “champions du monde” en la matière. Ils travaillent leur vision sur un cycle décennal et entament aujourd’hui leur 3ème cycle !
Une première (et finalement dernière) question
Qu’est-ce qui nous interpelle dans le propos de Mme Le Saget ? Quels points vont avoir une influence sur ce que l’on fait aujourd’hui ?
Comme cela devient presque la norme, durant ces 15 minutes nous passons plutôt du temps à deviser de propos à la marge et arrivons finalement qu’avec peu de matière à la conclusion du temps :
- Vision <> prévision <> prédiction
- Le facteur temps est important … et inquiète ! Les échelles de temps paraissent extrêmement longues et pas en accord avec le rythme des innovations majeures et des ruptures.
- Lâcher prise est différent de l’utilisation de l’intelligence collective
Quelques considérations pour terminer
Le facteur temps
Dans cette démarche d’implication large, chaque personne impliquée devient stratège. Les collaborateurs entendent des signaux faibles du marché pas nécessairement (et même rarement) perçus par le comité de direction. Cela permet de voir plus loin, mais cela prends du temps.
Motivations et objectifs
Rappelons qu’il y a différentes motivations à l’implication des employés:
- Provoquer l’engagement des employés dans toutes les strates de l’entreprise.
- Besoin de “décaler” l’entreprise et donc d’utiliser toutes ses forces vives pour cela.
Concernant les objectifs, l’oratrice est affirmative: il ne doit pas y en avoir plus de 3 !
La position du consultant
Il doit faire attention à ne pas créer de position qui le mette en décalage par rapport au dirigeant. C’est le dirigeant qui conduit, qui indique là où il veut aller.
Attention cependant, dans une telle facilitation pour les grands groupes, le consultant n’a pas seulement une position basse de facilitateur. Il peut devenir expert pour mettre en garde. Il y a une responsabilité quand aux impacts du travail mené…
L’utilisation des outils technologiques
Aujourd’hui, l’impact de ces outils est qu’il permet d’engager beaucoup plus de monde dans le processus. Ainsi dans les grands groupes, on utilise un mixte entre le présentiel (qui permet la meilleur qualité d’interaction) et l’utilisation de plateformes collaborative.
This is the end
Un grand merci à Christine Koehler pour avoir permis cette rencontre, encore une fois très enrichissante !
Note de lecture : Surviving Object-Oriented Projects, a manager’s guide, par Alistair Cockburn
Note : 7 ; Beaucoup de clairvoyance et de clarté dans l’illustration de cas réels, une pertinence du texte qui résiste mais s’est érodée avec le temps.
Ce livre est rédigé de façon pragmatique, c’est probablement pourquoi il ne compte que 200 pages, volume au delà duquel il faut planifier du temps pour lire entièrement l’ouvrage. L’auteur s’est attaché à décrire comment une organisation pouvait basculer vers l’objet, les stratégies possibles et comment mettre le maximum d’atouts de son coté. Les cas de figure sont abondamment illustrés de cas de figure réels, aussi bien en succès qu’en échecs. Mais voyons plus avant son contenu. Les 200 pages de son contenu sont réparties sur 8 chapitres, mais il faut aussi évoquer les 40 pages d’annexes.
Le premier chapitre est un rappel des concepts de base de l’objet : encapsulation, polymorphisme, etc.. Rien de vraiment original, surtout en 98 où l’objet est quand même un acquis. Mais le propos a le mérite d’être clair.
Le second chapitre est plus original, car il reprend de manière très succincte 11 projets avec leurs facteurs clés de succès, d’échecs ou simplement de difficultés. Chaque cas est exposé sur moins d’une page avec un cartouche caractérisant le projet. En synthèse de ce chapitre l’auteur expose les avantages et les coûts liés aux projets objet. Le contenu est original et reste intéressant, même maintenant.
Les 40 pages du chapitre 3 sont dédiées aux choix et au setup du projet. Quel type de projet doit-on choisir pour faire son premier projet objet ? Avec quelles personnes et surtout avec quel langage ? Certains des points évoqués font largement sourire aujourd’hui. Comme par exemple la question d’un nouveau venu « périphérique » : Java. Aujourd’hui c’est surtout avec ce regard historique que l’on lira ce chapitre dont le propos a perdu de sa pertinence au fil du temps.
Au chapitre 4, on discute méthodologie et plus exactement ce que l’auteur appelle « big-M » versus « little-m » methodologies. Le big-M, ce sont les vrais processus, alors que les little-m ce sont les notations dérivant vers des méthodes/processus d’usage de ces notations. L’auteur exhorte d’abandonner le little-m et de se consacrer au big-M en statuant sur le choix d’un « big shop » ou « small shop » methodologies. Ce qui deviendra plus tard sa « cristal family of methods ». Même si l’auteur conseille de ne pas faire trop lourd, on reste quand même dans la logique rôles / activités / outils, sans compter le plan, les milestones, etc.. On reste assez loin de l’agilité quand même.
Justement, le très long chapitre 5 (près de 50 pages) est exclusivement consacré aux aspects itératifs et incrémentaux des projets. L’auteur y explique par le menu la différence entre les deux et l’avantage des les combiner et compare l’utilisation de ce mode à une « correction de trajectoire ». Cette lecture reste pertinente, même aujourd’hui.
Par comparaison, le chapitre 6 est très court, car il ne compte que 10 pages. L’auteur y évoque les phrases qu’il aurait souhaité de ne jamais entendre. Ce que j’appelle de mon côté les tartes à la crème. Certaines de ces idées reçues sont passées de mode (du moins je crois) mais d’autres ont la vie dure… On passe un bon moment à passer cela en revue !
Le chapitre 7 traite le cas des gros projets et se focalise spécifiquement sur les facteurs de réduction de risque. Là encore, il s’agit d’une lecture qui ne se démode pas.
Le dernier chapitre revisite l’un des cas exposé au premier chapitre et montre comment un échec aurait pu être évité à la lumière des éléments exposés dans le livre.
N’oublions pas non plus l’annexe A, la plus importante qui reprend sous forme de patterns, les stratégies de réduction de risques. Pas mal.
Le livre mérite sans contestation possibles son titre. Il accuse par pas mal de facettes le poids des ans. Il devient difficile de le conseiller, surtout quand de l’excellente littérature agile peut vous montrer la voie. Quelques chapitres méritent le détour, même aujourd’hui. Mais on en est plus à considérer les projets orientés objet comme de la technologie d’avant-garde…
Référence complète : Surviving Object-Oriented Projects, a manager’s guide – Alistair Cockburn – Addison Wesley / Object Technology Series 1998 – ISBN: 0-201-49834-0
