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 même 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 codé 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. Ça 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.
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 à tout 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 n’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 ne sont pas bonnes. Sinon tu vas y passer un temps fou sur cette merde et ça va te rendre fou.
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 qu’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 ça tienne. Ça va péter! On casse le mur en question, sans peter tout l’immeuble, et on le reconstruit propre. Je sais qu’il y’a beaucoup de gens qui pensent le contraire. On va être d’accord sur le fait qu’on n’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’utilisateurs ? 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 oubli total de tout ce qui est qualité. Mais toi en tant que pompier t’es un héros. 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 temps qu’il faut. Ce projet, ça va être la 8éme merveille du monde. Du design pattern en folie et toutes les sortes de test possibles. Je veux que t’arrives en code review comme Connor Mcgregor avant un combat. Et je veux que ça soit le groupe de dev les plus chiants 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 ça ?
Si tu n’as pas le temps alors il va falloir l’exiger voire 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 dettes techniques.
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 commence à 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 ne 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.
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 😉
J’ai aussi mon paquet d’anecdotes similaires 🙂
C’est déprimant comme tout le monde vit la même chose !
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…
« Booléen à 3 états », j’ai justement un collègue qui voulait utiliser la valeur Null en plus de true et false pour gérer un 3ème état dans le code. Je lui ai dit hors de question, tu changes le type de la variable même si il y a un impact du front au backend, comment ne pas devenir le développeur toxique dans ces cas là.
Le « tribool » a son utilité pour certaines situations, et peut rendre le code plus clair et safe. Ca équivaut en fait à un optional / maybe sur un bool
https://stackoverflow.com/questions/1269911/have-you-used-boosttribool-in-real-work
https://stackoverflow.com/questions/24268388/scala-does-optionboolean-makes-sense
Salut,
Jarno : « 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… »
Y a pas que les gifs qui sont marrants ici 🙂
Quel métier formidable !
Les dev ont voit les choses à notre sauce mais c’est intéressant de demander aux managers ce qu’ils pensent de nos discours de « refactoring », « dette technique », et autre « code inmaintenable à réécrire » pour apprendre à mieux gérer ces situations.
Pour faire court :
– le refactoring c’est quelque chose de rapide, qui dure 2 jours au grand max : ça fait partie de « l’hygiène » normale d’un projet qui n’a pas à recevoir l’aval d’une personne non technique (un manager…)
– au delà c’est de la réécriture de code, c’est beaucoup plus couteux et risqué, ça doit être planifié et budgétisé de manière sérieuse. Un manager débutant va facilement se laisser embobiner, mais en entendant une 3eme fois à la suite « c’est inmaintenable il faut tout réécrire » sur un bout de code où déjà 2 développeurs se sont succédé 2 fois plus de temps qu’annoncé, il va commencer à se crisper face à ce genre de demandes… et il aura bien raison 🙂
De manière générale, plus on est nouveau sur un projet, plus ce projet est ancien / complexe, et plus il convient de temporiser ses ardeurs à tout vouloir refaire car il est très probable que beaucoup de choses nous échappent – raison pour laquelle on trouve que c’est inutilement compliqué. Prendre le temps d’assimiler et comprendre l’existant avant de prétendre l’améliorer.
Il ne faut pas non plus mélanger legacy et dette technique. La dette technique peut contaminer un projet de quelques semaines seulement, au point de devoir le recommencer au bout de quelques mois. Il est alors plus facile de céder à une fuite en avant technique que de considérer que c’est en premier lieu de notre responsabilité, et que donc on peut récupérer les choses. Sans cette compréhension, recommencer à zéro reproduira à terme le même résultat douloureux (c’est d’ailleurs souvent le moment où on pose sa démission…). A l’inverse, travailler avec du code en mauvais état est un excellent moyen de vérifier ce qui améliore réellement les choses… ou pas. Le secret c’est d’y aller de façon progressive, incrémentale, en constatant semaine après semaine comment les choses s’améliorent. Quelle fierté à la fin d’avoir récupéré un code qui partait en sucettes ! Le pire étant de ne rien changer : observer passivement le bateau couler tous les jours un peu plus… et notre motivation avec…
Quant au legacy, c’est simplement le socle indispensable pour bâtir quelque chose de sérieux dans le temps. C’est la capacité des développeurs à préserver leur propre travail et protéger l’investissement de la société. Par exemple il y a des applications / libs qui ont +20 ans d’âge et qui permettent d’effectuer des choses remarquables précisément parce qu’elles n’ont pas été ré-écrites from scratch tous les 2 ou 3 ans… « Old is Gold » !