De Débutant à Expert en correction de bugs en 4 étapes

parfois et bien le bug à corriger c'est les gens dans cette vidéo nous allons voir quatre étapes suggérées par Kent Beck pour corriger un defect selon les principes de l'extrême programming rappelez-vous que chaque bug et bien c'est de l'argent perdu des développeur en dépression et des clients qui perdent confiance petit à petit dans les compétences de l'équipe vu comme ça on se rend compte que chaque bug est un gaspillage qui est un fléo pour cette industrie dans son livre eXtreme Programming et bien Ken Beck explique qu'au grand minimum 30 % du code qui est produit actuellement dans le monde et du pur gaspillage ou plus précisément un gâi total vous créez des featour qui sont finalement pas exactement s attendu vous corrigez des bugs qui en créent d'autres ou encore vous refactorisez du code que les gens comprennent encore moins que l'implémentation initiale et un des principes phar de l'extrême programming et bien c'est la simplicité c'est-à-dire cet art perdu de maximiser le travail à ne pas faire nous allons donc voir les quatre étapes recommandées par kenbeck pour minimiser complètement le nombre de bugs dans votre code base et ainsi limiter au maximum le gaspillage pour ceux qui ne voient pas ce qu'est l'extrême programming voyez-le comme l'anccêtre de l'agilité beaucoup plus orienté sur l'aspect technique du développement et comme il fallait bosser plus et mieux sans faire forcément plus de réunion et bien cette méthodologie n'a pas très bien fonctionné le business ne voyait pas la valeur que ça pouvait apporter c'est donc historiquement l'agilité qui a gagné mais les principes d'extrême programming qu'on va voir n'ont rien perdu de leur pertinence première étape recommandée par kenbeck et bien ajouter un test d'acceptance automatisé qui échoue le terme test d'acceptance peut faire peur concrètement ce que vous devez comprendre c'est que c'est un test de haut niveau sur tout le système ce qu'on appelle des tests end to end et qui peuvent être implémentés avec des technologies comme Cypress ou playwght et une fois qu'on a mis en place un test qui prouve que le code en production échoue qu'il y a bien un bug et qu'il sera attrapé par la suite on peut se demander à quoi ça sert d'aller plus loin et le problème de C tests automatisés de haut niveau c'est qu'ils ont l'air génial sur le papier et il s'agit bien d'une solution magique mais sur le papier dans la réalité ces tests end to end sont extrêmement volatiles puisqu'ils dépendent absolument de toutes les couches logicielles qu'il y a en dessous et donc ils sont non seulement très cher à mettre en place mais il coûte une fortune à maintenir puisque vous imaginez dès qu'il y a une modification qu'un développeur fait sur n'importe quelle couche du projet la base de données le front-end ou le backend et bien les tests sont potentiellement plus à j dans l'excellent livre software engineering at Google et bien les auteurs expliquent comment ils gèent cette problématique à l'échelle de Google et le chiffre qu'il faut retenir c'est 0.15 %. en effet comme on l'a vu ces tests ont un scope absolument énorme ils dépendent notamment du réseau pour la plupart et il est extrêmement courant et bien d'avoir de faux positifs dans ce genre de test ce qu'explique Google c'est que au-delà de 0.15% de faux positifs dans ces tests automatisés et bien petit à petit il devient très dur d'avoir conf confiance dans les résultats qui sont affichés si chaque jour vous consultez les résultats des tests qui ont été déployés sur le système et que vous avez 10 % de faux positifs et bien petit à petit votre confiance dans les tests va s'amoindrir et vous ne saurez absolument pas quoi faire avec les résultats des tests que vous allez avoir chaque jour vous serez obligé de repasser dessus manuellement pour faire la distinction entre les vrais bugs et les faux amis donc google estime que 0.15 % c'est la ligne rouge à ne pas franchir et pourtant de mon expérience personnelle on est souvent 100 fois au-dessus sur un projet quand je faisais du Protractor avec angular JS je me rappelle de la galère que c'était de mettre en place ce genre de test end to end chaque jour nous avions plus de 15 % de faux amis donc on était bien 100 fois au-dessus de la limite recommandée par Google et ces tests signifiaent petit à petit de moins en moins de choses et ce qu'il faut bien comprendre c'est que malheureusement la plupart des projets que vous risquez de rejoindre ont un fonctionnement des tests de type cornet de glace comme vous pouvez le voir à gauche à l'écran c'est-à-dire qu'on déploie massivement des tests end to end automatisés de haut niveau et quasiment aucun test unitaire on se retrouve donc très rapidement avec des centaines de tests qui produisent des faux amis tous les jours ce qui est recommandé par l'approche extrême programming et qui est appliqué à Google et dans la plupart des boîtes tech c'est plutôt une pyramide qu'un cornet de glace et dans ce fonctionnement là et bien la quantité de test N2N global est de 5 % c'est-à-dire que sur 100 tests vous avez 80 tests unitaires 15 tests d'intégration et seulement C qui sont des tests n2M donc ce qu'explique Ken B dans son livre c'est queune fois que vous avez mis en place un test N2N pour vérifier que le bug en production ne se reproduise plus vous n'avez pas fini vous avez fait que 5 % du travail et on passe tout de suite à l'étape 2 ajouter un test unitaire qui échoue sur votre code en production et cette étape est une de mes préférées puisque c'est celle qui va produire le plus de valeur et qui est le moins pratiqué actuellement en effet la plupart des développeurs connaissent ce schéma du Test Driven devvelopment on écrit d'abord un test unitaire et ensuite on ajoute le code pour passer le test unitaire puis on refactorise avant de livrer et cette manière de coder et bien est décrite comme l'approche la plus scientifique pour du code destiné à la production d'après marximan dans son livre code that fits your head l'auteur va même plus loin en disant que de la même manière que du code qui n'est pas versionné avec git n'existe pas et bien du code qui n'a pas une couverture de test unitaire automatisé solide et du code aussi qui n'existe pas ça peut faire très mal à entendre surtout si j'étais en train d'apprendre à coder j'aurais pas aimé entendre ça mais honnêtement c'est probablement une des PR prtique majeur qui devrait être mis en place dans notre industrie en tout cas si vous avez une architecture ou une équipe qui a les compétences pour mettre en place un test unitaire à chaque fois qu'il y a un bug en production vous avez une architecture de code qui permet cela et bien vous êtes au bon endroit je vous recommande de rester sur ce projet et de continuer à monter en compétence sur cette pratique malheureusement la plupart des projets que vous allez rejoindre n'ont pas forcément une architecture qui est testable unitairement vous avez trop de coupling vous avez des injections de dépendance dans tous les sens ou alors vous avez des fichiers de 1000 lignes qui sont impossibles à monter dans l'environnement de test ou encore du code qui n'a tellement pas de responsabilité que même si on devait écrire un test on ne sait même pas ce que le code est censé faire en dessous si c'est le cas vous avez une problématique de refactoring qui va pas être évidente du tout puisque vous allez devoir refactoriser sans avoir des tests qui vous garantissent que vous ne cassez rien en tout cas vous avez deux chemins devant vous du refactoring pour avoir du code testable et si vous avez du code testable et bien appliquez cette deuxième étape que suggère kenbec maintenant vous avez deux tests qui échouent sur votre code en production sur le bug que vous aviez au départ et il va peut-être être temps enfin dans la troisème étape qu'on va voir et bien de corriger le bug en question rappelez-vous pour le moment on a que des tests qui échouent et la troisième étape et bien c'est de modifier votre code destiné à la production pour qu'il passe les deux tests qui échouent que vous venez d'écrire ce que vous voyez à l'écran c'est la double looupe TDD et BDD TDD pour la partie test driv and development c'est la partie test unitaire qu'on vient de voir et la partie BDD c'est pour s'assurer que le comportement de votre logiciel correspond bien à ce dont as besoin l'utilisateur en ayant écrit d'abord les tests qui échouent pour le code en production puis avoir écrit le code qui permet de passer ses tests et donc de corriger le bug et bien vous pouvez avoir confiance non seulement dans le code que vous livrez aujourd'hui mais vous pouvez être aussi certain que les prochaines régressions éventuelles vont être attrapées directement par les tests entre guillemets ça va vous permettre d'avancer avec votre code dans une seule direction plutôt que de faire deux pas en avant un pas en arrière sans compter le fait que à partir de maintenant à chaque fois que que vous allez modifier votre code et bien vous allez avoir deux feedback de plus que vous allez vous prendre pour être sûr que vous n'avez rien cassé et donc ça permet d'avoir confiance qu' on avance avec ses développements et juste avant de passer à la 4è étape qui va consister à fixer les gens entre guillemets et bien je me présente rapidement puisqu'on est plus de 100 nouveaux développeurs par jour sur la chaîne je m'appelle Simon ça fait 7 ans que je suis développeur professionnel et instructeur udemi for business je forme des ingénieurs logiciel sur le framework angular depuis que j'ai 26 ans via des workshops en présentiel j'ai créé cette chaîne pour faire découvrir comment on produit du code réellement en entreprise puisque les tutoriels généralement présentent des niveaux de complexité qui sont assez réduit par rapport à ce qui vous attend réellement dans l'entreprise dans un projet en entreprise important vous allez rarement créer une todo list ou un tableau de type trlot si demain vous devez gérer un système de réservation d'avion pas sûr que ce que vous avez vu en tutoriel va vous suffire donc si ce sujet de la production de code pour résoudre des problématiques complexes vous intéressent et bien vous retrouverez une nouvelle vidéo par semaine sur la chaîne pas besoin de abonnés vous repassez quand vous en avez besoin 4ème étape comment fixer les gens l'idée ici recommandée par kenbeck ça va être de comprendre comment corriger les bugs de manière systémique au niveau de votre organisation en tant qu'équipe le but n'est pas du tout de pointer des gens du doigt bien au contraire le but est plutôt de comprendre comment le système a permis à quelqu'un d'échouer et dans son livre extremme programming et bien kenbeck raconte l'histoire de l'ingénieur Taishi Ono qui est un des premiers ingénieurs qui a rejoint Toyota juste après la Seconde Guerre mondiale à ce moment-là Toyota est une toute petite entreprise au Japon qui produit quelque chose comme 300 camions par an à la sortie de la guerre à ce moment-là les Japonais sont entre guillemets du mauvais côté de l'histoire se sont pris deux bombes atomiques sur leur territoire et doivent concurrencer les Américains sur la production automobile ce que Taishi Ono remarque c'est que ils ne peuvent pas concurrencer les Américains sur les économies d'échelle qui sont la stratégie des entreprises américaine à ce moment-là c'est-à-dire produire beaucoup beaucoup beaucoup pour pouvoir factoriser les cûts de production et augmenter le bénéfice par véhicule vendu les Japonais peuvent pas se permettre ça et Taio met au point une autre stratégie qui est l'optimisation millimétrée des coups il va donc mettre au point une technique qui est encore connue aujourd'hui qui est la technique des cinq pourquoi en effet à chaque fois qu'il y avait une problématique dans la production d'une voiture dans les usines Toyota et bien taishiono posait CIN fois la question pourquoi parfois plus parfois moins l'objectif étant de trouver la racine réelle du problème par exemple lorsqu'une machine est tombée en panne dans l'usine taishiono et son équipe ont simplement commencé à poser la question pourquoi pourquoi cette machine est tombée en panne et bien parce que le moteur a surchauffé donc deième question pourquoi le moteur a surchauffé et bien parce que le filtre à huile n'était pas suffisamment propre troième question pourquoi ce filtre à huile n'était pas suffisamment propre parce que l'intervalle de maintenance n'a pas été respecté 4è question pourquoi l'intervalle de maintenance n'a pas été respecté parce que la fréquence de maintenance et bien qui a été mis en place l'était sur une estimation apprx ximative et non sur l'utilisation réelle de la machine 5è question pourquoi la fréquence de maintenance est basée sur une estimation approximative et bien parce qu'il n'y avait aucun système réel pour traacker l'utilisation réelle de la machine donc on passait par exemple toutes les deux semaines plutôt que toutes les 1000 productions de tel vis en remontant à la source du problème tisho et son équipe ont non seulement résolu la cause profonde du problème mais ils ont également mis en place un système de suivi qui est maintenant en place et qui diminue grandement l'erreur humaine qui pouvait exister jusque- là donc dans le monde du code et bien vous pouvez faire exactement le même parallèle quand vous avez un bug vous pouvez poser la question pourquoi pourquoi est-ce qu'il y a un nouveau bug sur la page d'accueil ah ben c'est parce que John a repris le travail de Toto qui est parti en vacances deuxième question pourquoi Toto n'a pas fait le transfert de compétence à John et bien parce que Toto pensait que John en savait déjà beaucoup et il lui a donné des information à la va vite du coup pourquoi John a pas été capable de reprendre le travail de Toto et cetera et cetera et en posant suffisamment de fois la question pourquoi vous arriverez toujours à la racine du problème qui est rarement un problème d'outil technique mais qui est toujours un problème organisationnel qui devrait être fixé de manière systémique et ce que Ken blackake explique dans son livre eXtreme Programming c'est que 99 % des bugs ont en réalité une cause profonde qui est une cause organisationnelle ou humaine par exemple quelqu'un qui n'a pas été formé sur le sujet qui manque de compétence pour opérer sur la technologie XYZ ou encore une ignorance totale du produit on code dans un un projet où on connaît 10 % du métier et on ose pas poser des questions ou encore des restrictions budgétaires par exemple qui sont mis en place mais de l'autre côté on attend que les équipes réduites fassent toujours le même travail qu'avant on obtient donc des gens épuisés qui livent des choses en étant complètement cramé et qui peut commencer à créer tout un tas de bugs simplement parce que les gens sont fatigués parce qu'il y a eu des restrictions budgétaires et comme on peut le voir la racine profonde des bugs a souvent rien à voir avec le javascript ou le python alors cette manière de corriger des bugs en quatre étapes de l'extrême program est plus un idéal qu'une réalité puisque comme on vient de le voir par exemple si vous avez des bugs parce que les gens sont épuisés à cause d'une restriction budgétaire et bien vous en tant que développeur malheureusement vous ne pouvez pas faire grand-chose mais en tout cas vous pouvez déjà trouver la cause profonde la raison systémique qui a causé le bug en tout cas même si ça n'est pas réaliste ou réalisable pour vous essayez de le voir comme un objectif de long terme de corriger des bugs de cette manière puisque normalement les bugs deviendraient de plus en plus rares il seraient corrigés de manière systémique à chaque fois donc ça augmente votre confiance pour vous et votre équipe lors des développements et puis ça augmenterait aussi la confiance du client dans ce que vous livrez voilà en tout cas je suis curieux de ce que vous pensez de cette manière de corriger des bugs et est-ce que vous pensez qu'il y a au moins certaines de ces étapes que vous pourriez mettre en place dans votre manière de coder actuellement et si ça n'est pas le cas qu'est-ce qui vous empêche de le faire sur votre projet les délais la qualité du code existante et cetera en tout cas merci d'avoir pris le temps de m'écouter et si cette vidéo vous a apporté de la valeur et que vous voulez devenir développeur web professionnel rapidement et bien voici tris manière dont je peux vous aider gratuitement premièrement vous retrouverez une nouvelle vidéo sur la chaîne sur des principes de code avancé donc si ça vous intéresse vous pouvez repasser de temps en temps deuxièmement vous pouvez interagir avec la chaîne en mettant des pouces bleus ou en interagissant en commentaire ça va permettre de faire connaître la chaîne et demain peut-être d'avoir la crédibilité d'interviewer un techlit chez Google ou un architecte chez Netflix et de mettre l'interview directement sur la chaîne et enfin troisièmement vous retrouverez un lien sous la vidéo si vous êtes intéressé pour suivre un de mes workshops en présentiel directement via un Espace membre en ligne actuellement et jusqu'à fin juin vous retrouverez sur le site angularersenior.fr et bien un workshop pour vous préparer pour votre premier jour en entreprise sur javascript qui est le langage qu'on retrouve derrière la plupart des framework frontain 6 workshop sur Javascript vous intéresse vous pouvez cliquer sur le premier lien en description de la vidéo YouTube et vous laisser guider et ce workshop sera accessible que jusqu'à fin juin de cette année ensuite je le retirerai pour en mettre un autre en tout cas je vous dis à bientôt pour une prochaine vidéo bon code seior d'ici là Ciao