Comment gérer votre dette technique ? (Un refactoring à 200.000⏠expliqué par un Développeur Senior)
VloĆŸit
- Äas pĆidĂĄn 12. 06. 2024
- đšđ»âđ» DĂ©marrer votre carriĂšre de DĂ©veloppeur Professionnel :
www.angularsenior.fr/apply
***
Ătes-vous souvent confrontĂ©s Ă la "dette technique" dans votre code ?
Si c'est le cas, aujourd'hui j'ai décidé partager avec vous ma roadmap en 3 étapes simples pour mettre en place un "Backlog Technique".
Cela sera bien vu par votre client et votre employeur...
Mais SURTOUT vous allez enfin pouvoir corriger le code qui vous fait mal Ă la tĂȘte, et sauver votre santĂ© Ă moyen terme.
(Comme toujours, tout ce que je donne comme conseil a été d'abord testé dans la vraie vie.)
Bon visionnage,
Simon.
***
00:00 : Introduction
00:15 : La question de la "dette technique"
01:21 : Le paradoxe du Refactoring
02:14 : Le mauvais code vs. le bon code
03:11 : Comment créer un Backlog Technique ?
03:26 : [Pillier n°1] CUT Adding Legacy
06:46 : [Pillier n°2] CLEAN Existing Code
11:31 : [Pillier n°3] CONSTRUCT Needed Abstraction
15:23 : Un Backlog Technique sur une feuille A4
15:31 : La Newsletter du Code Senior
Je dirige une Ă©quipe de dev sur des produits legacy et j'approuve Ă 100% tout ce que vous dites, et j'encourage tout le monde Ă suivre ces conseils. Robert "Uncle Bob" Martin est effectivement un rĂ©fĂ©rence et ses vidĂ©o et livres sont vraiment utiles. Je mesure la qualitĂ© de code avec des "WTF" (what the fuck), et je dĂ©couvre avec plaisir l'Ă©quivalent français "accroc mental" bien plus reprĂ©sentatif. Merci pour la vidĂ©o, je vais la recommender (surtout le dĂ©but) Ă certaines "parties prenantes" qui ont besoin de comprendre l'intĂ©rĂȘt d'Ă©viter la dette technique comme la peste et le cholĂ©ra.
Ă votre service pour continuer la propagande sur ce sujet. đ
Ce livre est en effet la Bible du développeur. D'ailleurs j'ai mis dans mon prompt entre autre "Tu as lu clean code de Robert Martin et tu appliques tous les grands principe du livre dans tes réponses en particulier les bonnes pratiques de nommage et de factorisation du code"
@@Cracky541 Haha pareil, j'ai tendance Ă mettre tout ce qui me semble des bonnes pratiques dans un prompt/custom model ChatGPT. đ
Je te remercie pour ton excellente vidéo.
Le vrai problĂšme nâest pas dâavoir conscience de devoir refactorer et de vouloir faire lâeffort mais de savoir comment le faire pour aboutir Ă un rĂ©sultat qui change vraiment la donne.
Les points que tu mets en avant sont tout Ă fait pertinents, mais que il sâagit de les appliquer câest difficile pour beaucoup de dĂ©veloppeurs, dĂ©butants et expĂ©rimentĂ©s, car cela reste souvent trop abstrait ou sujet Ă interprĂ©tation.
La clĂ© câest effectivement de rendre les choses simples. Pour cela il faut faire la distinction entre lâexpression de lâintention avec un language le plus naturel possible genre vehicule.roule() et le code exprimant comment cette intention est rĂ©alisĂ©e avec peut ĂȘtre un language plus technique.
Attention au couplage, donc attention aussi Ă la factorisation. Vouloir factoriser a tout prix peut amener Ă un code trĂšs complexe , difficile Ă modifier ou du moins error prone. Quand câest presque pareil câest des fois juste diffĂ©rent.
Les nouveau framework Ă la mode ne vous sauvera pas, seule la structure de votre code pourra le faire.
Rendre simples les choses compliquĂ©es nâest pas facile. Ăa demande dâessayer et essayer encore dâune autre.
Et celui quâil faudra vaincre câest vous mĂȘme, il faut dĂ©passer la vision purement technique et syntaxique de la programmation et y trouver comme un moyen dâexpression. On pourrait faire lâanalogie avec lâĂ©criture dâun livre avec des lettres et ponctuations. Ce ne sont dĂ©finitivement pas les lettres et les ponctuations que vous utilisez qui en fera un chef dâĆuvreâŠ
Je plussoie votre commentaire, notamment :
1/ Attention au couplage, donc attention aussi Ă la factorisation => VRAI.
2/ La clĂ© câest effectivement de rendre les choses simples => VRAI.
3/ Les nouveau framework Ă la mode ne vous sauvera pas, seule la structure de votre code pourra le faire => VRAI
J'approuve à 100% ta présentation. souvent la dette technique s accumule, jusqu'a ce que ce ne soit plus maintenable (version du framework à l'abandon, vulnerabilité critiques) et qu il y ait une refonte complete du systeme sur une pile technologique plus récente.
Exactement... d'oĂč la fameuse "techno miraculeuse"... et on relance la roue !
Tout à fait d'accord avec toi. Il y a en plus un effet négatif quasiment jamais abordé, c'est l'aspect RH. En effet, ayant participé au processus de recrutement notamment les entretiens techniques et bien je peux dire que sur des projets avec des technologies obsolÚte il est difficile de trouver des candidats et je les comprends... Finalement, faute du nombre de candidats tu prend celui qui veut bien venir et c'est pas forcément le meilleur.
Hello Simon, une nouvelle fois merci pour cette vidĂ©o instructive ! J'ai achetĂ© Clean Code Ă Cultura le weekend dernier, ta vidĂ©o me donne envie de l'attaquer dĂšs maintenant ! đ
Une question traßne dans mon esprit depuis un petit moment : je ne sais plus dans quelle vidéo, mais je me souviens t'avoir entendu dire que tu avais beaucoup accroché avec le frontend, et ce malgré un bagage en PHP assez important. Or, quand je regarde tes vidéos, j'ai l'impression que l'écosystÚme frontend dans lequel tu gravites est finalement assez proche du backend : consommation d'API, design pattern, tableaux/objets, architecture d'un framework front...
J'ai aujourd'hui le sentiment d'ĂȘtre plus proche de l'aspect graphique du dev : design, interface, intĂ©gration... bien que j'adore le JavaScript, je me demande si prendre de la distance avec le CSS me stimulerait autant au quotidien. As-tu dĂ©jĂ eu ce sentiment ? Et d'une maniĂšre plus gĂ©nĂ©rale, as-tu le sentiment d'ĂȘtre "dĂ©veloppeur frontend" ? Ce terme semble englober tellement de concepts...
Au passage, j'adore le format type "podcast" de tes vidĂ©os, elles permettent de se concentrer sur ce que tu dis đ
Effectivement, je viens d'un background backend sur Symfony (PHP). Mais on ne s'ennuie pas non plus cÎté frontend, il y a de quoi faire aussi finalement.
Concernant ta question, effectivement, on pourrait redĂ©couper le terme "dĂ©veloppeur frontend". Disons que je me focus sur la logique qui permet de faire tourner une application web, sans ĂȘtre spĂ©cialement proche du CSS ou des APIs du navigateur. Une sorte d'intĂ©grateur Angular, ou via un autre framework. Je ne sais pas si ça rĂ©pond Ă ta question...
Aussi, qu'est-ce que tu appelles le format "podcast" des vidéos ?
TrÚs bons conseils. En revanche, interviewer des employés de Google ou Netflix ne va pas donner une représentation réaliste du métier en France.
Il faut Ă©couter les meilleurs pour devenir meilleur. Il faut aussi pas ce focaliser que sur la France, le monde est grand il y a de la place partout.
Merci pour la réponse, c'est un peu ce que j'allais dire.
Ce n'est effectivement pas reprĂ©sentatif d'une ESN moyenne en France, mais ce n'est pas pour ça qu'il ne faut pas interviewer des experts. Que ce soit dans le code dans un autre secteur d'activitĂ© d'ailleurs. đ
@@codeursenior en effet, bonne continuation à vous pour votre projet de devenir expert google (ce qui sera une formalité pour vous je pense)
@@bryanfrancois1899 OulĂ rien n'est sĂ»r, je ferai le malin quand je serai de l'autre cĂŽtĂ© ! đ
Bon code Ă vous,
Simon.
Salut Simon ! Jâaime beaucoup ce que tu propose. Peux-tu faire une vidĂ©o sur quelques conseil de lecture allant du dĂ©butant Ă lâexpert stp merci đ
Hello, oui, je me suis notĂ© de rĂ©aliser cette vidĂ©o, mais je ne pourrai pas la produire avant plusieurs mois. J'ai envie de passer du temps sur cette vidĂ©o, car les livres m'ont vraiment beaucoup aidĂ© Ă progresser, donc je veux leur rendre hommage en quelque sorte. đ
j'ai rien a dire je com pour la visibilité et recensement. tres quali pouce bleu
Merci pour votre contribution Ă l'effort de guerre !
Code that feats in your head, bonne référence, d'ailleurs l'auteur du livre Mark Seemann a un blog ou il écrit des articles.
Yep, j'adore son livre, au top.
Bon code,
Simon.
TOP
MERCI
On peut Ă©galement ajouter le nerf de tous les problĂšmes : aprĂšs le RedĂ©coupage, la GESTION DES DĂPENDANCES : de quel classe/module/package doit VRAIMENT dĂ©pendre la mienne/le mien, pour rĂ©aliser ce dont il est responsable, ni plus ni moins.
Oui vous avez tout à fait raison ! Limiter le coupling au strict minimum.. et organiser les dépenses par ordre de stabilité. Bon code !
6:18 oui, le code dot ĂȘtre optimisĂ© pour le lecteur: donc si le vocabulaire mĂ©tier est en français, alors le code doit ĂȘtre Ă©crit en français, pas en anglais pour l'offshore Ă l'autre bout du monde ...
Hello, point de vue intéressant. Codant uniquement en anglais, je ne me suis jamais posé cette question !
Ce que je vois encore trop souvent, ce sont des clients qui ne comprennent à la notion de dette technique et qui vont virer un tech lead compétent pour le remplacer par un pisseur de features jusqu'au point de non-retour.
J'ai le sentiment qu'en microservjce on Ă©vite vachement plus ce genre de soucis non ?
Je dirai que "oui" si le microservice est bien fait, et "non" si le microservice est mal fait. En fait, ma démarche est de croire plus dans les compétences que dans les technos, méthodologies ou autres frameworks.
Parmis tâes livrĂ© tu en a un prĂ©fĂ©rer ?
J'aurais du mal Ă choisir, je dirai "Code That Fits in Your Head" de Mark Seeman.
đ Bonjour bonjour, je lancĂ© un pavĂ© dans la marre. Je fuit ma petite veille quotidienne, et je constate qu'une majoritĂ© de personne qui travaillent au sein de esn , ne font pas attention au tremblementaire AI. Tout ees gens continue Ă vaencquer Ă leur occupation sans prĂ©ocuper de l'AI. Je Ă©tonnĂ© simon que toi tu n'en iarle ou que tu ne l'as pas intĂ©grer dans tes vidĂ©os. Je suis partie voir ce qui si passe chez les gros ESN et ça va etse un carnage lorsque certains esn leader dans lAI vont se dĂ©ployer au pres de leur client.
Correction par AI : "Bonjour bonjour, je lance un pavĂ© dans la mare. Je fuis ma petite veille quotidienne, et je constate quâune majoritĂ© de personnes qui travaillent au sein des ESN ne font pas attention Ă lâintelligence artificielle (IA) sismique. Tous ces gens continuent vaillamment leur occupation sans se prĂ©occuper de lâIA. Je mâĂ©tonne, Simon, que toi tu nâen parles pas ou que tu ne lâaies pas intĂ©grĂ©e dans tes vidĂ©os. Je suis allĂ© voir ce qui se passe chez les gros ESN, et ça risque dâĂȘtre un carnage lorsque certains leaders dans lâIA vont se dĂ©ployer auprĂšs de leurs clients."
Lâintelligence artificielle est en effet un domaine en pleine expansion, et son intĂ©gration dans les entreprises est un enjeu majeur. EspĂ©rons que davantage dâESN prendront conscience de son potentiel et sauront lâutiliser de maniĂšre bĂ©nĂ©fique pour leurs clients. ;-)
@@olive1782000 đđ bien jouĂ©, bonne initiative. Revenons Ă des choses sĂ©rieux, si je dis ça c'est qu'en 2007 Ă la sortie de l'iphone beaucoup de personnes pensaient que Nokia aller continuĂ© Ă dominer le monde de la tĂ©lĂ©phonie avec leur N95 N 100 etc. Et on connait la suite des Ă©vĂ©nements. La, situation se reproduit avec l'AI. Et je vois le drame arrivĂ© dans les Esn. On auras plus besoins de dev devops ops sre etc, on voudras des prompt engineering , des manager spĂ©cialisĂ© IA etc..
Bonjour, le sujet de l'IA n'est pas mis sur le cÎté, au contraire j'invite tout le monde à se familiariser le plus tÎt possible avec ces outils. J'ai réalisé une vidéo sur ce sujet si cela vous intéresse : czcams.com/video/slvvttdgmXo/video.html&ab_channel=SimonDieny-CodeSenior.
possible d'avoir un projet web react de A à Z comment ça se passe en entreprise ?
Hello, pour React non. Pour Angular oui, ce sera l'objet de la formation que je rendrai publique quand j'aurais atteint 100.000 abonnées. Bon code !
@@codeursenior donc je partage au max la page đđ„
@@henochangemichaellonzokoff6036 đ
Je ne sais pas qui a dit un jour qu'un bout de code est obsolĂšte dĂšs qu'on l'a Ă©crit.
Ce n'est pas faux. D'oĂč l'intĂ©rĂȘt d'avoir une CI (Continous Integration) pour vous assurer que votre code se base sur des dĂ©pendances Ă jour, passe les tests unitaires, le linter et le formater. Cela vous aidera Ă avoir du code moins "obsolĂšte" dans le temps. đ
Ta rĂ©flexion est trĂšs juste IMO maintenant il faut expliquer cela Ă la secte agile et devops đ car tu dois ameilliore ton code le rendre Ă©volutif corriger le bug apporter des nouvelles fonctionnalitĂ©s vit et avec joie đ€Łđ€Łđ€Łđ€Ł
Il y a sûrement d'excellents tech leads chez Google, il y en a sûrement aussi beaucoup qui sont moins bons que toi.
Câest trĂšs flatteur mais ils doivent ĂȘtre rares quand mĂȘme. đ