⚠️ Lisez cette lettre dans votre navigateur pour profiter des corrections de dernière minute Les liens marqués avec 🔒 sont accessibles seulement aux membres de M33
Méditation sur le lean
Pendant les vacances j’ai eu le temps de laisser mon esprit divaguer et revenir sur ce que j’ai appris sur le Lean au sein de M33 :
Kaizen
Lorsqu’un chercheur produit un article pour exposer une théorie, il doit l’accompagner d’une valeur “p” qui pourrait se définir ainsi :
Si mon hypothèse est fausse, quelle est la probabilité que mes expériences produisent les résultats observés ?
Cela oblige le chercheur à lister soigneusement les hypothèses alternatives, même les plus improbables. Ainsi par exemple l’expérience qui a valu le prix Nobel à Alain Aspect devait prévenir toute influence entre le montage et les photons, même si à notre connaissance il n’existe aucun tel mécanisme.
En Lean il existe un atelier que l’on appelle Kaizen dont le but est l’amélioration des process et des produits.
Lors de ces ateliers il faut analyser les problèmes et proposer des solutions en débridant sa créativité.
De mon point de vue cette démarche est similaires à celle du chercheur qui imagine les hypothèses alternatives à celle qui a sa faveur. C’est une démarche contre nos biais et préjugés.
La pensée scientifique moderne réclame qu’on résiste à la première réflexion[…]. Il faut penser contre le cerveau.
TDD = PDCA
TDD est une technique de développement qui consiste à écrire d’abord un test (qui échoue) puis à implémenter la fonctionnalité qui fera passer le test.
PDCA est un outil d’amélioration continue adopté par la méthodologie Lean qui consiste à faire une hypothèse d’amélioration et mettre en place des outils de mesure afin de la tester puis en tirer des apprentissages.
Vu sous un certain angle, le TDD est une forme de PDCA. En effet on peut faire le parallèle suivant :
Plan = Ecrire le test
C’est à cette étape qu’on défini clairement le problème à résoudre et qu’on met en place des assertions univoquesDo = Ecrire le code fonctionnel
L’objectif clairement défini en tête on implémente la solution. En fonction de l’état actuel du produit et de nos compétences l’implémentation peut être plus ou moins laborieuse et un cetain nombre de problèmes se révèlent (des dépendances imprévues, une base de code tortueuse…)Check = On arrive (généralement) à faire passer le test
Mais parfois ça a été plus difficile que ce qu’on avait anticipé 🙂
Maintenant que nos tests sont verts, on revient sur la base de code. Fort de notre compréhension améliorée on peut la refactorer pour y expliciter les connaissance acquisesAct =
git push
Une fois que notre cycle de TDD est terminé on peut partager la nouvelle fonctionnalité et la connaissance acquise avec le reste du monde en poussant notre code dans le dépôt partagé
Andon
Dans la méthodologie Lean, l’Andon consiste à ce que toute personne travaillant sur un projet puisse stopper la production dès qu’il observe un défaut afin de le corriger au plus vite et reprendre une production affranchie de ce défaut.
En pratique chez M33 l’Andon est surtout compris comme appeler quelqu’un de plus compétent sur un domaine pour nous aider à résoudre un problème précis.
Mais un Andon ne dois pas être fait n’importe comment. Lorsqu’on formule sa demande il faut :
Décrire précisément le problème à résoudre
Ce qu’on a tenté pour résoudre le problème
Les difficultés auxquelles on s’est heurté
Ainsi le demandeur doit d’abord essayer quelque chose par lui même et ainsi éventuellement résoudre son problème ou alors apprendre quelque chose. De plus il permet à la personne sollicité de gagner du temps en fournissant un maximum d’éléments pour comprendre le problème.
L’Andon est une pratique particulièrement appréciable lorsqu’elle est bien réalisé car elle participes aux principes de respect et de développement de la personne.
Le pôle de formation Craft
La formation des dev
Chez Sipios lorsque nous recrutons un dev, nous passons la première semaine à le former.
L’un des outils pour cela est la “formation commando” : un outil d’auto-formation. Une série de fiches expliquant des concepts accompagnées d’exercices afin que la recrue apprenne à son rythme.
Mais un challenge de notre métier est la rapidité de son évolution. Par conséquent cet outils devient rapidement obsolète.
Pour palier ce problème nous avons donc entrepris de moderniser les fiches ainsi que leur usage. L’idée est que au lieu de laisser notre nouveau camarade seul avec les fiches, il reviendra à son coach (tout le monde a un coach en arrivant chez Sipios) de sélectionner les fiches en fonction des compétences à renforcer et des besoins de la mission. La plupart des fiches ont un niveau basique et un niveau avancé pour plus de finesse.
Pour entreprendre ce dépoussierage j’ai le plaisir de bénéficier de l’assistance de Julien M. qui a pris ce sujet entièrement en charge 👍🙏
Indicateur DDD
L’indicateur DDD dont j’ai déjà parlé ici et là a été modifié afin de renforcer la documentation du langage ubiquitaire et aussi de donner une vision plus profonde du code par rapport à un simple pourcentage.
Le score est à présent une courbe dont voici la représentaiton sur notre projet pilote :
Pour le moment il est hasardeux de chercher à en fournir une interprétation. Nous devons récolter d’autres pièces.
Keyboard Shortcuts
Le pair programming est une pratique formidable : tout le monde y apprend un truc ou deux. Le code produit est de meilleur qualité et à terme c’est un gain de temps pour le projet. Et pour l’onboarding il n’y a pas mieux.
Mais je dois avouer que parfois je ronge mon frein quand mon camarade écrit laborieusement du code que l’IDE pourrait générer à sa place.
Afin de ne pas craquer et sauter sur le clavier du driver j’essaye de mettre au point une formation sur les raccourcis claviers.
L’ambition est de développer la productivité des équipes et encourager encore plus le pair programming (car c’est aussi un moyen diablement efficace de s’échanger des astuces sur les IDE).
La difficulté c’est que les dev ont des IDE variés (IntelliJ, VS Code, WebStorm…), des plateformes différentes (Linux, Mac et même quelques Windows) et certains personnalisent leurs raccourcis. Impossible donc de faire une sorte de cheat-sheet.
Je m’oriente donc vers l’élaboration d’un socle commun : une liste de refactorings à savoir faire sur son IDE. Puis à partir de cette liste proposer des exemples de code à refactorer uniquement au clavier avec le moins d’actions possible.
Améliorer sa pratique
Chercher un composant Angular avec l’inspecteur du browser
Lorsqu’on exécute une application Angular dans son navigateur il est parfois difficile de savoir quelle partie d’une page est sous la responsabilité de quel composant.
Les composants Angular sont insérés dans le DOM avec le selecteur indiqué dans l’annotation @Component.
Une astuce simple est de cibler l’élément dont on aimerait retrouver le composant dans l’inspecteur du navigateur :
Le composant qui le contient est le plus proche parent dans le DOM qui matche un sélecteur de notre application.
C’est une convention courante que le sélecteur soit un nom d’élément commençant par “app-”. Mais un sélecteur peut aussi être une classe ou un attribut.
⚠️ Il est important que chaque sélecteur soit unique dans votre application !
Spring Data JPA @Modifying
Lors d’une séance de PP avec MaximeP nous sommes tombé sur un apprentissage à forte valeur ajoutée.
Je veux dire par là que le le comportement de l’annotation @Modifying nous était inconnu, plutôt inattendu (non documenté dans la Javadoc 😡), et cause de bug céphalocapteur.
Quel est l’intérêt de cette annotation ?
Cette annotation est utilisée sur une méthode annotée @Query qui va alterer des entités (INSERT, UPDATE, DELETE). Sans cette annotation la méthode lève une exception InvalidDataAccessApiUsageException.
De plus elle permet de faire des requêtes DDL (mais je recommanderais plutôt d’utiliser des outils comme Liquibase ou Flyway pour ce genre de chose)
Elle permet enfin de faire des requêtes en lot plus efficacement, en 1 seule requête, tandis qu’une requête dérivée d’une méthode “deleteBy…” par exemple exécuterait 1 requête par entité !
Ou est le problème alors ?
S’il semble si peu efficace de se passer de @Modifying pour faire des modifications d’entité par lot c’est parce-que chaque entité a un cycle de vie auquel elle peut accrocher des hooks.
L’annotation @Modifying contourne ce cycle de vie. La requête est envoyée à la datasource sans passer par le persistence context.
Résultat : le persistence context devient inconsistent avec la datasource !
Y a-t-il un espoir docteur ?
Heureusement la vie est bien faite et l’annotation vient avec deux attributs qu’il va falloir mettre explicitement à true.
clearAutomaticallypermet de nettoyer le persistence contexte après exécution de la requête. Comme il est devenu inconsistent avec la datasource ça semble une bonne idée. On évitera par exemple que l’entity manager nous retourne une entité qui vient d’être supprimée à son insu.flushAutomaticallylorsque vous modifiez une entité JPA, l’entity manager ne se synchronise pas nécessairement immédiatement avec la datasource. Il peut donc arriver que si vous nettoyez (clear) le persistence context, vous perdiez des modifications sur certaines entitées qui n’ont pas encore été synchronisées. Cet attribut va forcer l’entity manager à synchroniser (flush) ses entités avant exécution de la requête.
Bien sûr si ces deux attributs étaient à true par défaut la vie serait encore mieux faite et certains développeurs auraient + de cheveux.
Veille
Le blog de Sipios fourmille d’articles passionnants sur des sujets tech variés. Vous y trouverez forcément des pépites :
TypeScript est fort avec les types (mais quel rapport avec une Jedi ?)
Maintenant vous pouvez résoudre tous les challenges :
Enfin la mesure de l’empreinte carbone est un sujet important chez Sipios.
Nous avons tenté de mettre en place le 1-byte model chez un client mais la tâche s’est révélée trop ardue.
Il existe d’autres modèles peut-être plus pratiques comme Software Carbon Intensity de la Green Software Foundation.
L’Ademe fournit également un référentiel PCR afin d’encardrer la méthodologie de mesure d’empreinte carbone.
Toujours sur le sujet de la mesure de l’empreinte carbone ce talk fait un état des lieux des calculettes fournies par les Cloud Providers (AWS, Azure, GCP, OVH, Scaleway) et autre outils du même tonneau.
Puzzler du jour
Alors combien d’étoiles avez vous collecté à l’Advent Of Code ?
Je dois admettre que mon élan fut brisé (pauvre bête !) par la 11è journée (celle avec les singes qui jouent à se balancer mes affaires). J’ai finalement trouvé la solution mais je me suis arrêté là.
Le challenge
Haa JavaScript est une source d’étonnement inépuisable.
Par exemple, si vous exécutez cette expression :
['10', '10', '10'].map(parseInt)Vous obtiendrez un résultat qui n’est probablement pas celui que vous attendiez. Et pourtant il s’explique très bien !
Le défi est donc d’expliquer le résultat observé 😃
La réponse au prochain numéro !
Hello Loic! Super intéressant comme newsletter ! Que représente l'axe des abscisses dans le graphe de DDD ?
Je suis sur téléphone donc je ne peux pas tester le puzzle mais je crois que ça a un rapport avec les radis...