Telling your truth with compassion instead of delivering “constructive” criticism

Lissa Adkins

Adkins, Lissa
Publicités

Note de lecture : Working Effectively with Legacy Code, par Michael C. Feathers

Note : 9 ; Le refactoring repensé pour le legacy. Book of the year 2018 !

Appréhender la remise sous contrôle du code legacy est à mon avis une discipline à part entière. C’est en partie de l’architecture, tout en empruntant au refactoring avec une démarche de tests bien à elle. Entre autres choses. Mais peu d’ouvrages sont dédiés à la question, il faut dire que celle-ci n’est pas la plus sexy qui soit. Le livre de Michael Feathers se tient au sommet de cet édifice depuis plus d’une douzaine d’années et pour de bonnes raisons.

Michael Feathers nous propose une approche dans la ligne de l’approche extrême programming, en s’appuyant sur une vision code adossé à des tests unitaires. D’ailleurs sa définition du code legacy s’en inspire directement : du code legacy, c’est du code sans tests !

Avec 420 pages, ce n’est pas un petit volume que nous avons entre les mains. Il se découpe en 3 parties. La première d’entre-elle « the mechanics of change » est aussi la plus courte avec une cinquantaine de pages en 5 chapitres. Il s’agit bien d’une introduction assez exhaustive à l’approche que propose l’auteur et que j’appelle le « inside out ». Elle répond aux questions suivantes :

Lire la suite

Note de lecture : Traité du Zen et de l’entretien des motocyclettes, par Robert M. Pirsig

Note : 8 ; Un road-trip qui associé aventure humaine, réflexions philosophique et réparation des motos !

Le plus curieux dans ce livre, c’est le titre ! En fait, il n’est guère question de Zen, mais on y évoque bien l’entretien des motocyclettes. Ce livre, c’est un road-trip, que l’auteur entreprends avec son fils, à moto. Ou plus exactement un Chautauqua ainsi que le qualifie l’auteur. Le livre en lui-même est difficile à décrire, et je vais faire de mon mieux.

La trame de fond est le road-trip que j’ai évoqué. C’est l’aventure que l’auteur a imaginée pour renouer le contact avec son fils, entreprise qui s’avérera ardue, et leur fera traverser la moitié des Etats-Unis. Très vite on y rencontre un 3ème personnage, Phèdre, dont on finit par comprendre qu’il s’agit de l’auteur lui-même, avant son internement en hôpital psychiatrique, mais qu’il dissocie de lui-même. Phèdre à une vie, une pensée propre et surtout sa propre quête, celle de la « Qualité ». C’est d’ailleurs à ce moment que cet autre moi s’empare de l’auteur.

Les passages consacrés à Phèdre sont les plus ardus du livre, l’auteur y développe ses points de vue philosophiques, ou plutôt ceux de Phèdre. Nombre de réflexions sont toutefois réellement transposables, par exemple :

  • Les multiples évocations de la méthode scientifique et la manière dont elle peut être quotidiennement utilisée.
  • La dichotomie entre les modes « romantique » (inspiration, vision, intuition) et « classique » (structure de la pensée, approche scientifique).
  • Les divers écueils de nos modes de réflexion : blocages, freins et revers…

Lire la suite

Note de lecture : A Tour of C++, par Bjarne Stroustrup

Note : 5 ; Une introduction au C++ 2011, qui se lit mieux si on comprend déjà quelque peu le langage…

Une mise à jour de mes connaissances sur les dernières évolutions du langage : voilà ce qui étaient mes attentes concernant ce livre. Un livre fort court avec seulement 170 pages, ce qui me convenait parfaitement. D’ailleurs quand je dis « dernières évolutions du langage », c’est une façon de parler : j’ai bien attendu l’année de la norme 2017 pour lire un livre sur la norme 2011…

Le texte est bien découpé : les 170 pages sont réparties en 14 chapitres, chacun adressant un thème particulier du langage. Le premier couvre les « basics » sur 14 pages, j’y apprends quand même plusieurs nouveautés : le nullptr qui remplace null et la syntaxe for range permettant l’itération implicite sur des containers, comme en Java. Mais aussi l’inférence de types avec auto et l’initialisation des variables avec les accolades au lieu des parenthèses (on continue par ailleurs à utiliser celles-ci, tout n’est pas clair…). De petites (et moins petites) choses, mais de bonnes choses. Seulement 6 pages pour les « User defined types » du chapitre 2. Il faut dire que l’on n’a pas encore abordé les classes. Ici la nouveauté réside dans les class enums qui permet de typer ceux-ci. Là aussi on se rapproche du Java, mais sans pour autant pouvoir faire autant de choses avec. Dommage d’y consacrer moins d’une demi-page.

Lire la suite

Note de lecture : Understanding A3 Thinking, par Durward K. Sobek & Art Smalley

Note : 7 ; Pour donner du sens à la « pensée A3 », en conservant l’austérité du Lean !

Ne vous y trompez pas : le format de cet ouvrage est certes réduit, il ne prendra guère de place sur l’étagère… mais le contenu est consistant et demande à prendre son temps pour être consommé !

Ne vous y trompez pas : on y évoque le A3, mais ce n’est pas une explication de texte, en tout cas pas seulement. Comme le titre l’indique, il s’agit avant tout de comprendre la pensée A3, comment il s’inscrit dans une démarche et une logique PDCA. C’est d’ailleurs une trame récurrente du texte : superposer au A3 cette démarche PDCA.

160 pages et 8 chapitres, c’est tout ce qu’il faut pour venir à bout des objectifs énoncés ci-dessus. Le premier d’entre-eux est fort court avec 8, et c’est le PDCA qui nous est servi en guise d’introduction. C’est la philosophie Toyota que les auteurs tentent de nous faire toucher du doigt. Ils réussissent au minimum à nous donner l’envie de lire « The Toyota Way » ! Les 11 pages du second chapitre sont clés pour la suite, car il s’agit de la pensée A3 résumée en 7 éléments. Je ne vais pas les énoncer ici. Si je dois en retenir 3, je dirais : objectivité (résumé par l’approche scientifique), synthèse et vue systémique.

Lire la suite

Note de lecture : Le Mentoring Minute, par Ken Blanchard & Claire Diaz-Ortiz

Note 6 ; Les clés du mentoring, version succincte mais hélas un peu superficielle…

Dans la veine des autres « ouvrages minutes », celui-ci nous invite, par le truchement de deux personnages, à découvrir l’art du mentoring. C’est une bonne introduction au sujet. C’est un court opuscule d’environ 140 pages en petit format. L’approche « story telling » aide à en faire un texte qui s’avale très rapidement.

La relation de mentorat est différente de la relation de coaching, il s’agit d’une posture plus haute sans être infantilisante. Dans ce récit, le mentoré traverse une crise de doute qui l’empêche de dicerner le prochain pas à faire. Le mentor est quelqu’un de très expérimenté qui cherche à faire profiter de son expérience à de plus jeunes. Mentor et mentoré profitent tous deux de cette relation et c’est un des points qui est mis en relief ici. Alors qu’en coaching, le coaché doit lui-même trouver son chemin, le mentor peut proposer des possibilités, éclairer le mentoré de son expérience, mais il ne doit pas lui imposer une issue toute prête.

Coaching et mentoring partagent cependant des traits communs : dans les deux cas il est nécessaire de définir la mission. Un climat de confiance doit s’établir entre les deux parties, sans cela rien n’est possible. Enfin dans les deux cas l’accompagnement s’organise en terme de rythmicité et de mode opératoire.

Lire la suite

Note de lecture : Kanban pour l’IT 2nd édition, par Laurent Morisseau

Note 7 ; Toujours aussi (et même encore plus) complet avec une certaine austérité, mais un style en progrès.

J’avais trouvé la 1ère édition de ce livre excellente, quoique d’un style un peu rugueux. C’est avec un certain intérêt que je me suis lancé dans la lecture de cette nouvelle édition. Allait-elle montrer une amélioration ? Les habitués de mes notes de lecture savent que pour conserver la même note, un ouvrage doit se montrer un peu meilleur que son édition précédente. Et voilà que j’ai déjà cassé le suspens !
La précédente édition accusait 22 chapitres sur 215 pages, celle-ci prends de l’embonpoint avec 272 pages pour 31 chapitres ! On est donc très loin de la mise à jour cosmétique ! Voyons cela.

La première partie « les concepts de la méthode Kanban » est à peine plus longue que précédemment : 35 pages contre 27, mais on passe de 3 chapitres à 5, seuls les deux derniers étant repris. Le premier chapitre a lui-même changé, « les enjeux de Kanban » nous dresse les grands objectifs de l’approche de manière moins académique qu’avant. Le second chapitre « la méthode Kanban » est une sorte de teaser pour le reste du livre, nous proposant les éléments clés en version hyper-raccourcie. « Définir le flux tiré » est aussi extrait de l’ex-chapitre 1, même s’il ne fait que quelques pages, cet élément clé de Kanban méritait bien son propre chapitre.

La seconde partie change de titre dans cette nouvelle édition. « Concevoir et utiliser le système Kanban » compte 9 chapitre contre 17 précédemment, avec un chapitre 5 devenu chapitre 7 et chapitre 8. La troisième partie de la nouvelle édition « étudier et améliorer le système Kanban » poursuit l’ex-seconde partie à compter du chapitre 12. Il y ajoute un chapitre 19 « diminuer les délais par la résolution de blocages », court mais proposant une gestion pertinente des bloqueurs. Nouveau également, le chapitre 21 « évaluer son système Kanban » semble issu de l’expérience de l’auteur. Il nous propose un radar amputé de questions-clé permettant d’établir un niveau de maturité sur 6 axes. Le chapitre 23 (ex-chapitre 18) a droit à une évolution cosmétique passant de « résultat » à performance, ce qui change peu de choses pour moi. Le dernier chapitre de cette partie se voit alléger par rapport à la version d’avant : la partie consacrée au modèle Cynefin disparait !

Lire la suite

Note de lecture : Writing Great Specifications, par Kamil Nicieja

Note : 4 ; Dans la continuité du « specification by example » de Gojko Adzic, mais bien moins brillant.

Cet ouvrage est dédié à l’écriture de cas de test en Gherkin. Mais pas n’importe comment. Il s’inscrit dans la continuité du « specification by example » de Gojko Adzic qui a d’ailleurs préfacé le livre. En fait d’écriture de cas de test, l’auteur préfère évoquer l’écriture de spécifications (le livre a d’ailleurs changé de titre en cours de route), comme son devancier.

Il y a des variantes à la grammaire Gherkin, l’auteur a fait le choix de cibler celle supportée par Cucumber, bien qu’il fasse allusion à d’autres outils de temps à autre. De toute manière, l’outil n’est pas le propos du texte, ni même l’implémentation des scénarios. C’est bien de leur écriture dont il est question. Pour cet objectif, le texte accuse 250 pages structurées en 11 chapitres réparties sur 2 parties. La première d’entre-elle, regroupe les 6 qui suivent l’introduction et occupe 140 pages.
L’introduction justement, est là pour camper le décor. Il s’agit d’un chapitre plutôt dense, puisqu’il accapare à lui seul 30 pages. L’auteur y développe les définitions qui seront utiles par la suite, les anti-patterns de spécification et surtout sa démarche SBE. Mais que tout cela est verbeux ! Malheureusement, il en sera de même pour la suite.

En ouverture de la 1ère partie « Writing executable specifications with examples », le chapitre 2 évoque sur un peu plus de 20 pages l’articulation entre la couche de spécification et la couche d’automatisation. L’objectif du propos n’est pas franchement clair. J’ai l’impression que l’auteur tente de faire une introduction au ralenti. La véritable introduction est au chapitre 3, elle nécessite 25 pages et introduit tout à fait convenablement la syntaxe et les règles d’écriture qu’y surimpose l’auteur. C’est bien, juste trop volubile par rapport à la quantité d’information délivrée.

Lire la suite