Note de lecture : Effective C++, 55 specific ways to improve yours programs and designs, 3rd edition, par Scott Meyers

Note : 10 ; Un texte à l’écriture hors pair, remis à jour en prenant en compte la STL, mais toujours irréprochable!

Je sais que vous pouvais être surpris de voir une note de relecture sur un livre dédié à C++ ici ! Sachez deux choses:

  • Ayant pratiqué C++ pendant 12 ans, j’ai un très important fond de commerce de livres, et donc de notes de lectures, sur C++.
  • Discutant l’autre jour avec une de mes collègues, nous parlions de style d’écriture de livres, et de ce à quoi ressemble un très, très bon style d’écriture. De ceux qui vous accrochent, vous passionne, vous font comprendre les choses et vous font rire, quel que soit la complexité ou l’aridité du sujet. L’exemplarité dans le domaine existe, de mon point de vue. Parmi plusieurs centaines de livres, il s’agit de cet auteur là, de ce livre là. Sans aucun doute possible.

Pour ceux qui seraient inquiets quand à cette 3ème édition de l’ouvrage, le style de l’auteur est resté égal à lui-même : un régal ! En fait, l’écriture de Scott Meyers est l’exemple même de ce que devrait être l’écriture d’un texte technique. La première fois que j’ai lu cet auteur, j’ai dû avaler le livre en 2 ou 3 jours. On s’y accroche tel en bon roman, peut-être ai-je surpris des personnes dans le métro en éclatant de rire… Il m’a fallu un moment pour que je prenne conscience, une fois la dernière page tournée, que j’avais lu un texte très technique !

Alors c’est vrai : j’ai sauté la seconde édition ! Je devrais donc me contenter de comparer cette 3ème mouture avec la seconde édition. Dix ans ont passé depuis, et l’auteur a fait bien plus qu’un simple rafraichissement des items présentés, il a effectué un travail d’introspection en réévaluant la pertinence des items (9 ont disparus), en créant de nouveaux (15 items complètement nouveaux), en fusionnant certains et en découpant d’autres. Au-delà de ce remaniement, le texte est complètement revu, eut égard au niveau des compilateurs actuels, de la librairie standard et même du futur standard, et même de la librairie Boost. On trouve aussi des inspirations nouvelles : ainsi le « copy and swap », les 3 types de garanties (basic guarantee, strong guarantee et no-throw guarantee) ainsi que le NVI idiome sont directement inspirés des « exceptional C++ » de Herb Sutter, d’ailleurs largement cité en préface.

Ce volume est plus épais que les précédents, avec ses 280 pages, en impression bicolore, s’il vous plait ! Je vois une double raison pour céder à la lecture de cette seconde édition : se rafraichir la mémoire sur les bonnes pratiques de Meyers, dans le contexte actuel du C++ et découvrir de nouvelles choses non traitées dans les éditions précédentes (dans les nouveaux items comme dans les items existant). Je vous laisse deviner la conclusion qui s’impose…

Pour ceux qui n’ont rien à faire du C++ mais rêvent de devenir auteur, et même auteur hors pair, voici ce à quoi vous pouvez vous mesurer. Je n’ai aucune meilleure référence à vous proposer.

effective-c++-3edt-Meyers

Référence complète : Effective C++, 55 specific ways to improve yours programs and designs, 3rd edition – Scott Meyers – Addison Wesley / Professional Computing series 2005 – ISBN: 0-321-33487-6

Nb : La première édition de ce livre était mon “book of the year” 1994.

Effective C++: 55 Specific Ways to Improve Your Programs and Designs


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

Note de lecture : Software Project Manager’s Bridge to Agility, par Michele Sliger & Stacia Broderick

Note : 6 ; Du PMI à l’agilité par des auteurs qui savent de quoi ils parlent !

Franchir le pas entre les approches classiques et l’agilité est un thème désormais classique. Mais la littérature traitant sérieusement de cette transition est plutôt rare. Les auteurs de ce livre ont un passé (ou un passif) lié au PMBOK plutôt sérieux, elles ont donc largement la crédibilité nécessaire pour attaquer le sujet sous cet angle.

L’agiliste accompli apprendra peu de choses à la lecture de cet ouvrage. Cela ne signifie pas pour autant que la lecture ne puisse en être profitable : si votre besoin est de pouvoir expliquer ou argumenter le passage à l’agilité aux managers classiques, voici un texte sérieux sur lequel s’appuyer !

Cela dit, la cible privilégiée du livre n’est pas celle-ci. Le texte s’adresse directement aux managers et aux « middle managers » issus de la culture de la gestion de projet en cascade. Il s’adresse directement à eux pour expliquer comment passer à l’agilité, quels en sont les bénéfices, la façon de changer les différentes pratiques et la nouvelle posture qu’ils doivent prendre dans cet environnement changé.

Sur le fond, nous avons un matériel assez dense accusant 330 pages, donc une taille de livre moyenne, mais malgré une bonne illustration du propos, cela reste du tassé du point de vue texte. Fort heureusement, les 300 pages du texte principal sont très bien découpés en 17 chapitres d’une part, eux même regroupés en 3 parties formant une progression logique. Chaque chapitre est élégamment introduit avec de surcroit une ou deux citations toujours fort bien choisies. Pour clore les chapitres, nous avons aussi chaque fois un résumé reprenant sous forme de liste à points les éléments passés en revue et une liste des références présentes dans le texte. Un travail de très bonne facture, le découpage en chapitres de moins de 20 pages en rend la lecture plaisante.

La première partie « an agile overview » consacre 3 chapitres à la présentation du monde agile au manager PMI. On commence pour les principes de l’agilité, le manifeste, etc… Bref, les grands classiques. La suite est plus originale, car on passe vers un « mapping » des principes PMI vers les principes agiles. Pour finir on fait un tour du propriétaire du projet agile (itération planning meeting, stand-up, etc…) en le comparant à son pendant PMI.

La seconde partie est la plus conséquente du livre, elle compte 9 chapitres sur 160 pages. Elle aborde les différentes facettes d’un projet en se calquant sur l’approche PMI des différents domaines à couvrir : intégration, cadrage, gestion du temps, gestion des coûts, qualité, ressources humaines, communication, gestion du risque, sous-traitance. Malgré cet angle d’attaque, jamais les auteurs n’abdiquent sur l’approche agile et ils présentent l’alternative agile avec beaucoup d’à propos et de pertinence. J’ai peu à dire là dessus, car si j’ai peu appris, le tout est fort bien ficelé.

La 3ème partie évoque la problématique de la transition. 80 pages sur 5 chapitres y sont consacré. Cela va du changement dans le type de management, à la façon de vendre l’agilité jusqu’aux écueils dans lesquels ne pas tomber. Personnellement, c’est la partie qui m’a le plus apporté.

Au final, un livre qui n’apprendra probablement rien à l’agiliste confirmé, mais pourra aider un coach à faire changer un manager classique vers une approche agile. Mais surtout, c’est probablement la meilleure lecture que l’on puisse proposer à ce dernier pour réussir son changement. Bien entendu, cela nécessite au préalable le bon état d’esprit !

soft-PM-bridge-agility

Référence complète : Software Project Manager’s Bridge to Agility – Michele Sliger & Stacia Broderick – Addison Wesley ASD series 2008 – ISBN : 978 0 321 50275 9

The Software Project Manager's Bridge to Agility


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

Maintenance des logiciels: Java, le nouveau Cobol ?

Un post de Nicolas Martignoles a récemment attiré mon attention sur un article comparant les coûts de maintenance des logiciels en fonction des langages

L’article évoque en substance des coûts élevés pour les applications Java (un facteur 4,3) par rapport aux applications Cobol. Le tout basé sur une étude de 745 applications. C# semble nager dans les mêmes eaux que Java (cela semble logique). Pire: C++ semble mieux loti que Java ! J’aime bien le C++, mais cela devient franchement troublant.

En réalité l’étude fait état d’une réalité sous-jacente bien différente.

La maturité d’une application est un facteur important !

Eh oui, une application “neuve” n’est pas forcément la meilleure sous seul prétexte qu’elle a été écrite à partir d’une feuille blanche ! Cette application est surtout plus “verte”. Je pense qu’il y a différents facteurs jouant sur l’aspect maturité:

  • Une application mature est souvent plus stable. On passe au bout d’un certain temps de demandes de changements de type évolutif à des correctifs ou de ajustements liés à des conditions d’utilisation métier qui ont évolué. Ce facteur va dans le sens d’une maintenance moins chère. Hélas ce facteur de stabilité est aussi souvent le signe d’une transition de l’application vers une phase de fin de vie.
  • Un refactoring applicatif intégrant une flexibilité liée aux évolution. Au delà du design initial d’une application parfois liminaire, les changements demandés sur une application peuvent amener les développeurs à raffiner la conception pour en rendre les changements moins douloureux. Cette approche va souvent de pair avec une amélioration de la couverture de tests. Cela ne concerne hélas qu’une minorité d’application car elle nécessite des développeurs chevronnés sensibles à ce facteur. La majorité des applications se trouve plutôt dans la seconde catégorie.
  • Une entropie des applications suite à des modifications / corrections successives. les applications qui ne sont pas vraiment sous contrôle en terme de tests ont tendance à faire l’objet de “patch”, de correctifs dits chirurgicaux sans en raffiner la conception. Au contraire cela augmente la fameuse “entropie du logiciel”, c’est à dire une dégradation de son design qui augmente la crainte des développeurs d’y toucher, augmentant à son tour les pratiques accélérant l’entropie du logiciel ! Cette spirale se termine finalement par une sclérose totale du code conduisant à la réécriture complète de celui-ci.

L’expérience des développeurs

L’article insiste à juste titre sur les pratiques managériales privilégiant une équation économique court terme. En clair: on embauche des développeurs inexpérimentés à bas salaires pour réduire les coûts. Advienne que pourra de la maintenance ultérieure !

Effectivement les équipes de développement Java sont des équipes jeunes. Il est rare d’y croiser des développeurs de plus de 10 ans d’expérience. On parle déjà de développeur sénior pour des jeunes ayant 5 ans de pratique professionnelles dans les pattes. Il est vrai que le développeur armé de 15 ans d’expérience est d’une part plus cher que son homologue Coboliste et d’autre part qu’il cherchera plutôt une position d’architecte, de team leader ou d’expert technique. Nous avons là deux cultures différentes.

En contrepartie, il n’existe probablement plus de développeur Cobol débutant. Il ne faut pas se leurre, Cobol n’est probablement pas le language le plus sexy, mais la communauté des développeurs n’est pas nécessairement formée d’idiots (en fait, il y a probablement la même proportion d’idiots chez les Cobolistes que chez les Javanais) et les 20 ou 30 ans d’expérience de ces développeurs s’ils ne sont pas un facteur linéaire de compétence les aident produire du logiciel de qualité.

java le nouveau  Cobol ?

Java est le langage majeur des nouvelles applications de gestion. Il absorbe une quantité très importante de la profession avec une disparité de qualification très importante et globalement une population peu expérimentée. A ce titre, il ressemble à ce qu’était Cobol dans les années 80. Il est d’ailleurs devenu un lieu commun de dire que Java est le Cobol des années 2000 (ou 2010 maintenant). L’article avance sans doute avec raison l’existence d’une population importante de développeur Java sans formation solide. C’est aussi ce que j’ai pu voir en entretien de recrutement.

Et C++ ?

Je persiste à dire que C++ a un coût de développement, donc de maintenance potentiellement plus élevé que Java:

  • Le langage est difficile, beaucoup plus difficile et piégeux.
  • Le langage est de bas niveau et ne possède pas l’écosystème de librairies et frameworks s’assemblant rapidement pour adresser certaines problématiques. Pour ne pas parler des outillages et de la communauté open-source…

Mais voilà, beaucoup de développeurs “moyen” ont déserté C++ dans les années 2000, la population C++ est essentiellement constituée de développeurs aguerris, expérimentés sur le langage, voir d’amoureux de ce langage ! Bref la communauté s’est professionnalisée ! Il n’est pas étonnant de constater que la qualité des conceptions et du code produit en C++ soit supérieure, moins sujette au bugs. Cela n’a rien à voir directement avec le langage, mais avec la communauté.

Un jour peut-être…

L’article est trompeur sur son affirmation, mais pas sur son contenu. Les deux facteurs premiers avancés sont réels:

  • Réécrire sans cesse les applications n’est pas une solution. Une application “verte” est toujours plus baguée. De bonne pratiques de maintenance incluant une couverte de tests unitaires et une utilisation agressive du refactoring étendent de manière très importante la durée de vie des applications jusqu’à leur réelle obsolescence technologique (au lieu de la limite de sclérose).
  • L’expérience et la compétence sont des facteurs clé. Ils prédominent largement les aspects de contexte technologiques. On le sait depuis longtemps, mais le management classique reste imperméable à ces assertions.

Ma conclusion n’est pas que Java est un mauvais langage. Sans doute en existe-t-il de meilleurs et je sais qu’il il y en a de moins bon. En fait, peu importe. Je conclue surtout que les valeurs agiles et le Software Craftmanship vont dans la bonne direction: du logiciel de qualité développé avec rigueur et compétence.

Qui a peur du Lightning Talk ?

Le Scrum Day 2012 propose, parmi ses formats de soumissions, le “lightning talk”. C’est une nouveauté et un principe simple : vous avez 5 à 10 minutes pour présenter votre sujet.

Je trouve le format attractif, aussi vais-je moi-même proposer un sujet selon ce format.

Plus simple ?

D’abord le format est attractif car il vous permet de ne préparer un sujet que pour 5 à 10 minutes. C’est en principe moins stressant que faire cet exercice pour 45 minutes ! On verra plus loin que ce n’est pas entièrement vrai.

Focus, focus …

Dans une session de 45 minutes, on a tendance à cibler un sujet, puis à explorer différentes facettes de celui-ci. Certes, on a ainsi la sensation d’avoir traité le sujet, mais n’il y a-t-il pas un aspect prédominant par rapport à un autre ? Si c’est le cas (et c’est souvent le cas) celui-ci sera finalement perdu au sein d’une présentation assez longue. Dommage !

ma proposition et mon challenge sont ainsi celui-ci: ne choisir qu’un aspect et un seul. N’aborder que celui-ci, être direct, pertinent et percutant sur ce sujet ciblé ! C’est ce que je vais essayer de faire !

Le sens de l’info

Cette idée du lightning talk (je dois l’avouer, j’ai posé à ce que ce format soit proposé) m’est venue en écoutant une émission de France Info: le sens de l’info, avec Michel Serre. Dans cette émission, Michel Serre évoque un sujet durant 6 minutes environ. Je ne cesse d’être surpris par la masse de réflexions et d’informations que Michel Serre parvient à délivrer dans un temps si court !

Certes je ne suis pas Michel Serre, mais pourquoi donc aurais-je besoin de 45 minutes pour délivrer un message moitié moins consistant. “less is more” disait Ludwig Mies (et Steve Jobs après lui). Il est temps pour moi de montrer que j’y croie

Aller à l’essentiel

J’ai un constat un peu amère à faire: j’ai assisté à de nombreuses présentations et pour une grande proportion d’entre elles j’en suis arrivé à la conclusion que le message ou l’information délivrée aurait pu l’être dans un format bien plus court !

C’est ici que l’apparente simplicité du format se transforme en réelle difficulté: comment éliminer le superflu ? Que faut-il couper pour ne pas diluer le sujet initial ?

L’exercice n’est pas facile, il sera (presque) nouveau pour moi.

Et vous, pourquoi ne présenteriez-vous pas un “lightning talk” au Scrum Day ?

Pour en savoir plus sur les Lightning Talks

  • L’article de Wikipedia dédié au sujet
  • Les Pecha Kucha sont un format très particulier de Lightning Talks en 20 minutes et 20 slides.
  • La conférence Ignite vous donnera aussi de nombreux exemples de Lightning Talks en format court (5 mn).

Note de lecture : Ship it ! A practical Guide to Successful Software Projects, par Jared Richardson & William Gwaltney Jr

Note : 4 ; Dans la continuité des « pragmatic programmers », mais en manque d’originalité.

Qu’est-ce qui fait que certaines équipes s’enlisent, tandis que d’autres parviennent à délivrer ? Cette question est le point récurent des méthodes agiles, c’est le fer de lance de cet ouvrage qui n’a donc pas grand-chose d’original à cet égard. Le texte reprend les bonnes pratiques du « pragmatic programmers », en les unissant dans un processus agile découpé en 3 sous-ensembles (formant autant de chapitres du livre :

Techniques ; Cette partie regroupe 5 pratiques : Technical Lead (en fait le chef de projet), The List (la « feature list » de Scrum), Daily Meeting (le daily meeting d’XP), Code Reviews et Code Change Notifier. Il y a peu d’originalité dans ces pratiques communes à la plupart des méthodes agiles. Toutefois la description du « Technical Lead », à la fois gourou technique et gestionnaire des hommes et des plannings me laisse perplexe, tandis que le manager est vu comme un espèce de VRP…

Infrastructure ; Cette partie regroupe 6 pratiques dont 4 sont liées à l’automatisation : Version Control, Script Builds, Write and Run Tests et Continuous Builds. On remarquera que « continuous build » et « script builds » sont sinon liés, au moins dans la continuité l’un de l’autre. Les deux dernières pratiques sont Track Features et Track Issues, là encore 2 pratiques très liées et intimement liées à « The List », mais vu sous la facette Infrastructure !

La partie Process regroupe 5 pratique liées au développement de l’architecture : Propose System Objects, Propose Interfaces, Connect Interfaces, Add Functions et Refactor Refine Repeat. Le but de cette approche est de définir une architecture par découpage n composants majeurs, puis de définir ces composants par leurs interfaces que l’on connecte ensuite, pour finalement les « étoffer » avec la mécanique. Le réfactoring ajoute la touche finale de raffinement de l’architecture.

Comme je l’ai dit au début, il y a peu d’originalité dans ce livre, même si en soi il constitue un texte valable, il a du mal à sortir du lot. Parmi les particularités, je note toutefois les itérations de longueur variable, mais de contenu fixe. Un point de vue qui, hélas, me laisse également perplexe…

ship-it-pragprog

Référence complète : Ship it ! A practical Guide to Successful Software Projects – Jared R. Richardson & William A. Gwaltney Jr – The Pragmatic Bookshelf 2005 – ISBN : 0-9745140-4-7

Ship It!: A Practical Guide to Successful Software Projects


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

Note de lecture : Applying Use Cases 2nd edition, par Geri Schneider & Jason P. Winter

Note : 9 ; Un simple raffinement d’un livre déjà excellent, mais qui va dans le bon sens.

J’ai quelques références sur les Use Cases dans ma bibliographie. Ce texte-ci est l’un de mes préférés, sinon mon préféré. Historiquement, à mon échelle, c’est par la note de lecture de la 1ère édition de ce livre que j’ai commencé ma compilation bibliographique il y a maintenant 14 ans.

C’est un ouvrage succinct (environ 170 pages hors annexes), exclusivement destiné aux uses cases, à leur utilisation, leur développements (use case scénarios, diagrammes d’activité, liens vers la modélisation), leur documentation. Le propos est très clair, très direct et bien illustré à l’aide d’un exemple développé au long du livre. La taille réduite du livre fait partie de ses qualités, la substance utile étant très importante. 

Pour cette seconde édition, je m’attendais à d’avantage d’évolutions. En fait, les auteurs ont simplement repris leur matériel de base, en le réorganisant et en mettant à jour certains concepts (relations “includes” et héritage, ainsi que cas d’utilisation subordonnés).  La partie la plus faible de l’édition précédente (documentation des cas d’utilisation) a désormais atteint la qualité des autres chapitres et certains nouveaux thèmes ont été abordés comme les Use Case “CRUD” et les exigences complémentaires. La lourde description de l’étude de cas qui encombrait un peu l’ouvrage a été rejeté en annexe ou elle figure désormais de façon plus complète. Finalement, les auteurs ont réussi le tour de force de remettre à jour cet ouvrage sans nous pénaliser de l’augmentation de volume qui en est le corollaire. Toujours excellent, donc.

Un livre que je conseille très fortement, sans arrières pensés.

applying-usecases-2

Référence complète : Applying Use Cases, second edition, a practical guide – Geri Schneider & Jason P. Winter – Addison Wesley / O.T. series 2001 – ISBN: 0-201-70853-1

Nb: La première édition de cet ouvrage était mon “book of the year” 1998

Applying Use Cases: A Practical Guide


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