𝗝’𝗮𝗶 𝘃𝘂 𝘂𝗻 𝗷𝘂𝗻𝗶𝗼𝗿 𝗽𝗹𝗲𝘂𝗿𝗲𝗿 𝗱𝗲𝘃𝗮𝗻𝘁 𝘂𝗻 𝗳𝗶𝗰𝗵𝗶𝗲𝗿 𝗵𝗲𝗹𝗽𝗲𝗿𝘀.𝘁𝘀 Il faisait 2 831 lignes. Et contenait… 143 fonctions. Le pire ? Personne n’était vraiment choqué. Dans beaucoup d’entreprises, le code propre est un mythe. Voici pourquoi : 1️⃣ 𝗟𝗮 𝗱𝗶𝗰𝘁𝗮𝘁𝘂𝗿𝗲 𝗱𝘂 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆 Quand tout doit sortir "hier", les bonnes pratiques sont les premières victimes. Le refactoring ? "On verra plus tard." Spoiler : ce "plus tard" n’arrive jamais. 2️⃣ 𝗧𝘂𝗿𝗻-𝗼𝘃𝗲𝗿 𝗲𝘁 𝗲́𝗾𝘂𝗶𝗽𝗲𝘀 𝗵𝗲́𝘁𝗲́𝗿𝗼𝗴𝗲̀𝗻𝗲𝘀 Chaque nouveau développeur ajoute sa touche… sans contexte, sans relecture, sans transmission. À la fin ? Une cacophonie technique. 3️⃣ 𝗗𝗲𝘀 𝘀𝘁𝗮𝗻𝗱𝗮𝗿𝗱𝘀... 𝘀𝘂𝗿 𝗹𝗲 𝗽𝗮𝗽𝗶𝗲𝗿 𝘀𝗲𝘂𝗹𝗲𝗺𝗲𝗻𝘁 Les conventions existent, mais qui les lit ? Qui les met à jour ? Qui les applique ? Réponse : rarement les devs en feu à 2 jours d’une release. 4️⃣ 𝗟𝗮 𝗱𝗲𝘁𝘁𝗲 𝘁𝗲𝗰𝗵𝗻𝗶𝗾𝘂𝗲 : 𝗹’𝗲́𝗹𝗲́𝗽𝗵𝗮𝗻𝘁 𝗾𝘂’𝗼𝗻 𝗻𝗼𝘂𝗿𝗿𝗶𝘁 Chaque raccourci creuse un peu plus. On le sait. On l’accepte. On l’ignore. 5️⃣ 𝗙𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗲 𝗻𝗲́𝗴𝗹𝗶𝗴𝗲́𝗲 Clean Architecture, SOLID, TDD ? Pas le temps. Pas de budget. Pas prioritaire. Donc ça reste flou… voire perçu comme un luxe de sénior. 6️⃣ 𝗘𝗺𝗽𝗶𝗹𝗲𝗺𝗲𝗻𝘁 𝗱𝗲 𝗰𝗼𝘂𝗰𝗵𝗲𝘀 𝘁𝗲𝗰𝗵𝗻𝗶𝗾𝘂𝗲𝘀 Un jour tu es sur un framework de 2014, le lendemain tu pilotes 3 APIs externes en mode panique. Tout est collé. Rien n’est pensé ensemble. 7️⃣ 𝗟𝗮 𝘃𝗶𝘀𝗶𝗼𝗻 𝗽𝗿𝗼𝗱𝘂𝗶𝘁 𝗰𝗲𝗻𝘁𝗿𝗲́𝗲 𝘂𝗻𝗶𝗾𝘂𝗲𝗺𝗲𝗻𝘁 𝘀𝘂𝗿 𝗹𝗲𝘀 𝗳𝗼𝗻𝗰𝘁𝗶𝗼𝗻𝗻𝗮𝗹𝗶𝘁𝗲́𝘀 "Ce ticket doit passer." "Ce bug peut attendre." Et le code devient lent, fragile, et toxique. 𝐐𝐮𝐞 𝐟𝐚𝐢𝐫𝐞 𝐝𝐚𝐧𝐬 𝐜𝐞 𝐜𝐡𝐚𝐨𝐬 ? ◾ Rendre les normes vivantes (outillées, commentées, visibles) ◾ Dédier du temps réel à la dette (refacto planifié ≠ dette fantôme) ◾ Organiser la transmission (revues croisées, pair coding, doc vivante) ◾ Encourager les revues de code : Deux paires d’yeux valent mieux qu’une. ◾ Prioriser la montée en compétence (talks, mentors, dojos) ◾ Réserver du temps tech dans chaque sprint (sinon il disparaît) 𝗟𝗲 𝗰𝗼𝗱𝗲 𝗰𝗹𝗲𝗮𝗻, 𝗰𝗲 𝗻’𝗲𝘀𝘁 𝗽𝗮𝘀 𝗱𝗲 𝗹’𝗲𝗴𝗼. 𝗖’𝗲𝘀𝘁 𝘂𝗻𝗲 𝗱𝗲𝘁𝘁𝗲 𝗾𝘂𝗲 𝘁𝘂 𝗰𝗵𝗼𝗶𝘀𝗶𝘀 𝗱𝗲 𝗿𝗲𝗺𝗯𝗼𝘂𝗿𝘀𝗲𝗿… 𝗼𝘂 𝗱𝗲 𝘁𝗿𝗮𝗻𝘀𝗺𝗲𝘁𝘁𝗿𝗲. 💬 Et toi, quel est le bout de code le plus absurde que tu as dû maintenir ?