Survivre avec du code legacy

Travailler sur du code legacy qui vient droit des enfers est une chose inévitable. Si ça t’est jamais arrivé crois moi quand je te dis que ça va pas tarder. Et si c’est inévitable ce qui serait bien c’est de savoir comment gérer la situation sans exploser son clavier sur la tête du voisin. Aujourd’hui je te propose d’inspirer un grand coup et de trouver des solutions pour le monstre de projet qu’on t’a filé dans les mains.



Essaye de ne pas rager

Il faut qu’on en parle tout de suite avant meme d’aborder la technique. Tu vas rager. Mais genre violent. Et c’est ça qui va te faire perdre le plus de temps. Temps que tu vas passer en plus à nager dans le caca de ce projet satanique. C’est plus facile à dire qu’à faire. Mais garder son calme devant un code legacy stupide et bâclé c’est le plus important. Déjà pour toi, personnellement, mais il faut aussi se dire que le fait de taper sur ton écran va rien arranger. De toute façon ta situation est impossible à éviter.

Car oui ce que tu as dans les mains est un projet coder avec le cul. Ce genre de projet est légion et aujourd’hui c’est ton tour de t’en occuper. C’est ta faute ? Bien sûr que non. Est-ce que t’es payé à nettoyer la merde des autres ? Oui. Ca fait partie de la vie d’un développeur. C’est pas la première fois et c’est pas la dernière fois que ça t’arrive. Maintenant entre le faire de façon méthodique pour y passer le moins de temps possible ou rager en hurlant et gesticulant dans l’open space tu as le choix.



rage


Ha et aussi je le dis en passant mais c’est super important. Essaye de rager encore moins sur les humains qui sont responsables du code legacy. Déjà parce que bah t’es au boulot et devenir toxique avec quelqu’un n’est jamais une bonne idée. Mais surtout parce que c’est pas en vomissant sur les gens qu’ils vont mieux bosser. Au mieux ils vont t’ignorer et tu vas perdre des infos au pire tu vas te faire des ennemis. Aller on respire et on s’intéresse au code.



Comprendre l’horreur

La première erreur que tu vas faire est de ne pas prendre le temps de comprendre le pourquoi. Il faut changer d’état d’esprit. Tu es un archéologue professionnel envoyé dans les sous-sols de l’enfer. Un endroit ou même Satan en personne ne va plus. Tu vas être le témoin d’atrocités que jadis des âmes damnées ont fait faire à la machine. Il est de ton devoir de garder ton calme et de comprendre pourquoi ceux qui sont passés avant ont commit ce genre de chose. Et quand je dis comprendre ça veut dire être capable de faire de la documentation détaillée et surtout de l’expliquer aux autres qui seront surement horrifiés en écoutant ton épopée.

De la documentation ? Tu crois que j’ai le temps de faire de la documentation dans la situation où je suis ? Alors non seulement tu as tout le temps du monde -on y reviendra- mais en plus cette documentation est capitale pour l’avancement du projet. Quand on soigne un malade on soigne la cause de sa maladie. Pas les symptômes. En informatique c’est pareil. Le fait de comprendre les algorithmes et comment ils communiquent entre eux va te permettre de comprendre pourquoi l’application est bancale. En comprenant le pourquoi tu vas pouvoir t’attaquer à la cause de ce projet bancal. Là où la vraie dette technique réside.



Paye la dette des autres

C’est un investissement obligatoire. Tu dois payer la dette technique des autres tout de suite pour arrêter le cercle vicieux. Tu la payes d’abord avec de la documentation. Tu fais partie du problème si tu fais pas ça. C’est comme si on t’envoie en tant que pompier sauver un immeuble et que tu te mettes à lancer de la merde sur les murs à la place.

Cette dette technique doit être réduite à tous prix. C’est capital pour la santé mentale de ceux qui passeront après toi. Et surtout c’est capital pour le toi du futur. Car comme tout bon projet de merde il va hanter ton open-space pour longtemps. Si toi et tes collègues vous ne savez pas comment parler au démon, ce démon continuera à vous terroriser. En particulier un jour férié en prod.

Bref ne fuis pas ta responsabilité de pompier. Paye moi cette dette



Découpe, supprime, refait.

Une autre erreur courante de développeur(euse) en panique sur du code legacy et de vouloir réparer les choses. En mode : “je vais y toucher le moins possible, juste un peu pour le réparer”. C’est une très mauvaise idée. Quand un membre est gangrené on essaye pas de jeter du synthol dessus en espérant que ça passe. Quand un membre est gangrené on le coupe. Sauf cas particulier il faut partir du principe que les fondations sont pas bonnes. Sinon tu vas y passer un temps fou sur cette merde et ça va te rendre fou.



code legacy


Du code que ta peur de toucher et que tu touches à peine “pour pas que ça casse” reste donc du code legacy. Tu ne payes pas la dette, tu ne fais que en rajouter. Je sais que beaucoup de dev font ça et c’est pour ça que j’insiste : ça ne sert à rien de mettre du scotch sur un mur pour que ca tienne. Ca va peter! On casse le mur en question, sans peter tout l’immeuble, et on le reconstruit propre. Je sais que y’a beaucoup de gens qui pensent le contraire. On va être d’accord sur le fait qu’on est pas d’accord.

Je te parlais de vraiment comprendre le projet que tu as dans les mains. Ça sert en effet à faire la doc mais ça va servir surtout à savoir comment découper ton projet. La gestion des utilisateurs a un comportement schizophrène ? OK. À quel point ça marche pas ? Tout ? On supprime toute la gestion des utilisateurs et on refait. Juste la création d’utilisateur ? On supprime tout le système de création et on refait. Cette manière va vous faire gagner un temps fou en plus de vous garder sain d’esprit.



Aucune concession sur la qualité

Une des principales caractéristiques du code legacy est un oublie total de tout ce qui est qualité. Mais toi en tant que pompier t’es un héro. C’est fini le taudis on va faire un appartement neuf avec une belle déco post-moderne. Aucune concession possible sur la qualité du code. Prends le temp qu’il faut. Ce projet ça va être la 8éme merveille du monde. Du design pattern en folie et toute les sortes de test possibles. Je veux que t’arrives en code review comme Connor Mcgregor avant un combat. Et je veux que ca soit le groupe de dev les plus chiant au monde qui fassent cette code review.





En faire un cas d’école

Tu vas sûrement me dire que tu as pas le temps de faire tout ce que je te propose. De la documentation ? Refaire des parties entières ? Un code exemplaire ? Mais qui a le temps de faire ca ?

Si tu n’a pas le temps alors il va falloir l’exiger voir même le forcer. Cette dette technique à été créée la plupart du temps pour gagner du temps. En prenant le temps qu’il faut pour la payer tu envoies un message. Tu fais comprendre que le temps gagné, et donc l’argent, en faisant de la merde ne doit pas être pris à la légère par ton entreprise. En prenant le temps de bien faire tu fais de la prévention pour les futurs projets codés avec le cul. Ta boite y pensera à deux fois avant de faire plus de dette technique.

Enfin si ton entreprise te met la pression, que tu es pris pas le temps et stressé par la direction la solution est très simple. Mets à jour ton CV et commences à discuter avec les recruteurs qui te harcèlent sur Linkedin. Car tu es dans une entreprise qui en a rien à foutre de la qualité. Tu es donc dans une entreprise qui en à rien à foutre de toi et de ton bien être. Nettoyer du caca tu vas faire que ça ici. Il est temps de se barrer.



Épilogue

C’est jamais amusant de bosser sur ce genre de projet mais c’est inévitable. On peut pas toujours être affecté sur un nouveau projet cool avec la dernière techno funky. Donc il faut être préparé à nettoyer le caca des autres. Avec un peu de technique et beaucoup de patience ça se fait bien. Donc respire un coup. Y’a toujours un moyen d’éviter de faire de la boxe sur ton bureau et tes collègues.

Qui me parle ?

Je suis un dev. En ce moment je suis Backend Développeur / DevOps à Ubisoft. Je suis passionné du dev et expert en blagues. Je continue à te parler quotidiennement sur mon Twitter. Tu peux m'insulter à cette e-mail ou le faire directement dans les commentaires juste en dessous.

Commentaire(s)

  1. Cet article, fort intéressant, fait écho à ma dernière mission frerlance (terminée il y a tout juste une semaine). J’ai non seulement eu affaire à un code legacy bien velu (niveau meilleur ouvrier de France), mais en plus de ça j’ai moi même dev du code legacy, la faute à une gestion de projet inexistante et des demandes qui disaient merde aux autres continuellement (j’ai fait de mon mieux pour éviter le pire, mais je plains mon successeur..). Et la boîte (un grand compte) n’en avait rien à péter, le CP (un incompétent fini qui me refilait ses taches) me mettait la pression pour aller le plus vite possible. Résultat : une dette technique assez conséquente, et mon expertise (je suis freelance hien) on s’assoit dessus.
    Pour l’anecdote, j’avais un système de nested categories à créer, j’ai donc proposé une lib qui le gère bien (projet Laravel), mais le CP m’a dit “non non c’est simple on utilise pas ça”. Bah du coup 1 mois après on est passé sur la lib que j’avais proposé… Donc 1 mois de perdu. Et pas le temps de nettoyer mon code hein, faut que ça enchaîne !
    Bref des anecdotes dans le genre j’en ai d’autres encore… J’ai longuement insulté mon prédécesseur sur le projet au vu du code qu’il a pondu, mais au regard de la gestion du projet, je comprends pourquoi il en est ainsi.
    Bref, super article comme d’hab 😉

  2. Je cite :
    ‘En mode : “je vais y toucher le moins possible, juste un peu pour le réparer”. C’est une très mauvaise idée. Quand un membre est gangrené on essaye pas de jeter du Synthol dessus en espérant que ça passe. Quand un membre est gangrené on le coupe.’

    Pas facile quand :
    – d’une part ton projet, c’est la Tour Eiffel à l’envers, qui tient en équilibre sur presque rien et que personne ne sait trop comment c’est possible ;
    – d’autre part la directive du CP, au contraire, c’est “surtout tu touches à rien, tu changes le minimum juste pour corriger, et puis c’est tout” et que ton crédit-temps pour agir est tout rikiki pour s’assurer que tu franchisses pas la ligne rouge…

    De plus, il y a legacy et legacy : quand tu tombes sur des booléens à 3 états (c’est du vécu 🙁 ), tu te dis que tu ne vas pas non plus trop chercher les ennuis et t’user la santé sur ce truc…

T'en penses quoi ?

Your email address will not be published. Required fields are marked *