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.

We hebben waarschijnlijk het moment bereikt waarop de hype over AI op zijn grootst is: men is langs één kant laaiend enthousiast over AI, maar hier en daar raken mensen al gedesillusioneerd. Ook spreekt men meer en meer over een bubbel in de markt van de grote tech-spelers. Maar hoe nuttig zijn LLMs momenteel nu echt? Kunnen we nog veel verbetering verwachten? En hoe zit dat met die hallucinaties?

Waarschijnlijk heb je het zelf al meegemaakt: je praat met ChatGPT of een andere slimme chatbot, en deze vertelt je vol vertrouwen iets waarvan je weet dat het niet klopt. Of je bent een developer, en die coding assistant werkt best wel goed, tot je naar wat meer verlangt, maar die nieuw toegevoegde feature aan je programma hopeloos tekort schiet. En dat zijn nog maar je eigen, bescheiden, ervaringen: wat je hoort van anderen, of op het nieuws of via sociale media, is allicht nog veel extremer: vreugdekreten over hoe we, dankzij AI, een volgende industriële revolutie tegemoet gaan en doemberichten dat mensen hun job erdoor zullen verliezen, versus artikels die vertellen over hoe AI projecten maar blijven mislukken en verhalen over wat voor belachelijke of zelfs gevaarlijke hallucinaties uit de AI chatbots blijven komen. Dus wat moet je er nu van denken?

Om dit enigszins beter te begrijpen: een heel kort, niet te technisch, intermezzo over wat LLMs alweer zijn (mijn excuses dat ik daarbij opzettelijk vaag blijf: voor een betere uitleg raad ik de blogposts van mijn collega’s aan): AI taalmodellen doen voorspellingen over wat het volgende stukje tekst moet zijn, aan de hand van probabiliteiten. Ze zijn getraind op zó veel tekst, dat de in se willekeurige zinnen die eruit rollen, daardoor van een hoge kwaliteit zijn en perfect juist klinken (en het vaak genoeg ook zijn). Echt nadenken zoals een mens doen ze dus niet; het is heel erg “text based”. Het is meer het vinden en herhalen van patronen, dan écht begrip; de intelligentie erin ontstaat als emergent verschijnsel. De leukste naam die ik er al voor gehoord heb is “probabilistische papegaai“.

Volgens Gartner zitten we nu al voorbij de piek van opgeblazen verwachtingen en in de trog van desillusie. Ook andere verslaggevers spreken van een hype of bubbel. Er worden ettelijke miljarden geïnvesteerd in nieuwe datacenters om de AI-machine te voeden, soms zelfs met inbegrip van nieuwe energiecentrales, terwijl de winstgevendheid voorlopig nog ver te zoeken is. Is het effectief een bubbel? Dat hangt af van je definitie van bubbel… Het lijkt in elk geval een grote, soms geostrategische gok, op de volgende technologie die de wereld drastisch kan veranderen en verbeteren, of zelfs veroveren; misschien zelfs vernietigen… En op moment van schrijven deinzen sommigen er niet van terug om te zeggen dat de luchtbel weldra zal barsten, met als belangrijkste argumenten de circulaire investeringen van een aantal grote bedrijven in elkaars capaciteit, en het openstellen van ChatGPT voor erotische inhoud, een zet die meer op cashflow-druk dan op ruimdenkendheid lijkt te duiden.

Bijkomend probleem is dat momenteel ook de investeringen in LLM de wind wegnemen uit de zeilen van een aantal andere zeer nuttige AI-technologieën (maar wanneer de storm is gaan liggen kunnen de datacenters misschien wel van pas komen voor deze laatste). Stemmen gaan trouwens op dat we voor échte intelligentie nóg een andere AI technologie zullen moeten ontwikkelen (al zal het uiteindelijk wel iets zijn dat gebruik maakt van alle rekenkracht die we nu uitrollen), en dat LLMs stilaan op hun limieten botsen, met steeds kleiner wordende incrementele verbeteringen (en opgeklopte testresultaten). Ondanks de bittere les dat meer data en rekenkracht de grootste vooruitgang mogelijk hebben gemaakt, gaan er nu stemmen op dat men met LLMs geen Artificial General Intelligence (AGI) zal kunnen bouwen; men zal nieuwe research moeten aanboren. En ondertussen kan men ook aantonen dat de hallucinaties er gewoon bij horen en allicht nooit volledig weg te krijgen zullen zijn: onkruid vergaat niet.

Maar in een tuin waar onkruid groeit, kan men toch ook goede dingen laten groeien, met wat moeite. En in zo’n tuin hebben LLMs wel degelijk hun nut: daar waar een taak vooral gaat over tekst en taal, zijn ze bijvoorbeeld heel krachtig (denk aan samenvatten, vertalen, zaken verzinnen, zeer eenvoudige redeneringen opbouwen, …). En ook voor programmeren (wat een soort omgaan met een specifiek soort taal is), merken we enthousiasme van vele developers die hun productiviteit zagen stijgen (maar security blijft een aandachtspunt!). Als algemene slimme assistent kan het ook een rol spelen, zolang de gebruiker zelf voldoende onderlegd is in een onderwerp en kritisch is ingesteld. En misschien moeten ze gewoon nog verder evolueren tot de beste tool voor een bepaalde niche van taken.

Ook zelf heb ik een genuanceerd verhaal te vertellen: in mijn vorige blogpost had ik het over een aantal kleine successen met vibe coding, en de beperkingen van het AI, wanneer de taken groter of complexer worden. Hetzelfde zie ik in het werk dat ik sindsdien heb verricht: het analyseren en vertalen van legacy code met behulp van deze taalmodellen. Ook daar dus een gemengd succes: geen toverstokjes, nauwelijks of moeilijk te automatiseren, maar toch een zichtbare tijdswinst bij het begrijpen van middelmatig grote en het herschrijven van kleine stukken code van dit soort projecten (meer details daarover in een komende blogpost).

Conclusie

Een LLM is slechts één van de vele intelligente technologieën die we momenteel aan onze vingertippen hebben, al zij het wel de meest toegankelijke en zichtbare. Misschien vandaar zowel de hype als de controverse?

Zijn LLMs nuttig? Ik zou durven argumenteren van wel. Met de huidige stand van de technologie is het echter van groot belang dit te nuanceren: zet een LLM als powertool ter beschikking van een menselijke expert! De echte waarde ligt dus niet in vervanging, maar in augmentatie. Laten we het komende jaar kijken of alle agent-based systemen hier verandering in brengen…

Nous avons probablement atteint le point culminant du battage médiatique autour de l’IA : d’un côté, l’IA suscite l’enthousiasme, de l’autre, elle commence déjà à créer la désillusion. On parle aussi de plus en plus d’une bulle sur le marché des grands acteurs technologiques. Mais quelle est réellement l’utilité des LLM à l’heure actuelle ? Pouvons-nous encore espérer de nombreuses améliorations ? Et qu’en est-il des hallucinations ?

Vous avez probablement déjà vécu cette situation : vous discutez avec ChatGPT ou un autre robot conversationnel « intelligent » et celui-ci produit sans détour une affirmation que vous savez fausse. Ou vous êtes développeur et votre assistant de codage fonctionne plutôt bien, jusqu’à ce que vous en demandiez plus, mais la nouvelle fonctionnalité ajoutée à votre programme est loin d’être à la hauteur. Et ce ne sont là que vos propres expériences, modestes. En effet, les expériences relatées par les autres ou celles relayées dans la presse ou sur les réseaux sociaux sont sans doute bien plus extrêmes : d’un côté, des cris de joie à l’idée que l’IA amorce une nouvelle révolution industrielle et des messages alarmistes selon lesquels elle entraînera des pertes d’emploi, de l’autre, des articles qui disent que les projets d’IA ne cessent d’échouer et des récits sur les hallucinations ridicules, voire dangereuses que ne cessent de produire les robots conversationnels basés sur l’IA. Que faut-il dès lors en penser ?

Pour une meilleure compréhension, un bref intermède, pas trop technique, sur ce que sont les LLM (je vous prie de m’excuser de rester volontairement vague à ce sujet : pour une meilleure explication, je vous recommande les articles de blog de mes collègues) : les modèles de langage d’IA prédisent ce que doit être le prochain morceau de texte, en se basant sur des probabilités. Ils ont été entraînés sur une telle quantité de texte que les phrases aléatoires qu’ils produisent sont de grande qualité et semblent parfaitement cohérentes (et le sont souvent). Ils ne réfléchissent donc pas comme un être humain : leur fonctionnement est très “basé sur le texte”. Il s’agit davantage de trouver et de répéter des modèles que de faire preuve d’une véritable compréhension ; l’intelligence qui s’en dégage est un phénomène émergent. Le nom le plus cocasse que j’ai entendu jusqu’à présent est “perroquet stochastique“.

Selon Gartner, nous avons déjà dépassé le pic des attentes déraisonnables et nous sommes désormais dans la phase de désillusion. D’autres journalistes parlent d’un effet de mode ou d’une bulle.
Des milliards sont investis dans de nouveaux centres de données pour alimenter la machine IA, parfois même avec de nouvelles centrales électriques, alors que la rentabilité est encore loin d’être atteinte. S’agit-il réellement d’une bulle ? Tout dépend de votre définition d’une bulle… En tout cas, cela ressemble à un pari énorme, parfois géostratégique, sur la prochaine technologie qui pourrait changer et améliorer radicalement le monde, voire le conquérir, voire le détruire… Tandis que j’écris ces lignes, certains n’hésitent pas à affirmer que la bulle est sur le point d’éclater, avec comme principaux arguments les investissements circulaires d’un certain nombre de grandes entreprises dans leurs capacités respectives et l’ouverture de ChatGPT au contenu érotique, une décision qui semble davantage refléter une pression sur les flux de trésorerie qu’une ouverture d’esprit.

Un autre problème réside dans le fait qu’actuellement, les investissements dans les LLM freinent également le développement d’un certain nombre d’autres technologies d’IA très utiles (mais lorsque la tempête se sera calmée, les centres de données pourraient bien s’avérer utiles pour ces dernières). Certains pensent d’ailleurs que pour obtenir une véritable intelligence, nous devrons développer une autre technologie d’IA (même si, au final, celle-ci utilisera toute la puissance de calcul que nous déployons actuellement ), et que les LLM atteignent peu à peu leurs limites, avec des améliorations incrémentielles de plus en plus faibles (et des résultats de tests gonflés). Malgré la leçon amère que davantage de données et de puissance de calcul ont permis les plus grands progrès, des voix s’élèvent maintenant pour dire qu’on ne pourra pas construire une Intelligence Artificielle Générale (AGI) avec les LLM ; il faudra se tourner vers de nouvelles recherches. Et entre-temps, on peut aussi démontrer que les hallucinations en font tout simplement partie et qu’elles ne disparaîtront probablement jamais complètement : les mauvaises herbes ne disparaissent jamais.

Mais dans un jardin envahi par les mauvaises herbes, de belles plantations sont tout de même possibles, moyennant quelques efforts. Et dans un tel jardin, les LLM ont bel et bien leur utilité : lorsqu’une tâche concerne principalement le texte et le langage, ils sont par exemple très performants (pensez au résumé, à la traduction, à la création, à la construction de raisonnements très simples…). Et même pour la programmation (qui est une sorte de manipulation d’un langage spécifique), nous constatons l’enthousiasme de nombreux développeurs qui ont vu leur productivité augmenter (mais la sécurité demeure un point d’attention !). En tant qu’assistant intelligent général, les LLM peuvent également jouer un rôle, à condition que l’utilisateur soit suffisamment informé sur un sujet et ait l’esprit critique. Et peut-être doivent-ils simplement continuer à évoluer pour devenir le meilleur outil pour une certaine niche de tâches.

J’ai moi-même une histoire nuancée à raconter : dans mon précédent article de blog, j’ai évoqué quelques petits succès avec le vibe coding, ainsi que les limites de l’IA lorsque les tâches deviennent plus importantes ou plus complexes. Je constate la même chose dans le travail que j’ai effectué depuis : l’analyse et la traduction de code hérité à l’aide de ces modèles de langage. Là aussi, le succès est mitigé : pas de baguette magique, difficile voire impossible à automatiser, mais tout de même un gain de temps visible dans la compréhension des codes de taille moyenne et la réécriture des petits morceaux de code de ce type de projets (plus de détails à ce sujet dans un prochain article de blog).

Conclusion

Un LLM n’est qu’une des nombreuses technologies « intelligentes » disponibles actuellement, même s’il s’agit de la plus accessible et la plus visible. C’est peut-être ce qui explique à la fois l’engouement et la controverse qu’elle suscite.

Les LLM sont-ils utiles ? J’oserais dire que oui. Cependant, compte tenu de l’état actuel de la technologie, il est fondamental de nuancer cette affirmation : mettez un LLM à la disposition d’un expert humain en tant qu’outil puissant ! La véritable valeur ne réside donc pas dans le remplacement, mais dans l’augmentation. Nous verrons si tous les systèmes basés sur des agents changeront la donne au cours de l’année à venir.

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.

De voordelen van het gebruik van EDA zijn legio. Maar hoe gebruik je nu eigenlijk EDA in de praktijk? Wat als je al een enorm ecosysteem van toepassingen hebt die enkel en alleen via synchrone communicatie worden geïntegreerd en je nog nagenoeg geen business Events publiceert? In deze blog-post stellen we een methode voor om een applicatie te laten evolueren om meer Events te gaan publiceren.

Binnen de instellingen van de Sociale Zekerheid groeit het besef dat Event Driven Architecture (EDA) erg nuttig kan zijn als onderdeel van de integratiestrategie (we hebben hierover reeds uitvoerig geblogd en de belangrijkste voordelen zijn ook samengevat in ons webinar van november). We hebben in ons IT ecosysteem echter al een enorm groot aantal systemen en applicaties die hier nog niet noodzakelijk van gebruik maken. Het zou zonde zijn als we ons voor EDA enkel zouden focussen op nieuwe toepassingen – de belangrijkste business Events in het ecosysteem worden waarschijnlijk al gecapteerd door reeds bestaande diensten. Maar hoe kunnen we er dan voor zorgen dat deze Events effectief via EDA technologie – als effectieve IT Events – worden gepubliceerd en beschikbaar worden in het ecosysteem voor subscribers?

In deze blog zullen we een mogelijke stap voor stap benadering bekijken, waarmee we reeds bestaande toepassingen meer Event-Driven kunnen maken. Niet alleen maar door ze stelselmatig meer Events te laten publiceren (al zal dit een logische eerste stap zijn), maar ook door ze hun eigen Events te laten gebruiken.

Een noodzakelijke disclaimer hier, is dat het Event-Driven maken van toepassingen niet het enige is dat zal moeten gebeuren om te evolueren naar een ecosysteem met een ruim en matuur gebruik van EDA. Wat dit allemaal zou moeten inhouden (b.v. het opzetten van een goede Event Broker), staat momenteel nog ter discussie in onze innovatiewerkgroep, al kunnen we daaromtrent uiteraard onze mening geven in een toekomstige blog-post…

Fase 1: Event-Publicatie, “Na de Feiten”

De eerste stap in het refactoren van een bestaande toepassing is meteen ook de belangrijkste voor het ecosysteem: het publiceren van Events. We moeten dit in eerste instantie als een zuivere toevoeging aan de functionaliteiten beschouwen, zonder enige impact op de reeds bestaande. Daarom zullen we een Event pas publiceren “na de feiten”, i.e. nadat alle zaken die normaal gezien door de toepassing worden gedaan, reeds zijn uitgevoerd.

Laten we kijken hoe we dit kunnen doen voor één Event (we kunnen dit uiteraard herhalen om de toepassing meerdere Events te laten publiceren). Beschouw het (informele) sequentiediagram in Fig. 1: een bepaald commando komt binnen in de toepassing (normaal gezien via een API), en er is besloten dat dit aanleiding geeft tot het voorkomen van een bepaald business Event; we willen dit Event dan ook publiceren als gevolg van het ontvangen commando. De toepassing doet reeds ander werk (“Internal Work”) als gevolg van het commando, en het commando moet worden beschouwd als een transactie (zoals we zien in “Command Transaction”).

Om het Event te publiceren met een minimale impact op de werking van de toepassing, zullen we het (via het “EDA Subsystem”) publiceren nadat we de transactie hebben vervolledigd. In de praktijk zal dit b.v. kunnen door (bínnen de transactie) een extra taak in de toepassing te creëren in een aparte thread, die pas wordt uitgevoerd nadat de transactie is afgewerkt (de “publicatietaak”). Het creëren van deze taak zal een zo eenvoudig mogelijke instructie zijn in de programmatie, met een veel kleinere kans op falen dan het effectieve uitvoeren van de taak, en kunnen we daarom dus veilig binnen de transactie doen.

Wanneer dan, achteraf, de publicatietaak effectief wordt uitgevoerd, zal dit door het EDA subsysteem gebeuren, en zullen we dan effectief het Event publiceren (in eerste instantie kan dit als “mock”: een operatie zonder enig effect, later zullen we het Event effectief aanbieden aan de Event Broker). Aldus komt het Event terecht in het ecosysteem en kan men het nuttig beginnen gebruiken.

Fase 2: Event-Publicatie, “In Transactie”

In fase 1 hebben we, om een zo min mogelijke impact te hebben op de performantie en kans op falen van de transactie, een nogal gekunstelde manier moeten gebruiken om het Event te publiceren búiten de transactie om. Een logische volgende stap is dan ook om het publiceren van het Event onderdeel te laten uitmaken van de transactie. Bijgevolg zullen we dan ook garanderen dat, indien de transactie volledig wordt uitgevoerd, het Event ook wordt gepubliceerd. Dit kan een garantie zijn van groot belang voor de Event subscribers verderop in het ecosysteem, vanaf nu kan men erop rekenen dat álle Events van dat type de revue zullen passeren.

Beschouw nu Fig. 2: het verschil met de vorige tekening is niet groot: we zien nu dat het EDA subsysteem wordt opgeroepen tijdens het uitvoeren van het normale werk als gevolg van het binnenkomende commando. Wanneer het Event is gepubliceerd én het andere werk is uitgevoerd, kan de transactie worden afgewerkt. Publicatie van het Event betekent dat we bevestiging hebben gekregen van de Event Broker dat het goed door deze is ontvangen, maar uiteraard niet noodzakelijk reeds naar de subscribers is gestuurd. Dit is net één van de voordelen van de asynchrone communicatie binnen EDA.

Bij deze fase moeten we er wel op letten dat we op een zeer betrouwbare Event Broker kunnen rekenen. Vermits deze online moet zijn om het Event in ontvangst te nemen tíjdens de transactie, zou de transactie worden geblokkeerd indien er daarbij een fout optreedt. Men zou dit als een nadeel kunnen beschouwen, maar we moeten er aan denken dat het Event kan worden gebruikt als plaatsvervanger van het eventuele rechtstreeks oproepen van alle subscribers, indien deze tijdig op de hoogte moeten worden gebracht van wat er wordt beoogd met het uitvoeren van de transactie. Indien men tijdens het verwerken van het commando normaal gezien beroep deed op achterliggende APIs van andere systemen, kan men deze andere systemen nu in plaats daarvan inschrijven op het Event, waardoor deze API calls niet meer hoeven gebeuren en onze toepassing dus niet langer afhankelijk is van de achterliggende. Op deze manier vermínderen we de kans op falen van de transactie indien de Event Broker betrouwbaarder wordt gemaakt dan de andere achterliggende systemen.

Fase 3: Event-First Programming, Transactioneel

Tot nu toe waren onze wijzigingen in de oorspronkelijke toepassing vrij conservatief: het doel was een reeds bestaand systeem Events te laten publiceren ten voordele van het grotere ecosysteem (we zagen daarbij dat dit in principe kan leiden tot het verminderen van het gebruik van APIs van andere systemen en op die manier tot minder afhankelijkheden).

Vanaf fase 3 zullen we echter ook de eigen toepassing gebruik laten maken van de eigen Events, alvorens, als gevolg van het ontvangen van deze Events, het normale werk te doen. Dit noem ik Event-First programming, en het laat toe om een standaard stramien te hebben om te reageren op binnenkomende informatie: alle belangrijke wijzigingen komen nu binnen via Events. Dat betekent dat we op dezelfde manier zullen reageren op de eigen Events, als op andere Events van het ecosysteem, komende van andere toepassingen.

Beschouw Fig. 3: om de transactie (voor het commando) op te volgen, voeren we een extra controller in. Als eerste stap wordt er nu een Event gepubliceerd als gevolg van het binnenkomende commando. Het EDA subsysteem zal dit Event publiceren, en óók de applicatie zelf (naast eventuele andere in het ecosysteem), zullen er zich voor inschrijven. Wanneer het Event dan opnieuw binnenkomt in de applicatie ten gevolge van de subscription, wordt het effectieve werk uitgevoerd dat de applicatie moet doen ten gevolge van het commando. Om de transactie, ten slotte, te kunnen beëindigen, moet de controller worden ingelicht wanneer het werk is gedaan. Hier zijn we vrij om dit opnieuw via een Event te doen, of op een andere manier (gebruik makend van een of ander bestaand mechanisme voor communicatie tussen threads dat wordt aangeboden door de programmeertaal).

Indien we deze fase voor een toepassing volledig implementeren (i.e. toepassen op álle binnenkomende commando’s), kunnen we de toepassing verder gaan modulariseren volgens het principe van CQRS (Command & Query Responsability Segregation). Dit wil zeggen dat modules die reageren op commando’s apart zullen staan van modules die reageren op queries.

Als u heeft opgemerkt dat het een beetje raar is dat we via een extra controller gaan wachten op een bericht dat het werk, als gevolg van ons Event, is gedaan en we onze transactie nu kunnen beëindigen, dan heeft u gelijk: we hebben deze fase eerder als illustratie ingevoegd om het contrast met de volgende fase te verduidelijken. Maar het lijkt ons eerder aangeraden om fase 3 over te slaan en onmiddellijk gebruik te maken van Eventual Consistency!

Fase 4: Eventual Consistency

Tot nu toe hielden we sterk vast aan de transactionaliteit van het uitvoeren van ons binnenkomende commando. Eigenlijk is dit een kunstmatig opgelegde beperking, die ons ervan weerhoudt maximaal in te zetten op de availability van het ecosysteem (zie: CAP theorema). In fase 4 zullen we gaan vertrouwen in het concept Eventual Consistency: we gaan het commando als uitgevoerd beschouwen, van zodra we zeker zijn dat ons Event is gepubliceerd. We gaan er dan van uit dat de toestand van de applicatie (en, per extensie, van het volledige ecosysteem), na verloop van tijd (“eventually”) consistent zal worden en alle nodige zaken zijn gebeurd als gevolg van het commando (ook in andere toepassingen!). Typisch zal deze tijd redelijk kort zijn; we laten enkel de mogelijkheid open dat het langer kan duren, omdat we het falen van een achterliggend systeem nu kunnen toelaten (zie ook het PACELC theorema).

Beschouw nu Fig. 4: eigenlijk doen we hier hetzelfde als in Fig. 3, maar dan met een vereenvoudiging: er hoeft geen feedback meer te komen van “Internal Work” naar de “Controller” voor het commando. Deze laatste zal nu simpelweg het commando als uitgevoerd beschouwen wanneer het Event is verstuurd (we hadden de extra controller eigenlijk terug weg kunnen laten). Met deze manier van werken verkrijgen we het meeste voordeel uit EDA voor de eigen applicatie (het voordeel voor het ecosysteem kregen we reeds in fase 1).

Besluit

In deze blog-post lieten we een mogelijke, stapsgewijze evolutie zien van een computerprogramma dat bij het uitvoeren van een commando een business Event zou moeten publiceren. In de eerste fases wordt de impact geminimaliseerd; in latere fases wordt de toepassing zelf meer Event Driven gemaakt. Het spreekt voor zich dat deze manier van werken niet de enige goede is, en dat men ook niet steeds álle stappen hoeft te zetten.

We beseffen dat de vier fases zeer verboos zijn gedocumenteerd in dit schrijven; voor programmeurs kan dit nogal overbodig lijken. Maar we richten deze blog ook op niet-programmeurs, zodat voor hen een tipje van de sluier wordt gelicht over hoe programmeurs moeten nadenken over het echte binnenwerk van een toepassing, en hoe dit in verband staat met de communicatie op schaal van het ecosysteem waarbinnen een toepassing opereert.

Het publiceren van herbruikbare business Events is cruciaal voor een groot IT ecosysteem, waarbij integraties, louter op basis van APIs, op langere termijn voor een verminderde resiliëntie en agility kunnen zorgen. Een goed evenwicht tussen integraties via zowel synchrone als asynchrone communicatie, waarbij EDA als evenwaardig wordt beschouwd aan API, leidt tot het meest gezonde ecosysteem van applicaties.

In dit webinar gaan we in de eerste plaats in op waarom EDA belangrijk is, wat EDA precies doet en de plaats die het kan innemen in een toekomstbestendige IT-architectuur zoals wordt nagestreefd in “eGov 3.0”. We focussen vooral op het waarom van EDA, en op welke manier dit paradigma zijn voordelen biedt wanneer het wordt gecombineerd met andere belangrijke ontwerpprincipes. We zullen een “bird’s eye view” ontwikkelen op hoe applicaties op zich, maar ook het ruimere IT-landschap, eruit zouden kunnen zien met een groter gebruik van dit paradigma. Op een aantal zaken zoomen we technisch dieper in om een voldoende ruim begrip van EDA te bekomen, zonder al te veel in detail te gaan.

Een greep uit de andere concepten die we op deze manier toegankelijk willen maken via dit webinar: Domain-Driven Design (DDD), event storming, hexagonal architecture, microservices, modular architecture, loose coupling, … Ten slotte kijken we ook naar wat er bij zal komen kijken om “meer” of “voldoende” EDA te hebben in onze portfolio, en op de “mindset shift” die daarbij als belangrijkste nood – en obstakel – naar boven komt.

Voici quelques-uns des autres concepts que nous nous souhaitons rendre accessibles de cette manière lors de ce webinaire : Domain-Driven Design (DDD), event storming, architecture hexagonale, microservices, architecture modulaire, loose coupling… Enfin, nous examinerons également les éléments à prendre en compte pour avoir “plus” ou “suffisamment” d’EDA dans notre portefeuille, ainsi que le changement de mentalité qui apparaît comme le principal besoin – et obstacle – pour y parvenir.

Recording

Presentation