Comment gérer votre dette technique ? (Un refactoring à 200.000€ expliqué par un Développeur Senior)

10 % de 100 million d'euros et bien ça fait 100000 € par an sur 2 ans ça fait donc 200000 € consacré à juste de la de dette technique c'est-à-dire qu'au lieu de vous acheter un appartement et bien vous allez devoir modifier vos lignes de code javascript la question à laquelle j'ai dû répondre il y a un peu plus de 2 ans maintenant c'est comment adresser de la dette technique avec un budget qui est aujourd'hui supérieur à 200000 €. en effet j'ai actuellement créé plus de 150 tâches techniques pour mon client actuel contrairement à ce que vous pensez et bien je ne suis pas du tout étonné après avoir rejoint un éème projet on retrouve toujours la même problématique c'est que le code qu'on a écrit jusque là pour délivrer des fonctionnalités et corriger des bugs et bien commence à nous ralentir au fur et à mesure et c'est le cas de la plupart des projets que j'ai rejoint la difficulté c'est jamais de dessiner un magnifique diagramme pour un nouveau projet qui commence sur lequel tout est possible les technos modernes vont nous sauver et cetera bien souvent c'est pas du tout ça qui se passe on est sur un projet déjà existant les gens qui ont démarré le projet sont parfois même plus là et il faut arriver à continuer à délivrer de la valeur dans entre guillemets un gros bordel et c'est d'ailleurs la problématique qu'explique Martin fouler dans son livre légendaire refactoring c'est un des problèmes majeurs dans notre industrie c'est pas de dessiner des diagrammes et la question que vous pouvez vous poser et bien c'est le paradoxe majeur du refactoring c'est pourquoi est-ce qu'on va concentrer autant d'efforts d'argent et d'énergie à bouger le code existant sans apporter de nouvelles valeurs de nouvelles fonctionnalités ou des bugs fixes pourquoi consacrer autant à simplement refactoriser le code et bien c'est une problématique de maintenabilité c'estàdire que le code que vous avez actuellement en soit il fait pas grand-chose il permet aujourd'hui à votre client de délivrer de la valeur mais ce client est lui-même en concurrence avec tout un tas d'autres entreprises qui continuent à améliorer leur produits donc un code n'est jamais fini vous êtes dans un jeu qui est infini et donc le but c'est pas d'avoir une code base qui fonctionne le but c'est d'avoir une code base qui permet d'aller vite c'est-à-dire de délivrer de plus en plus sans rien casser et le refactoring permet de donner cette vitesse en améliorant la maintenabilité donc la raison pour laquelle il y a un budget de 200000 € sur de la dette technique c'est simplement pour venir donner de la vitesse à cette code base l'image mentale qu'il faut absolument arrêter d'avoir c'est qu'il y aurait du bon code et du mauvais code je rappelle que même à très haut niveau les experts dans notre industrie sont pas forcément d'accord sur le terme bon code ou même sur des termes assez basiques en général par exemple le terme test d' intgration et bien si vous demandez à des experts influents dans notre industrie ils vont pas avoir tout à fait la même définition donc il y a bien sûr des choses sur laquell on est d'accord mais il y a des choses sur laquelles ça fait pas encore l'unanimité au niveau de l'industrie dans son ensemble donc je préfère raisonner en terme de code qui coûte cher et de code qui coûte moins cher quand vous embauchez une nouvelle personne sur votre projet est-ce qu'il vous faut 6 mois pour la former pouvoir opérer c'est très mauvais signe ou alors est-ce que en quelques jours quelques semaines cette personne peut commencer à déployer du code en production sans rien cassé c'est beaucoup mieux et donc le refactoring et c'est ce qu'on vair dans cette vidéo permet de faire baisser le coût opérationnel de votre code base le but c'est pas d'avoir un code qui marche et d'avoir un code qui va vite parce que on est dans un monde où tout bouge donc je vais vous montrer tout de suite ma stratégie pour structurer un tel budget et une telle dette technique sans devenir fou ou s'inquiéter être stressé et cetera et je structure toujours la dette technique ou même quand je fais un audit autour de trois piliers très simples qu'on va voir dans cette vidéo premier pilier de votre roadmap technique ça va être que C adding Legacy l'analogie ici c'est le saut percé vous avez tout simplement actuellement un saut percé donc vous avez beau faire des efforts courir derrière faire des refactoring à droite à gauche travailler jusqu'à 19h votre saut est percé et l'eau est en train de couler de partout et donc vous luttez entre guillemets contre le courant et vous allez simplement vous épuiser si vous ne cherchez pas d'abord à boucher les trous en effet quand vous arrivez sur un projet ou dans une équipe pour adresser la dette technique ce que vous devez bien comprendre c'est que la dette technique est en train d'être créée sous vos yeux en ce moment même donc plutôt que de commencer comme ça à lancer des refactoring vous devez tout de suite identifier les pratiques les processus les outils qui sont en place et qui ont créé cette dette technique mécaniquement qui est là aujourd'hui d'accord vous devez fixer la cause et pas les conséquences le but c'est pas de mettre un sparadra sur une fracture ouverte le but c'est que l'OS guérisse donc le piège ici c'est de se lancer trop tôt dans des chantiers alors vous avez pas encore identifié et bien tous les trous du saut percé donc je vous donne trois exemples très simples de choses à fixer avant de lancer quelqu chantier que ce soit côté refactoring premièrement travailler dans un écosystème pas à jour si vous travaillez dans un écosystème où vous êtes quatre versions majores derrière sur votre framework vos dépendances et cetera et bien tout le code que vous tapez est potentiellement déjà déprécié ou en retard et il va falloir le réécrire un jour ou l'autre sous peine de devoir laisser tomber le projet complètement à l'abandon puisqu'il peut plus être mis à jour avec l'écosystème dans lequel vous évoluez donc assurez-vous en premier lieu de travailler dans un écosystème à jour deuxièmement vous devez essayer de mettre très rapidement en place ce que j'appelle la règle une règle une automatisation vous devez regarder tout ce qui est imprécis dans le process actuel et venir consolider de manière automatique plein de règles mais qui ne ralentissent pas l'équipe exemple le linter le formatage du code des tests unitaires tout ce que vous pouvez verrouiller définitivement avec un outil automatique en C et bien faites-le comme ça plus personne n'a à y penser et vous pourrez concentrer toute l'énergie libérée sur le prochain chantier qui a apportera plus de valeur troisièmement vous devez regarder un petit peu ce que j'appelle entre guillemets les croyances fausses c'est-à-dire tout ce que les gens croient actuellement qui en bout chaîne provoque de la dette technique le but c'est pas de savoir qui a raison c'est de savoir quelles sont les croyances qui sont efficaces et beaucoup de croyances sont très contreintuitive dans le monde du code un exemple très bête ça va être d'optimiser le code pour écrire vite en utilisant beaucoup d'acronymes puisque ça fait moins de lettres à taper mais notre industrie ne fonctionne pas comme ça dans son excellent livre clean code roberc mar explique bien que 90 % du temps un développeur relie simplement le code qui existe pour pouvoir venir implémenter quelque chose et seulement 10 % du temps on va écrire donc le code ne doit jamais être optimisé entre guillemets pour celui qui écrit le code en utilisant par exemple des acronymes pour taper plus vite mais au contraire doit être optimisé pour le lecteur donc utiliser des mots qui font sens qui sont en anglais qui sont simple à relire et qui font pas des micros acrentales en permanence à chaque fois que vous lisez une ligne de code bref une fois que vous avez fait ça et bien félicitations vous avez bouché les trous c'est-à-dire que vous avez identifié et corrigé toutes les pratiques processus outils tout ce que vous voulez qui créer de la dette technique en ce moment même donc entre guillemets vous allez pouvoir commencer à travailler sans lutter contre le courant et finir par vous épuiser sans aucun résultat et la deuxième étape que j'utilise dans mes backlogs de dette technique et bien ça va être clean existing code c'est-à-dire que enfin on a plus à lutter contre le courant normalement on crée beaucoup moins de dette technique qu'avant idéalement plus du tout et on va pouvoir attaquer les chantier sur une base scène donc à ce moment-là l'analogie c'est que vous avez un saut qui est plus percé mais qui contient beaucoup d'eau sale l'avantage maintenant c'est que tous les efforts qu'on va faire et bien ils seront acquis puisque l'eau va pas couler par les trous le problème c'est qu'on se retrouve quand même maintenant avec potentiellement des chantiers à réaliser dans tous les sens dont des trucs complètement pharaoniques où on a l'impression qu'il nous faudrait 3 ans devant nous pour régler le problème donc la question ici ça va être la priorisation il va falloir prioriser parce que on peut pas du tout tout faire il faut continuer à livrer de la valeur pour le client et là-dessus la phrase que j'aime beaucoup c'est que s'il n'y a pas de raison de gratter et bien n'allez pas gratter si vous avez deux chantiers pharaoniques à démarrer et qu'il n'y en a que un qui vous gêne au quotidien et bien prenez celui-là c'est celui-là qui va vous permettre d'avoir une code base qui va plus vite et si vous avez un bout de code qui est bon pas génial mais qui fait le boulot et que personne n a touché depuis 2 ans et bien tant pis c'est pas prioritaire et ça empêche pas de délivrer de la valeur pour le moment exemple de choses que vous pouvez faire en tout cas pour nettoyer votre code exist ant et bien ce que j'adore et que je regarde en priorité c'est simplement qu'est-ce que vous pouvez supprimer en effet c'est une valeur fondamentale dans notre métier c'est la simplicité l'art de maximiser le code qui n'y a pas à écrire donc vous pouvez démarrer sur Supprimer tout le code qui actuellement ne sert à rien et au moment où vous cliquez sur Supprimer et bien vous venez de libérer de l'énergie pour tout le monde autre chose que vous pouvez faire c'est marquer des éléments comme des prced dans votre projet pour dire ben jusqu'à maintenant on faisait comme ça mais idéalement il faudrait arrêter de l'utiliser et indiquer plutôt une nouvelle solution comme ça les gens au fur à mesure qu'ils codent et bien vont basculer petit à petit vers la nouvelle implémentation puisque dans leur éditeur ils verront le code de l'ancienne implémentation qui est barré via le commentaire des prcd une autre chose très simple que vous pouvez faire c'est simplement d'appliquer le principe separation of concern grosso modo dans votre code vous avez plein de fichiers ce que j'appelle des software unit des petits bouts de morceaux de code comme ça de 50 1000 500 lignes à droite à gauche et ce que vous pouvez faire c'est simplement les remettre entre guillemets dans les bonnes couches donc vous prenez un fichier vous dites mais ça ça gère de la vue ça gère des règles métier ça gère des appels réseau back-end et simplement vous commencez à déplacer ou à redécouper pour avoir des fichiers qui gèrent des choses dans des couches données en effet tant que vous avez trop de copling entre des couches logicielles différentes et bien c'est très dur de refactoriser quoi que ce soit autre principe très puissant qu'on va utiliser pour clean vraiment notre code ça va être le query command pattern c'est-à-dire de simplement découper tout notre code soit en requête qu'on fait à un autre élément du système ce qu'on appelle une query soit une commande c'est-à-dire quelque chose qui va venir muter une structure de données et ensuite on peut faire les distinctions entre synchrone et asynchrone puisque on va avoir un traitement complètement différent en informatique vous le savez sûrement mieux que moi quand on travaille avec de l' syynchrone c'est pas du tout pareil qu'avec du synchrone c'est généralement plus compliqué on obtient donc une petite matrice très simple avec les commandes et les queries synchron pas synchrone et en découpant toutous nos traitements comme ça et bien ça va nous donner la possibilité de refactoriser beaucoup plus simplement derrière la règle forte ici c'est que une query ne mute jamais un état si vous demandez fetch username vous recevez toujours un USERNAME et celui-ci va pas se mettre à bouger si vous appelez trois fois fetch username vous recevrez bien trois fois un USERNAME bref en appliquant tous ces principes au fur à mesure que vous livrez ou en prévoyant des chantier de code et bien petit à petit vous allez pouvoir adresser la dette technique et créer ce que j'appelle un cercle vertueux puisque tout le monde arrête d'utiliser du code deprced et écrire du code qui crée de la dette et on va mettre en place un cercle vertueux c'estd qu'à chaque livraison on va écrire du code qui ne rajoute pas de la dette technique et permet de fixer celle existante donc ça c'est plutôt génial et avant de passer à la troisème étape que j'utilise pour structurer mes backlogs techniques et bien je me présente rapidement pour ceux qui sont nouveaux sur la chaîne puisqu'on est plus de 100 nouveaux développeurs par jour donc je m'appelle Simon je suis tech lead et instructeur udemi for business et mon but à travers cette chaîne c'est de faire connaître ce que j'appelle le code senior c'estàdire le code qui permet de résoudre des vrais problèmes en entreprise et ces vrais problèmes c'est la quantité de complexité que vous allez devoir gérer avec votre code là où les tutoriels s'arrêtent sur/viture/1/viture/2 et bien vous allez découvrir quand vous serez en entreprise que vous avez des problèmes beaucoup plus compliqués à résoudre et le problème c'est que quand on démarre ben on sait pas quoi faire on n'est pas équipé avec des petits tutoriels donc c'est la problématique que j'essaie de résoudre faire découvrir le code senior et vous retrouverez chaque semaine une nouvelle vidéo sur la cha à propos de ces bonnes pratiques en tout cas on passe tout de suite à la troisème étape construire les abstractions dont on va avoir besoin l'analogie de cette troisième étape et bien c'est ici que vous avez un saut qui est pas percé vous avez nettoyé l'eau mais le problème c'est que vous êtes trop lent entre guillemets vous avez un saut d'eau propre mais vous devez alimenter une ville comme Paris donc vous êtes dans la bonne direction pour adresser votre dette technique mais à la vitesse où vous allez actuellement il vous faudrait peut-être 100 ans pour tout gérer donc le sujet ici ça va être d'accélérer et une des meilleures définitions de l'abstraction et bien c'est encore roberc Martin qui nous la donne dans ses excellents livres le rôle d'une abstraction c'est d'éliminer ce qui est pas essentiel ce qui est pas important pour un client et au contraire d'amplifier ce qui est essentiel entre guillemets vous allez créer des couches d'abstraction qui vont vous permettre d'aller beaucoup plus vite avec votre code en effet si à chaque fois que dans votre code quand vous implémentez quelque chose vous allez utiliser du code existant et si pour utiliser ce code existant vous êtes obligé de lire tout ce qu'il fait de l'Intérieur puisque la signature de cette méthode ou de cette classe par exemple M le nom est pas bon ou le contrat les paramètres que vous devez passer dedans sont tellement compliqués que c'est inutilisable et bien dans ce cas vous avancez trop lentement donc un premier exemple un peu bête qui me vient en tête c'est une abstraction trop lente que vous pouvez voir à l'écran on va créer un type pour dire le genre de la personne est-ce que c'est un homme une femme ou une femme enceinte ici vous voyez qu'il y a un problème d'abstraction un peu gênant puisqu'on va venir mixer deux informations qui n'ont pas à être au même niveau d'abstraction vous avez le genre homme femme et le fait d'être enceinte ou non une femme peut être enceinte ou non mais un homme peut normalement jamais être enceinte donc vous venez de mixer des couches d'abstraction un peu bizarre dans votre logiciel et ça va être très difficile d'utiliser donc c'est quasiment quelque chose ici que vous aurez dû adresser à l'étape 2 mais c'est pour vous montrer comment une couche d'abstraction mal foutue peut ralentir tout le monde créer de la dette technique et être très désagréable à utiliser moi j'ai pas envie de travailler dans une code base où il y a ce genre de type qui a été modélisé donc pour accélérer construisez-vous des abstractions qui ont du sens c'est-à-dire qui amplifie l'essentiel et masque ce qui est pas très important pour le code client deuxième chose que vous pouvez faire dans cette troisème étape et bien c'est d'accélérer comme on l'a vu vous avancez actuellement trop lentement même si c'est dans la bonne direction donc vous pouvez identifier toutes les tâches un peu manuelle répétitive où des fois les gens se plantent et il faut recommencer et cetera il faut lancer trois commandes dans tel ordre sauf s'il y a tel truc qui se passe et cetera identifier tout ça et regarder si on peut pas juste l'automatiser le mettre dans la C et et cetera ou le faire dès queon Bude le projet pour ne plus avoir à y penser et pouvoir encore une fois libérer de l'énergie mentale pour tout le monde et se consacrer au prochain chantier plus haut niveau et autre moyen d'accélérer qui est largement sous- côté dans ce qu'on fait ça va être les compétences en effet actuellement vous opérez dans votre code base avec le niveau de compétence que vous avez pour le moment mais rien vous empêche de progresser de suivre des workshops de lire des livres d'aller à des conférences et cetera et de voir comment vous pourriez aller beaucoup plus vite ou faire mieux dans ce que vous faites actuellement un des principaux freins dans votre exécution actuelle c'est vos compétences l'exemple que je prends souvent c'est que je suis sûr que si sur mon projet par exemple actuel et bien il y avait un tech lead de chez Google avec 20 ans d'expérience qui débarquaent je suis sûr qu'il pourrait corriger quasiment la plupart de nos problèmes actuels en quelques mois alors que par exemple moi ça fait des années que j'essaie de corriger des choses et je n'y arrive pas la seule différence entre guillemets ça va être les compétences ce tech lead hypothétique a beaucoup plus d'expérience il a des connaissances sur des patterns des framework de haut niveau des stratégies refactoring dont je ne connais même pas l'existence qui nous permettrait de régler notre problème donc entre guillemets vous devez payer votre dette d'ignorance tous les jours en vous forant c'est une des manières d'accélérer qui est largement sous côté voilà en tout cas maintenant et bien vous avancez dans la bonne direction avec votre gestion de la dette technique et vous avancez suffisamment vite donc votre client sera content et puis surtout vous aussi vous allez plus opérer dans une code base qui vous fait mal à la tête donc voilà je vous ai mis un petit schéma avec les trois étapes et puis les analogies si vous voulez reprendre le sujet l'exli un collègue ou le mettre en place dans votre projet en tout cas merci d'avoir pris le temps de m'écouter j'espère que cette vidéo vous a apporté de la valeur et si c'est le cas et que vous cherchez à devenir développeur web professionnel rapidement et bien voici trois manières dont je peux vous aider gratuitement premièrement vous pouvez repasser sur la chaîne de temps en temps puisque je fais une vidéo par semaine sur un principe de con senior une pratique avancée sur la production de logiciel pas besoin de vous abonner vous repassez quand vous en avez besoin deuxièmement à terme j'aimerais interviewer des experts sur la chaîne par exemple un techlead chez Google un architecte chez Netflix et cetera et pour ça et bien plus on est nombreux sur la chaîne plus on interagit en commentaire ou avec des pouce bleu et bien plus on aura la crédibilité pour aller interviewer ces personnes et ensuite mettre la vidéo de l'interview directement sur la chaîne Youtube et enfin si vous voulez aller au-delà de la petite vidéo Youtube pour développer vos compétences et bien je propose une newsletter du code senior dans laquelle je vous envoie des petites infos des petites pépites et des nuggets directement dans votre boîte mail si ça vous intéresse vous retrouverez un lien juste en dessous de cette vidéo en description vous pouvez cliquer dessus rentrreer votre mail et vous commencerez à recevoir les premières infos très rapidement en tout cas je vous dis à bientôt pour une prochaine vidéo bon code Seigneur d'ici là Ciao