Le code legacy ou code hérité en français, c’est le code “originel” présent dans les sites web ou les applications, mais qui est devenu obsolète ou difficile à maintenir. On parle de code hérité parce qu’il s’agit en général d’un code hérité d’un autre développeur.
Les développeurs ont souvent peur de “casser” ce code en le modifiant, car le manque de tests automatisés au moment de sa création ou son manque de documentation le fragilise. À la manière d’un Jenga, modifier un bout de ce code peut entraîner d’autres dysfonctionnements (parfois assez aléatoires).
Dès lors, comment améliorer ce code ? Faut-il le corriger en dépit du business ou du service qui doit continuer à tourner ? Quelles sont les problématiques de recrutement liées à un code legacy trop important ? Ce sont à ces questions que nous allons tenter de répondre grâce à Etienne Pinault, Mobile Team Lead chez Sightcall, Jérémy Laplanche, CTO chez Imparfaite et Gabriel Pillet, CTO chez Web^ID.
“Tout code deviendra du legacy”
“Avoir un code Legacy n'est pas un échec, ça prouve que l'application a eu du succès dans le temps, malgré la dette technique. De toute façon n'importe quel code, aussi beau soit-il écrit aujourd'hui sera le Legacy de demain. Il est quand même important de revenir régulièrement pour rafraîchir le code et enlever progressivement de la dette technique.” explique Gabriel Pillet, CTO chez Web^ID.
Effectivement, il y a 3 types de code legacy :
Le code qui a été soigné par ses prédécesseurs. Il est clair, commenté, testé et donc facilement maintenable (mais cela n’est pas le cas le plus fréquent !).
Le code difficilement maintenable. Il n’est pas très lisible au premier coup d’œil, il contient du code mort ou dupliqué, il y a des classes trop grandes, il y a peu, voire pas de tests unitaires, etc.
Le code obsolète. C’est un code qui n’a pas suivi les évolutions de framework et/ou de langage. Avec les changements de versions, il est devenu difficile d’ajouter une feature et les développeurs passent leur temps à maintenir le code à flot.
Disclaimer : dans cet article, nous allons plutôt aborder le second type de code legacy. Il est toutefois nécessaire de garder en tête qu’il existe des codes hérités qui sont très propres.
Il est rare, quand on parle de legacy, que l’on fasse référence à une code base parfaitement propre. En effet, dans nos échanges quotidiens avec des développeurs ou des CTO par exemple, une connotation négative est quasi toujours associée à l’idée de code legacy.
Le code legacy expliqué en quelques mots
Le concept du code legacy peut se comprendre assez facilement : imaginez cela comme la construction d’un Lego.
Vous êtes face à un Lego qui a été monté il y a des années avec des pièces qui n’existent plus aujourd’hui.
Et là, on vous dit : “tu vois cette construction en Lego, il faut que tu corriges toutes les pièces qui ne sont plus dans leur axe et surtout on veut qu’il soit complètement articulé pour dans 2 jours”.
Ajoutez à cela que la ou les personnes qui ont construit ce Lego à l’époque ne sont plus là, que vous n’avez pas le manuel de construction et qu’il est impossible de mettre la main dessus.
Have fun !
À quoi ressemble un code legacy mal entretenu ?
Maintenant que nous en avons la définition, nous allons dresser le portrait-robot de ce code
legacy :
Il n’est pas clair ou pas lisible,
Il y a du code mort ou dupliqué,
Il y a peu, voire pas de commentaires,
Il n’y a pas de noms de variables ou de classes explicites (ce sont des abréviations que seul votre prédécesseur connaissait, etc.),
Les classes sont très grandes (5000~7000 lignes),
L’architecture est trop complexe et non maîtrisée,
et surtout : il n’y a pas de tests unitaires !
Si la base de code de votre application ressemble à cela, on peut alors affirmer que votre projet possède une importante dette technique. Le problème est que plus la dette technique est importante, plus son coût de maintenance est élevé.
Qu’est-ce que la dette technique ?
Le concept de dette technique est apparu dans les années 90 et permet d’analyser la pérennité et l'évolution des développements informatiques dans le temps.
Quelles sont les causes de la dette technique ?
Les causes peuvent être nombreuses, mais quatre explications sont le plus souvent à l’origine de la dette technique :
Le manque de temps. Vos clients, voire les fondateurs de votre startup, veulent voir les évolutions au plus vite alors on oublie la phase de test pour pouvoir livrer le projet dans les temps. En effet, la question du “time to market” est clé pour beaucoup de startups qui lancent une application SaaS, pour diverses raisons stratégiques (aller plus vite que la concurrence, avoir rapidement des clients - donc des revenus - pour lever des fonds et passer à la phase de scaling, etc.)
“En tant que CTO, avoir une vision "tech" d'un projet est primordiale, mais même le plus parfait des projets, s'il n'est pas en adéquation avec les attentes business, ne fonctionnera pas. Il faut garder à l'esprit que pour faire évoluer le service, il est nécessaire que celui-ci soit "rentable".
C’est pour cela que les 6 premiers mois, on a fait beaucoup de choses pas très propres, mais depuis 9 à 10 mois tout ce qu’on fait a vocation à être réalisé de manière plus correcte. C'est loin d'être parfait, mais au fur à mesure, on écluse la dette technique et on met en place les bons outils” analyse Jérémy Laplanche, CTO chez Imparfaite.
Le manque de budget.
Le déficit de compétences du développeur à l’origine du code. Il faut comprendre par là que le développeur en charge ne maîtrisait peut-être pas suffisamment les bonnes pratiques de développement pour poser les bases du code.
“Chez Imparfaite, ce qu’il s’est passé, c'est que l’équipe était composée de personnes qui venaient de temps en temps et qui repartaient. Donc on leur donnait une mission, ils la remplissaient, mais sans forcément regarder de près le rendu. Ça fonctionnait, tant mieux. Sauf qu’au fur et à mesure, on s’est retrouvé avec un empilement de mauvais code sur le projet à tel point que quand je suis arrivé, on était à la limite que le code entier se casse” explique Jérémy Laplanche.
La taille trop réduite de l’équipe de développement. Les développeurs ne sont pas assez nombreux et tout le monde travaille donc sur les évolutions du projet, faisant passer l’amélioration et l’évolution du code existant au second plan.
Quelles problématiques se posent quand le code legacy est trop important pour une entreprise ?
Des problématiques de sécurité : cela touche particulièrement les banques et les services financiers. C’est ce qui est arrivé en 2017 à Equifax, une société d'évaluation de la cote de crédit.
L’histoire d’Equifax
En 2017, l’une des plus grandes agences de notation de crédit au monde, Equifax, a subi une attaque de pirates qui avaient utilisé à leur avantage une faille de sécurité dans le système informatique de l’entreprise. Ce sont alors les données de 148 millions de personnes dans le monde qui ont été compromises.
Cependant, un rapport du Government Accountability Office aux États-Unis a conclu que la violation était entièrement évitable et était en partie causée par le code hérité du site web qui remontait aux années 1970...
Outre les coûts de nettoyage qui ont été estimés à 1,3 milliard de dollars, les failles de sécurité ont une influence majeure sur la confiance de vos consommateurs et le grand public.
Des problématiques financières
Une dette technique trop importante peut coûter cher en maintenance et en refactorisation. La refactorisation est le fait de repasser sur la code base pour la clarifier, la débugger, la nettoyer : cela a un coût puisqu’une ressource humaine interne à l’entreprise ou outsourcée doit engager du temps pour un tel sujet technique.
Comme évoqué précédemment, pour respecter les contraintes de temps de livraison d’un projet, le code est développé de manière fonctionnelle, mais techniquement imparfaite : cela implique quasi obligatoirement une phase de reprise du code, de refactoring, à terme.
Selon une étude de Consortium for IT Software Quality, les systèmes existants ont coûté 70 milliards de dollars aux entreprises américaines en 2003, contre 596 milliards de dollars en 2018.
Des problématiques de temps
Le refactoring (ie. le fait de nettoyer du code sans en modifier son comportement) prend des heures et est souvent placé au bas de la liste des tâches. D’ailleurs, entre 11% et 30% seulement du temps de développement est alloué à la dette technique dans les entreprises. Parmi ce temps passé, des études ont démontré qu'environ 50% de ce temps consacré à la maintenance du code est en réalité dédié à tenter de comprendre le code qu’ils essayent de maintenir !
Des problématiques de recrutement
Nous pouvons en témoigner : la présence d’une dette technique importante est un frein réel au recrutement de nouveaux talents techs. En fonction de l’état du code legacy, le recrutement n’est pas impossible, mais il est plus complexe. L’erreur à éviter absolument est de ne pas évoquer, lors des entretiens de recrutement, la réalité du code legacy car c’est alors le meilleur moyen qu’un développeur soit déçu et qu’il envisage de quitter son poste à court-terme.
Pour pallier un peu la difficulté à recruter avec une dette technique importante, mieux vaut jouer la transparence sur l’état réel de votre code, voire montrer ce dernier pendant les entretiens de recrutement. Ainsi, vous vous assurez de ne recruter que des profils qui rejoignent votre projet en connaissance de cause et qui ont cette envie (voire une expérience sur le sujet) de participer à une phase d’amélioration et de refactoring du code.
“Un code trop Legacy avec une forte dette technique pourra rebuter des nouveaux candidats à l'embauche, qui cherchent souvent des projets avec des technologies modernes à l'état de l'art. ll est donc plus difficile de recruter quand les technologies utilisées ont trop de retard et ne sont plus d'actualité.” explique d’ailleurs Gabriel Pillet, CTO de Web^ID.
Même si s'attaquer à un gros projet Legacy pourra rebuter des profils junior, ce type de projet peut en revanche offrir un beau challenge à des développeurs expérimentés.
“Certains profils senior sont contents d'être confrontés à des problématiques de refactoring des projets Legacy, limiter la dette technique, améliorer la qualité et le code pour le stabiliser offre souvent plus de challenge que d’entamer un projet "from scratch"” nous affirme Gabriel Pillet.
Mais pourquoi ne pas se concentrer sur l’amélioration constante du code legacy s’il présente autant d’inconvénients ?
Tout simplement parce que c’est prendre le risque de couper un service qui fonctionne.
Si le développeur d’origine comprend son code de facto, cela peut vite ne plus être le cas des autres et futurs membres de l’équipe si le code ne respecte pas les best practices de développement.
De plus, au fil des années, l’équipe évolue et le code devient un véritable patchwork toujours plus difficile à comprendre et à modifier. Jusqu’au moment où il devient impossible de faire des mises à jour ou des modifications puisque plus personne ne comprend le code et ses effets.
“Un code legacy, même s’il est endetté techniquement, on n’y touche pas. S'il fonctionne, on le laisse fonctionner et il n’y a aucune raison de modifier quoique ce soit. C’est pour cela que reprendre une application “from scratch”, ça n’a aucun sens, car le service fonctionnera pareil, il sera simplement mieux écrit ; mais ça on s’en fiche en soi.
S’il y a une feature ou un morceau du code qui ne fonctionne pas ou qu’on a besoin de modifier pour des raisons produit, là on peut modifier. Mais en général, tant que cela fonctionne, on n’y touche surtout pas, car on risque de tout casser pour finalement pas grand-chose” expose Etienne Pinault, Mobile Team Lead chez Sightcall.
"ll faut savoir jongler un peu entre deux aspects du développement : l’aspect technique et le business. Pour un CTO, il est nécessaire de savoir là où on peut se permettre de rajouter de la dette technique maîtrisée avec du commentaire, des tests, etc. en s'assurant qu’on ne casse rien au fur et à mesure. Le plus important, c'est de garder en tête qu’on n'arrivera jamais à 0 dette technique, ce qu’il faut, c’est la limiter au maximum”. explique Jérémy Laplanche, CTO chez Imparfaite
Bonnes pratiques et solutions
Afin d’éviter la dette technique, il faut commencer par mettre en place les bonnes pratiques de développement.
Parmi elles :
Mettre en place d’une documentation claire,
Se mettre d’accord avec le reste de l’équipe sur une méthodologie à suivre,
Utiliser un framework,
“Dans les audits que nous réalisons, on constate que l'utilisation d'un framework limite beaucoup les dérives, en revanche du code "fait maison" est presque toujours lié à une grosse dette technique et amène à devoir refaire une nouvelle version de l'application.” affirme Gabriel Pillet, CTO de Web^ID.
Faire des tests ! Avant ou après, mais tester son code reste une étape importante qui évite bien des embûches. Vous pouvez utiliser la méthode TDD (Test Driven Development), c’est-à-dire, développer son service numérique petit à petit en écrivant un test avant le code.
Pourquoi créer les tests avant le code c’est mieux ?
Tout simplement, car si vous vous dites que vous finirez par les tests une fois le code écrit, il y a une bonne chance pour que vous ne le fassiez jamais. Généralement, l’étape des tests est reléguée à la fin de votre liste de tâches et, in fine, cette étape est souvent réduite, voire supprimée faute de temps.
Si vous faites déjà face à une importante dette technique, quelles solutions s’offrent à vous ?
Opérer un refactoring (ou une refonte), c’est-à-dire retravailler le code pour améliorer sa lisibilité, sa compréhension, sa qualité, son architecture ou ses performances. En renommant les classes, en créant de nouvelles couches, etc. de façon à restructurer le code sans modifier sa fonction finale.
“La bonne idée, c’est de faire du refactoring par petits bouts, et qu’il soit introduit par une nouvelle feature. C’est le meilleur truc à faire à mes yeux, car on va satisfaire à la fois le business en introduisant une nouvelle feature qui leur sera utile, et l’équipe de développement, car on va réduire une partie de la dette technique. On ne peut pas réduire la dette technique pour la réduire, il faut qu’il y ait autre chose avec” explique Etienne Pinault, Mobile Team Lead chez Sightcall.
Passer par une agence. Si vous n’avez pas le temps, ou les compétences en interne, nécessaires pour réaliser une refonte, il existe des entreprises spécialisées qui pourront vous aider dans la restructuration de votre code.
En bref, on ne peut pas éviter le code legacy donc le mieux à faire c’est de s’armer de beaucoup de patience et de technique !
