Dit artikel is ook beschikbaar in het Nederlands.

Depuis l’essor de l’engouement pour les grands modèles de langage, la plupart des développeurs ont sans doute déjà pu constater le gain de productivité que ces outils peuvent offrir, à condition de les utiliser correctement. Dans cet article de blogue, nous explorons la possibilité d’aller plus loin : l’IA offre-t-elle une aide suffisante afin de maîtriser le legacy code ?

Le recours aux grands modèles de langage (Large Language Model – LLM) en programmation est en effet bien connu à présent : cela va de la formulation de questions à un chatbot (“comment écrire un algorithme en Java qui…”), à un code completion de plus en plus intelligent et étendu (saisie automatique de ce que vous souhaitez taper dans l’éditeur), jusqu’au vibe coding complet (dans l’IDE, ou même simplement dans un terminal) : des agents d’IA rédigent, à l’aide de prompts, des pans entiers de code sur votre machine – oui, même des applications fonctionnelles.

Nous avons donné une définition très large du code legacy dans un précédent article de blog. Commençons donc par préciser ce que nous entendons par “legacy” et par mieux illustrer le “degré de difficulté” des projets legacy.

“Ancien” code : une multitude de possibilités

Il n’existe pas vraiment de définition officielle du code legacy ; généralement, on parle de l’utilisation d’une technologie qui n’est plus prise en charge, difficile à maintenir, ou simplement de “code dont on hérite de quelqu’un d’autre”. Il s’agit évidemment toujours de code encore en service, et donc important. Ironiquement, les applications les plus critiques sont souvent celles qui existent depuis des années et auxquelles on “fait confiance” depuis longtemps, mais sans les entretenir correctement.

L’IA peut nous aider à entretenir n’importe quel code ; nous allons donc présenter un spectre allant du code legacy le plus ancien et le plus problématique au code de projets ne nécessitant qu’une petite mise à jour. À une extrémité du spectre, on trouve des programmes écrits dans des langages de programmation obsolètes, selon une architecture dépassée, utilisant des bases de données qui ne sont plus d’actualité et fonctionnant sur des serveurs équipés de systèmes d’exploitation qui ne sont plus pris en charge : avec ces géants, on doit souvent craindre une défaillance critique à la moindre modification erronée. À l’autre extrémité, on trouve des logiciels assez bien entretenus, mais qui utilisent une bibliothèque logicielle qui n’est plus la version la plus récente : il est généralement très facile de les remettre entièrement à jour. Enfin, quelque part entre les deux, on trouve des applications pour lesquelles la plupart des développeurs n’utiliseraient pas encore le terme legacy, mais qui nécessitent néanmoins des migrations complexes, avec par exemple un ou deux frameworks obsolètes à remplacer.

Que pouvons-nous en faire ? Les LLM offrent-ils d’autres possibilités en fonction de la position du projet sur ce spectre ? Jusqu’à présent, nos recherches se sont concentrées sur la partie gauche de ce spectre ; la suite de cet article portera donc davantage sur les possibilités d’aborder le “véritable” legacy. Plus tard dans l’année, nous approfondirons également ce que nous pouvons faire en matière de migrations et d’updates.

Utilisation des LLM sur des bases de code legacy

Il est clair qu’un simple prompt “réécris ce programme selon les normes modernes” ne fonctionnera pas (même si certains fournisseurs affirment que cela sera bientôt possible). Nous devrons poser des questions un peu plus concrètes et décomposer le travail en plusieurs étapes. Il y a en fait deux choses que nous pouvons faire avec notre code legacy : le réécrire et le documenter.

Réécriture du code legacy

Lorsque nous commençons à réécrire du code, nous devons souvent tenir compte du fait que la reconstruction complète d’un très grand projet est une tâche trop difficile. Il est possible d’obtenir des “quick wins” en réécrivant stratégiquement certaines parties d’un projet, qui seront ensuite réutilisées dans un contexte plus large, où une équipe humaine et l’IA reconstruiront l’application dans les règles de l’art. Nos expériences nous ont montré qu’il était trop ambitieux d’attendre de l’IA qu’elle utilise une architecture entièrement nouvelle tout en traduisant l’ancien code vers le nouveau. En revanche, il est possible de “vibe coder” une grande partie de la charpente typique d’un nouveau projet, puis d’y injecter de manière ciblée un certain nombre de morceaux de code qui sont des traductions de parties d’un projet legacy. En tant qu’êtres humains, notre tâche consiste à indiquer clairement quelle architecture nous attendons et quelles sont les règles de qualité du code nouveau.

L’un des principaux défis liés à la réécriture de code à l’aide de l’IA consiste à tester l’exactitude de la traduction : le code fait-il toujours ce qu’il faisait auparavant (indépendamment du fait que cela soit souhaitable, car même le business case peut parfois être trop obsolète dans le cas d’un projet legacy) ? Pour les projets relativement récents, il existe déjà de nombreux tests que nous pouvons effectuer pour vérifier l’exactitude, mais avec les anciens systèmes legacy, nous sommes souvent confrontés au problème que l’application est simplement testée en production, ou du moins avec des données de production : il n’y a pas de tests spécifiques ni même de données de test pouvant être utilisées en toute sécurité. Dans ce cas, il s’agit de créer un environnement dans lequel nous pouvons tester le nouveau code en toute sécurité, ce qui est généralement un travail ad hoc et demande une certaine créativité. Nous ne pouvons pas envoyer de données de production vers le cloud, nous devons donc nous assurer que le LLM ne puisse pas les lire. Ce serait plus simple si nous pouvions utiliser des LLM fonctionnant en local, mais pour l’instant, ceux-ci ne sont pas encore assez puissants (quand ils sont disponibles) pour effectuer des tâches aussi complexes avec du code legacy.

L’interface utilisateur constitue un autre défi : dans les projets plus anciens, celle-ci est souvent obsolète et il faut construire une nouvelle GUI à partir de zéro. Cela pose toutefois le problème de ne plus disposer d’une base de référence dans l’ancien projet : la nouvelle interface devra généralement être testée manuellement par des personnes. J’espère toutefois que nous verrons des progrès dans ce domaine dans un avenir proche, en ce qui concerne les possibilités de l’IA. En effet, nous voyons déjà apparaître des systèmes capables de contrôler l’intégralité de votre ordinateur (comme OpenClawd), et l’intégration avec des frameworks plus traditionnels pour le test d’une interface graphique fait également partie des possibilités.

Enfin, les petits projets legacy constituent également un domaine où nous pouvons obtenir des résultats rapides. Si nous utilisons un programme legacy petit à moyen, doté de fonctionnalités limitées et d’une GUI simple, ou présentant un input et un output clairs en cas de traitement par lots, et qu’il n’existe aucun business case justifiant son intégration dans une autre méthode de travail, nous pouvons alors tenter une approche directe pour construire une version moderne dans un nouveau langage de programmation à l’aide de l’IA. Dans ce cas, il faudra tout de même bien tester et adopter une approche structurée avec un accompagnement des développeurs humains, mais il est possible d’essayer cette méthode pour des applications non critiques. Une application à usage interne, par exemple, constitue généralement un bon premier candidat.

Documentation du code legacy

Parfois, la réécriture du code legacy avec l’IA est un peu trop ambitieuse, ou nous avons besoin de plus d’informations avant de nous y risquer. Il peut être intéressant de se tourner d’abord vers la documentation : l’IA peut également nous aider à faire en sorte que l’exploration d’une base de code legacy ressemble un peu moins à de l’archéologie de haut niveau.

Expliquer un morceau de code de petite à moyenne taille et en extraire la logique business, ou analyser un morceau plus important et en expliquer la structure et l’architecture, tout cela est tout à fait possible avec les grands modèles de langage actuels. Il est toutefois possible d’aller plus loin : il est possible de créer des outils d’IA pour l’aider à explorer la base de code et, par exemple, à générer des diagrammes illustrant les dépendances entre les segments de code. Ou bien on peut lui faire écrire des scripts afin de structurer soigneusement ses conclusions après chaque analyse dans un fichier texte pour elle-même et un PDF destiné à l’utilisateur humain.

Il est également possible d’adopter une approche hiérarchique : commencer par explorer la base de code, puis approfondir progressivement l’analyse des différents modules afin d’obtenir de plus en plus de détails et de compléter l’analyse. Il s’agit là de l’approche descendante, que nous pouvons toutefois compléter par une version ascendante : une fois que nous sommes allés en profondeur, nous pouvons à nouveau demander un résumé afin de construire une présentation mieux documentée de la situation dans son ensemble.

Il est toutefois important ici de savoir à l’avance ce que nous souhaitons exactement atteindre. Une analyse générale d’une base de code par l’IA peut s’avérer intéressante lorsque les utilisateurs humains ne connaissent pas du tout le système et souhaitent disposer de points de repère pour se familiariser avec celui-ci.

Cependant, lorsque l’objectif est de pouvoir assurer la maintenance de la base de code, il est préférable de mettre en place un système proposant un chatbot qui connaît le contexte spécifique et les particularités du projet legacy, et qui peut répondre à des questions très ciblées à ce sujet. Cela est possible, par exemple, dans CoPilot Studio. Si cela ne fonctionne pas correctement, il est possible d’envisager de construire manuellement une base de connaissances en utilisant l’IA qui pourra ensuite être utilisée par l’IA pour répondre aux questions.

Une autre option consiste à extraire des informations spécifiques de la base de code, telles que la logique business par module individuel, ou du pseudocode pouvant aider les développeurs humains à réimplémenter cette logique dans un autre projet. (Et bien sûr, une IA peut également être mise à contribution lors de cette deuxième étape).

Avec une touche de créativité, nous pouvons concevoir une meilleure approche pour la plupart des analyses ad hoc que celle consistant à “se contenter d’analyser à tout va”. Et la documentation d’un système legacy peut tout simplement constituer une première étape vers sa réécriture.

Conclusion : professionnels recherchés

Comme mentionné précédemment, les LLM nous offrent progressivement des possibilités très puissantes pour traiter nos bases de code legacy, surtout lorsque nous avons accès aux modèles volumineux et puissants disponibles aujourd’hui. Nous constatons toutefois qu’il s’agit en réalité d’une boîte à outils très bien fournie, comprenant plusieurs outils puissants, et que nous devons savoir ce que nous voulons en faire et comment les utiliser au mieux.

Tout n’est pas encore entièrement automatisé : nous aurons donc toujours besoin de bons professionnels pour tirer le meilleur parti de ces outils. Notre conseil aux développeurs est de ne surtout pas avoir peur de l’IA et de l’utiliser régulièrement lors de l’analyse et du développement de logiciels : l’expérience est la meilleure école pour former les bons professionnels dont nous avons besoin dans ce domaine.

Pour l’instant, la conclusion est donc la suivante : pour le code legacy, l’IA n’est pas une panacée, mais une boîte à outils pratique qu’il vaut mieux essayer dans le cadre d’une approche plus large. Comme indiqué, nous nous pencherons plus tard dans l’année sur le milieu et la partie droite du spectre du code legacy. Nous pensons qu’il existe ici davantage de possibilités d’automatisation de certains workflows, surtout si nous exploitons davantage les agents. Il est donc possible que, pour des projets un peu plus simples et répétitifs, nous puissions évoluer du “professionnel” vers “l’usine”.

Cet article est aussi disponible en français.

Sinds de hype van grote taalmodellen is losgebarsten, zullen de meeste ontwikkelaars ondertussen al wel geproefd hebben van de productiviteitswinst die deze tools, mits correct gebruik, kunnen bieden. In deze blog onderzoeken we of we verder kunnen gaan dan dat: biedt AI ook voldoende hulp bij het beheersen van Legacy Code?

Het inzetten van Large Language Models (LLM) bij het programmeren is inderdaad ondertussen stilaan goed gekend: het gaat van vragen stellen aan een chatbot (“hoe schrijf ik in Java een algoritme dat … “), overheen steeds slimmere en langer wordende code completion (automatisch aanvullen wat je wil typen in de editor), tot volledige vibe coding (in de IDE, of zelfs gewoon in een terminal): AI agenten, via prompts, hele stukken code – ja, zelfs werkende toepassingen – laten schrijven op je machine.

In een vorige post rond legacy code, gaven we een erg brede definitie. Laten we dus vooreerst iets duidelijker stellen wat we met Legacy bedoelen, en de “moeilijkheidsgraad” van Legacy projecten beter illustreren.

“Oude” code: een spectrum aan mogelijkheden

Er is niet echt een officiële definitie van legacy code; meestal spreekt men van het gebruik van niet langer ondersteunde technologie, moeilijk te onderhouden, of simpelweg “code die je van iemand anders erft”. Het gaat uiteraard altijd wel om code die nog in gebruik, en dus belangrijk is. Ironisch genoeg, zijn het vaak de meest kritische toepassingen, die al jaren meegaan en waar men al jaren “op vertrouwt”, maar dan zonder ze goed te onderhouden.

AI kan ons helpen bij het onderhoud van eender welke code, dus we zullen een spectrum demonstreren dat van de oudste, ergste legacy code gaat, tot code van projecten die slechts een kleine update nodig heeft. Aan de ene kant van het spectrum heb je programma’s, geschreven in ouderwetse programmeertalen, volgens een achterhaalde architectuur, gebruik makend van databases die niet meer van deze tijd zijn, en draaiende op servers met niet langer ondersteunde besturingssystemen: bij deze mastodonten moet men vaak bang zijn dat ze kritisch zullen falen bij de kleinste verkeerde wijziging. Helemaal aan de andere kant heb je vrij goed onderhouden software, waarin een softwarebibliotheek wordt gebruikt die niet meer de meest recente versie is: meestal een koud kunstje om ze weer helemaal up-to-date te krijgen. Ergens in het midden vind je, ten slotte, toepassingen terug waarbij de meeste developers nog niet meteen het woord Legacy in de mond zullen nemen, maar waar wel moeilijke migraties dienen te gebeuren, met b.v. een verouderd framework of twee dat zou moeten worden vervangen.

Wat kunnen we hier nu mee? Bieden LLMs ons andere mogelijkheden naargelang de plaats van het project op dit spectrum? Ons onderzoek heeft zich tot nu toe op de linkerkant van dit spectrum gefocust, dus het vervolg van deze blogpost zal veeleer over de mogelijkheden gaan om “échte” Legacy aan te pakken. Later dit jaar gaan we ook verder uitdiepen wat we met migraties en updates kunnen doen.

Gebruik van LLMs op Legacy Codebases

Het is duidelijk dat de eenvoudige prompt “herschrijf mij dit programma volgens moderne standaarden” niet zal werken (al beweren sommige vendors dat dit eraan zit te komen). We zullen iets concretere zaken gaan vragen, en het werk ook enigszins in stukjes moeten kappen. Verder zijn er eigenlijk twee zaken die we kunnen gaan doen met onze legacy code: ze herschrijven en ze documenteren.

Herschrijven van Legacy Code

Als we beginnen met code herschrijven, zullen we er vaak rekening mee moeten houden dat een heel groot project voldoende goed herbouwen een te moeilijke opgave is. We kunnen “quick wins” behalen door strategisch een aantal zaken te gaan herschrijven van een project, en die stukken dan te gebruiken in een ruimere context, waarbij een team van mensen en AI de toepassing opnieuw bouwen volgens de regels van de kunst. Bij onze experimenten stelden we vast dat het een brug te ver was om van het AI te verwachten een volledig nieuwe architectuur te gebruiken, tegelijk met het vertalen van oude code naar nieuwe. Wat wel mogelijk is, is om heel wat van de typische scaffolding (de standaardcode om tot iets werkend te komen) van een nieuw project te vibe coden, en daar dan gericht een aantal stukken code in te injecteren die vertalingen zijn van stukjes van een legacy project. Als mens is het onze taak om duidelijk aan te geven welke architectuur we verwachten, en wat de kwaliteitsregels zijn van de nieuw geschreven code.

Eén van de grotere uitdagingen bij het herschrijven van code met behulp van AI, is het testen van de correctheid van de vertaling: doet de code nog wat ze vroeger deed (los van het feit of dit wenselijk is, want zelfs de business case kan soms te verouderd zijn in geval van Legacy)? Bij redelijk nieuwe projecten zullen er reeds heel wat testen bestaan die we kunnen uitvoeren om de correctheid na te gaan, maar bij legacy hebben we vaak het probleem dat de toepassing eenvoudigweg wordt getest in productie, of op zijn minst met productiedata: er zijn geen specifieke tests of zelfs maar veilig bruikbare testdata. In dat geval komt het erop neer een omgeving te creëren waarin we de nieuwe code op een veilige manier kunnen testen, wat meestal ad hoc werk is en enige creativiteit vraagt. We mogen namelijk geen productiedata naar de Cloud sturen, dus we moeten ervoor zorgen dat het LLM deze niet kan lezen. Het zou eenvoudiger zijn als we lokaal draaiende LLMs zouden kunnen gebruiken, maar voorlopig zijn deze nog niet krachtig genoeg (als ze al beschikbaar zijn) om dergelijke complexe taken uit te voeren met legacy code.

Een andere uitdaging is de gebruikersinterface: bij oudere projecten is deze vaak achterhaald en moet er, vanaf de grond, een nieuwe GUI (Graphical User Interface) worden opgebouwd. Dat geeft echter het probleem dat je geen basis meer hebt in het oude project om mee te vergelijken: de nieuwe interface zal doorgaans manueel door mensen moeten worden getest. Ik verwacht echter dat we op dit vlak nog vorderingen zullen zien in de nabije toekomst, wat de mogelijkheden van het AI betreft. We zien namelijk al systemen opduiken die je volledige computer kunnen besturen (zoals OpenClaw of het “Computer Use” van Anthropic), en ook integratie met meer traditionele raamwerken voor het testen van een GUI behoort tot de mogelijkheden.

Waar we, ten slotte, ook quick wins mee kunnen halen, zijn kleinere Legacy projecten. Als we een klein tot matig groot legacy programma gebruiken, met beperkte functionaliteit en een eenvoudige GUI of een duidelijke input en output in geval van batch processing, en geen business case om deze te integreren in een andere manier van werken, dan kunnen we een rechttoe rechtaan aanpak proberen om een moderne versie in een nieuwe programmeertaal te bouwen met AI. We moeten dan nog altijd goed testen en een gestructureerde aanpak hebben met bijsturingen door menselijke developers, maar het wordt wel feasible om dit voor niet-kritische toepassingen te gaan uitproberen. Een intern gebruikte toepassing is bijvoorbeeld een typische goede eerste kandidaat.

Documenteren van Legacy Code

Soms is herschrijven van Legacy met AI net iets te ambitieus, óf we hebben meer informatie nodig voor we er ons aan wagen. In dat geval kan het interessant zijn om eerst richting documentatie te kijken: het AI kan ons ook helpen om het verkennen van een legacy codebase net iets minder op archeologie voor gevorderden te doen lijken.

Van een klein tot matig stuk code uitleggen en er de business logica uithalen, of een groter stuk analyseren en de opbouw en architectuur uitleggen: dat kan met de huidige grote taalmodellen zonder meer. We kunnen echter verder gaan: we kunnen het AI tools laten bouwen om zichzelf te helpen de codebase te verkennen, en b.v. diagrammen te voorzien van de afhankelijkheden tussen de stukken code. Of we kunnen het scripts laten maken om de bevindingen na elk stuk analyse netjes te structureren in een tekstbestand voor zichzelf en een pdf voor de menselijke gebruiker.

We kunnen ook hiërarchisch werken: eerst een verkenning van de codebase doen, en dan telkens dieper duiken in de verschillende modules, om meer en meer detail te verkrijgen en de analyse aan te vullen. Dat is de top-down aanpak, die we echter kunnen aanvullen met een bottom-up versie: eens we tot in de diepte zijn gegaan, kunnen we weer zaken laten samenvatten om van het grotere plaatje een beter geïnformeerde uiteenzetting op te bouwen.

Hier is het wel van belang dat we van tevoren weten wat we precies willen bereiken. Een algemene analyse van een codebase door het AI kan interessant zijn wanneer de menselijke gebruikers het systeem nog totaal niet kennen en aanknopingspunten willen hebben om zaken te leren, maar biedt meestal weinig extra aan mensen die de codebase reeds beheersen.

Maar wanneer het doel is om de codebase te kunnen onderhouden, kunnen we eventueel een systeem opbouwen waarbij we een chatbot aanbieden die de specifieke context en bijzonderheden van het legacy project kent, en daar heel gerichte vragen over kan beantwoorden. Dit kan b.v. in CoPilot Studio. Wanneer dat niet goed genoeg werkt, kunnen we nog overwegen om manueel een knowledge base op te bouwen, gebruik makend van het AI, die dan weer door het AI kan worden gebruikt om vragen te beantwoorden.

Nog een andere optie bestaat eruit dat we specifieke informatie uit de codebase willen extraheren, zoals de business logica per afzonderlijke module, of pseudocode die menselijke developers kan helpen om de logica in een ander project te herimplementeren. (En uiteraard kan bij die tweede stap ook weer een AI worden ingezet.)

Kortom, met een beetje creativiteit kunnen we voor de meeste ad hoc analyses een betere aanpak verzinnen dan “analyseer er maar gewoon op los”. En het documenteren van een legacy systeem kan ook gewoon een eerste opstap zijn naar het herschrijven.

Besluit: vakmannen gevraagd

Zoals we hebben aangekaart, bieden LLMs ons stilaan erg krachtige mogelijkheden om onze Legacy Codebases aan te pakken, zéker wanneer we toegang hebben tot de grote en krachtige modellen die vandaag beschikbaar zijn. We zien echter ook dat het eigenlijk een heel goed gevulde gereedschapskoffer is, met een aantal krachtige “power tools”, en dat we moeten weten wat we ermee willen bereiken en hoe we deze best kunnen gebruiken.

We zitten nog niet op het punt dat alles automatisch gaat: we zullen dus nog steeds goede vakmannen nodig hebben om optimaal van dit gereedschap gebruik te maken. Onze raad aan developers is om zeker niet bang te zijn van AI en er geregeld gebruik van te maken bij de analyse en ontwikkeling van software: ervaring is de beste leerschool om de goede vakmannen die we hiervoor nodig hebben, op te leiden.

Voorlopig is dus het besluit: voor legacy code is AI geen wondermiddel, maar een handige gereedschapskist die je best kan uitproberen als deel van een bredere aanpak. Zoals gezegd kijken we later dit jaar eerder naar het midden en de rechterkant van het spectrum van legacy. Wij vermoeden dat hier meer mogelijkheden zijn tot automatisering van een aantal workflows, zeker als we ook dieper gebruik gaan maken van agents. Mogelijks kunnen we, voor iets eenvoudigere en repetitievere projecten, dus toch van “vakman” naar “fabriek” evolueren.

Nederlandstalige Versie

Dans le monde en perpétuelle évolution du développement logiciel, le code hérité est un sujet souvent abordé, mais finalement très peu compris. Le code hérité peut être défini de différentes manières, mais pour cette discussion, nous considérons qu’il s’agit de tout code qui est encore utilisé par une application importante, mais qui devrait être mis à niveau. Il se peut qu’un nouveau style architectural ou de nouvelles normes soient nécessaires, que des cadres obsolètes soient encore utilisés ou que le code soit écrit dans un langage de programmation qui n’est plus pris en charge. Ou alors le code n’est pas travaillé à la base, et se retrouve donc trop souvent pollué de correctifs rapides. En d’autres termes, il s’agit d’un code devenant de plus en plus difficile à maintenir et qui doit être réécrit, mais qui, pour une raison ou une autre, n’est pas pris en main. Certains parlent également de dette technique (technical debt).

Et si nous allions plus loin en essayant non seulement de gérer ce code, mais en plus de l’améliorer de manière proactive ? Pouvons-nous utiliser de nouvelles technologies comme l’IA pour y parvenir ?

Pourquoi le Code hérité est un problème

Le code hérité entraîne un certain nombre de défis. Le plus important d’entre eux est probablement le fait qu’il ralentit le développement et rend la maintenance difficile, ou qu’il nécessite des connaissances spécialisées et des outils obsolètes. Sans les connaissances et les outils adéquats, il peut représenter un coût énorme pour tout éditeur de logiciels. De plus, si les développeurs qui ont écrit le code original ont également quitté l’entreprise, le problème peut se révéler encore plus grave. En parlant des développeurs, c’est également la  dette technique qui constitue l’un des plus grands désagréments dans leur travail.

Il existe heureusement plusieurs façons de relever ces défis, même en utilisant les technologies les plus avancées, telles que l’intelligence artificielle.

Stratégies de gestion du code hérité

Il n’existe malheureusement pas de solution magique permettant de résoudre tous les problèmes liés aux code hérité en une seule fois. Il faut adopter une approche polyvalente faisant appel à plusieurs tactiques à la fois. Pensons à l’analyse du code, à la construction de nouveaux composants de manière modulaire et à la maintenance continue de la base de code pour s’assurer qu’elle reste à jour et bien adaptée aux besoins futurs.

Une première étape consiste à effectuer une analyse statique. Il s’agit d’examiner le code sans l’exécuter afin d’identifier les problèmes potentiels tels que les dépendances, les failles de sécurité ou les “code smells”. En utilisant des outils d’analyse statique, les développeurs peuvent mieux comprendre la structure du code et identifier les zones problématiques à améliorer. Ces outils sont en partie intégrés dans un bon environnement de développement, mais il est souvent possible de leur ajouter une puissance supplémentaire.

Après l’analyse du code, il est essentiel de mettre en place des bancs d’essai, conformément au paradigme du Test Driven Development (TDD). Cela permet de créer un environnement sûr dans lequel divers tests peuvent être exécutés afin de garantir que le code se comporte comme prévu. Les tests sont essentiels pour détecter rapidement les bogues et les problèmes de performance, avant que des changements ne soient apportés. Par ailleurs, si la couverture des tests est suffisante, il devient beaucoup plus sûr de remanier le code, ce que nous devons continuer à faire tout au long du cycle de vie afin de veiller à ce que le code continue d’être amélioré et n’atteigne surtout pas le legacy status. La mise en place de bancs d’essai soutient en outre les processus d’intégration et de déploiement continus (CI/CD)), qui sont essentiels pour la gestion de la qualité à long terme.

Une autre stratégie importante consiste à remanier le code pour le rendre modulaire. En décomposant une base de code monolithique en modules plus petits et plus faciles à gérer, les développeurs peuvent isoler les fonctionnalités, ce qui rend le code plus facile à comprendre, à maintenir et à tester (et peut-être même à réécrire). Cette modularisation permet également à différentes équipes de travailler simultanément sur différentes parties de la base de code, ce qui augmente la productivité et réduit la probabilité d’erreurs.

Le rôle de l’IA dans la gestion de code hérité

L’intelligence artificielle offre de nouvelles possibilités pour la gestion de code hérité, en particulier aujourd’hui, avec l’évolution rapide de l’IA générative. Bien que les capacités actuelles de l’IA soient souvent limitées à des tâches à petite échelle, son potentiel de transformation de la gestion du code hérité est considérable. L’IA peut aider à analyser le code, à écrire des tests, à remanier et même à générer de la documentation. Cela fait de l’IA un outil précieux pour les développeurs.

• Analyser le code : Les outils d’IA peuvent analyser le code pour en déterminer la structure et la fonctionnalité, ce qui permet d’obtenir des informations qui ne sont pas forcément évidentes pour les développeurs humains. Cela peut s’avérer particulièrement utile lorsqu’il s’agit de systèmes hérités complexes ou mal documentés.
• Rédaction de tests : L’IA peut également aider à générer automatiquement des tests basés sur le comportement du code, ce qui permet de gagner du temps et d’améliorer la qualité du code en identifiant les cas marginaux qui pourraient être négligés lors des tests manuels.
• Refonte du code : Les outils pilotés par l’IA peuvent suggérer des améliorations et aider les développeurs à remanier le code graduellement. Ce processus de remaniement continu permet de garder la base de code propre et maintenable, réduisant ainsi la dette technique au fil du temps.
• Génération de documentation : L’IA peut automatiquement générer et actualiser la documentation dans le cadre de CI/CD, ce qui est particulièrement utile dans les grands projets où la maintenance de la documentation peut être un défi.

Ces tâches peuvent principalement être effectuées par le même type d’outils d’IA : les assistants de codage.  Codacy, Snyk et, bien entendu, github CoPilot en sont quelques exemples.

Conclusion : l’avenir de la gestion de code hérité grâce à l’IA

La gestion de code hérité reste un défi complexe qui nécessite une approche stratégique. Cependant, l’émergence de l’IA en tant qu’outil d’analyse, de test et de remaniement du code offre des possibilités de relever ce défi de manière plus efficace et plus rentable. L’évolution de la technologie de l’IA générative est encore en plein essor, et son rôle dans la gestion de code hérité ne fera probablement que s’accroître, offrant davantage de possibilités d’améliorer les processus de développement de logiciels.

Toutefois, il ne faut pas non plus se focaliser sur l’IA : le meilleur remède contre le code hérité est encore de l’éviter, et ce, en appliquant les bonnes tactiques tout au long du cycle de vie du développement logiciel afin de maintenir la conception et le code aussi propres et à jour que possible. Dans un prochain article de blog, nous examinerons cette question plus en détail, en zoomant sur les différentes phases du cycle de vie afin de discuter de la manière d’éviter le code hérité et de la façon dont l’IA peut être utilisée au cours de chaque phase en vue d’y contribuer.

Version française

In de steeds veranderende wereld van softwareontwikkeling is legacy code een onderwerp dat vaak ter sprake komt, maar zelden goed wordt begrepen. Legacy code kan op verschillende manieren worden gedefinieerd, maar voor deze discussie beschouwen we ze als elke code die nog steeds wordt gebruikt door een belangrijke toepassing, maar die zou moeten worden geüpgraded. Misschien zijn er een nieuwe architectuurstijl of standaarden nodig, worden er nog verouderde frameworks gebruikt, of is de code geschreven in een niet langer ondersteunde programmeertaal. Of er is al te vaak niet meer ten gronde aan de code gewerkt en ze is vervuild geraakt met snelle fixes. Met andere woorden, het is code die steeds moeilijker te onderhouden wordt en die opnieuw moet worden geschreven, maar om een of andere reden niet wordt aangepakt. Sommigen noemen dit ook wel eens technical debt.

Maar wat nu als we een stap verder gaan en deze code niet alleen proberen te beheersen, maar ook proactief verbeteren? En kunnen we hierbij gebruik maken van nieuwe technologieën zoals AI?

Waarom Legacy-Code een Probleem Is

Legacy code brengt tal van uitdagingen met zich mee. De grootste daarvan is waarschijnlijk het feit dat ze de ontwikkeling vertraagt en onderhoud bemoeilijkt; of ze vraagt gespecialiseerde kennis van voorbijgestreefde hulpmiddelen. Zonder de juiste kennis en tools kan dit een gigantische kostenpost worden voor elk softwarebedrijf. Als de ontwikkelaars die de oorspronkelijke code schreven, bovendien ook nog het bedrijf verlaten hebben, kan het probleem nog groter worden. Over de ontwikkelaars gesproken: ook voor hen is technical debt een van de grootste ergernissen bij hun werk.

Er zijn gelukkig een aantal manieren om met deze uitdagingen om te gaan, zelfs met behulp van de meest geavanceerde technologieën, zoals kunstmatige intelligentie.

Strategieën om Legacy Code te beheren

Er bestaat, jammer genoeg, geen magische oplossing die alle problemen met legacy code in een keer oplost. Het vereist een veelzijdige aanpak waarbij meerdere taktieken tegelijkertijd worden toegepast. Denk aan het analyseren van de code, het modulair opbouwen van nieuwe componenten en het continu onderhouden van de codebase, om ervoor te zorgen dat deze up-to-date blijft en goed is aangepast aan toekomstige behoeften.

Een eerste stap is het uitvoeren van statische analyse. Hierbij wordt de code onderzocht zonder deze daadwerkelijk uit te voeren, om zo potentiële problemen te identificeren zoals afhankelijkheden, beveiligingslekken, of zogenaamde ‘code smells’. Met behulp van statische analysetools kunnen ontwikkelaars de structuur van de code beter begrijpen en probleemgebieden aanwijzen die verbetering behoeven. Deze tools zijn voor een deel ingebakken in een goede IDE, maar je kan er vaak nog extra kracht aan toevoegen.

Nadat de code is geanalyseerd, is het opzetten van testbanken essentieel, volgens het Test Driven Development (TDD) paradigma. Dit creëert een veilige omgeving waarin verschillende tests kunnen worden uitgevoerd om ervoor te zorgen dat de code zich gedraagt zoals verwacht. Testen is cruciaal om bugs en prestatieproblemen vroegtijdig op te sporen, voordat er wijzigingen worden doorgevoerd. Als er voldoende test coverage is, wordt het trouwens een stuk veiliger om de code te refactoren, hetgeen we tijdens de volledige levenscyclus zullen moeten blijven doen, om ervoor te zorgen dat de code steeds beter wordt en zeker geen legacy status krijgt. Het opzetten van testbanken ondersteunt daarnaast ook continuous integration en deployment (CI/CD) processen, die essentieel zijn voor kwaliteitsbeheer op lange termijn.

Een andere belangrijke strategie is het refactoren van de code om deze modulair te maken. Door een monolithische codebase op te splitsen in kleinere, beter beheersbare modules, kunnen ontwikkelaars functionaliteiten isoleren, wat de code gemakkelijker maakt om te begrijpen, te onderhouden en te testen (en eventueel zelfs om ze te herschrijven). Deze modularisatie stelt verschillende teams ook in staat om tegelijkertijd aan verschillende onderdelen van de codebase te werken, wat de productiviteit verhoogt en de kans op fouten vermindert.

De rol van AI in het aanpakken van Legacy Code

Kunstmatige intelligentie biedt nieuwe mogelijkheden voor het beheren van legacy code, zeker nu, met de snelle evolutie van generatieve AI. Hoewel de huidige mogelijkheden van AI vaak beperkt zijn tot kleinschalige taken, is het potentieel om legacy codebeheer te transformeren aanzienlijk. AI kan helpen bij het analyseren van code, het schrijven van tests, het refactoren en zelfs bij het genereren van documentatie. Dit maakt AI een waardevol hulpmiddel voor ontwikkelaars.

• Code Analyseren: AI-tools kunnen code analyseren om de structuur en functionaliteit te bepalen, waardoor inzichten ontstaan die mogelijk niet direct duidelijk zijn voor menselijke ontwikkelaars. Dit kan vooral nuttig zijn bij het omgaan met complexe of slecht gedocumenteerde legacy-systemen.
• Tests Schrijven: AI kan ook helpen bij het automatisch genereren van tests op basis van het gedrag van de code, wat tijd bespaart en de codekwaliteit verbetert door randgevallen te identificeren die tijdens handmatige tests over het hoofd kunnen worden gezien.
• Code Refactoren: AI-gestuurde tools kunnen verbeteringen voorstellen en ontwikkelaars helpen om code stapsgewijs te refactoren. Dit continue refactoringsproces helpt om de codebase schoon en onderhoudbaar te houden, waardoor technische schuld in de loop van de tijd wordt verminderd.
• Documentatie Genereren: AI kan automatisch up-to-date documentatie genereren en bijhouden als onderdeel van CI/CD, wat vooral nuttig is in grote projecten waar het bijhouden van documentatie een uitdaging kan zijn.

Deze taken kunnen veelal worden uitgevoerd door dezelfde type AI tools: de zogenaamde code assistants. Een aantal voorbeelden zijn Codacy, Snyk en, uiteraard, github copilot.

Conclusie: de toekomst van legacy codebeheer met AI

Het beheren van legacy code blijft een complexe uitdaging die een strategische aanpak vereist. Maar met de opkomst van AI als hulpmiddel bij het analyseren, testen en refactoren van code, ontstaan er mogelijkheden om deze uitdaging op een meer efficiënte en kosteneffectieve manier aan te pakken. Generatieve AI-technologie is nog in volle ontwikkeling, en haar rol in legacy codebeheer zal waarschijnlijk alleen maar toenemen, wat nog meer kansen biedt voor het verbeteren van softwareontwikkelingsprocessen.

We mogen ons echter ook niet blind staren op AI: het beste medicijn tegen legacy code is ze te voorkomen, en dit door gedurende de volledige softwareontwikkelingslevenscyclus de juiste taktieken toe te passen om het ontwerp en de code zo clean en up-to-date mogelijk te houden. In een toekomstige blogpost zullen we hier nog dieper op ingaan, waarbij we op de verschillende fasen van de levenscyclus inzoomen, om te bespreken hoe we legacy kunnen vermijden, en ook hoe AI tijdens elke fase kan worden ingezet als hulpmiddel daarbij.