De verborgen risico’s van legacy-code

Veel organisaties vertrouwen op rekensoftware of wetenschappelijke software die lang geleden is geschreven. In de dagelijkse hectiek staat niemand stil bij deze code; de ​​risico’s die inherent zijn aan dergelijke legacy-code blijven onopgemerkt. In deze blog belichten we de belangrijkste risico’s van legacy-code en wat u eraan kunt doen.

Risico 1: De ontwikkelaar met alle kennis gaat de deur uit

We zien regelmatig dat er slechts één expert is die alles van de code weet. Vaak is dit de oorspronkelijke ontwikkelaar. Wanneer er een probleem is met de code of er nieuwe functionaliteit moet worden gebouwd, loopt iedereen naar deze expert die het probleem snel oplost.

Maar naarmate de code ouder wordt, wordt ook de ontwikkelaar ouder. Op een gegeven moment is hij of zij niet meer beschikbaar. Zelfs als deze ontwikkelaar in goede gezondheid verkeert, komt er een moment dat hij of zij met pensioen gaat. En wat dan?

Als de code inderdaad belangrijk is, zal iemand de rol van deze ontwikkelaar moeten overnemen. Maar dit is niet per se eenvoudig. Ten eerste is legacy-code vaak slecht gedocumenteerd of is de documentatie verouderd. Bovendien is de code soms onbegrijpelijk voor iedereen behalve de ontwikkelaar. En het kan voor jonge ontwikkelaars die alleen Python of # kennen moeilijk zijn als de code is geschreven in een taal zoals Fortran of Java.

Risico 2: De code is niet onderhoudbaar

Veel codebases beginnen als kleine stukjes code die in de loop der tijd uitgroeien tot grote softwaresystemen. De oorspronkelijke structuur is meestal niet in staat om alle extra functionaliteit die erop wordt gestapeld te ondersteunen. Als er al überhaupt een originele structuur was. De nette term hiervoor is technische schuld. Maar eenvoudiger gezegd: de code is een veelkoppig monster geworden dat niemand meer durft aan te raken.

Dit is prima, totdat het ineens een probleem is. Er kunnen geen nieuwe functies meer worden toegevoegd; bugs kunnen niet meer worden opgelost. En niemand kan meer echt uitleggen hoe de code werkt. Zelfs als er geen wijzigingen nodig zijn, is het meestal onacceptabel voor een organisatie om te vertrouwen op software die niemand begrijpt.

Risico 3: Het is niet langer mogelijk om nieuwe versies te maken

In extreme gevallen is de codebase zelf verloren gegaan en is alleen de executable nog in gebruik. Nieuwe versies kunnen dan niet meer worden gegenereerd. Maar zelfs als de code er nog is, kan het erg moeilijk zijn om nieuwe versies te compileren.

Dat kan bijvoorbeeld plotseling een probleem worden als een van de bibliotheken die in de applicatie worden gebruikt, niet meer werkt met een nieuwe versie van het besturingssysteem. Als er geen actuele versie van die bibliotheek is, wordt het genereren van een werkende versie van het uitvoerbare bestand een acuut probleem.

Dit kan een nog groter probleem zijn als er geen compilers meer zijn voor de versie van de programmeertaal die werd gebruikt. Zo is er tegenwoordig nog maar beperkte tooling voor code geschreven in Pascal/Delphi.

Wat te doen met de risico’s in legacy-code?

Het belangrijkste advies bij het omgaan met legacy-code is om de risico’s tijdig aan te pakken. Als je wacht tot er een crisis ontstaat, kan het oplossen van problemen veel moeilijker of zelfs onmogelijk worden.

Als je afhankelijk bent van één ontwikkelaar en er gebeurt iets met die ontwikkelaar, kan al diens kennis in een oogwenk onherstelbaar verloren gaan. Of de software kan plotseling onbruikbaar worden als iemand ontdekt dat de code verkeerde antwoorden geeft en het onmogelijk is om dit te herstellen vanwege de spaghetti-structuur van de code.

Als u de risico’s in legacy-code wilt aanpakken, is het eerste wat u moet doen, de ernst van de situatie inschatten. Bij VORtech voeren we regelmatig zogenaamde modelscans uit, wat in feite audits zijn van legacysoftware. Ons rapport geeft een beoordeling van de situatie op alle relevante aspecten, met een overzicht van de risico’s en de ernst ervan, en wijst op de problemen die echt moeten worden aangepakt.

Typische maatregelen zijn: de code documenteren zodat de kennis van de ontwikkelaar wordt vastgelegd; de code refactoren om de structuur te verbeteren; en de juiste tests bouwen zodat de geldigheid van de code na een wijziging kan worden gecontroleerd.

Alleen in extreme gevallen is een volledige herschrijving van de code nodig: een pragmatische, gedeeltelijke herschrijving of refactoring is in de meeste gevallen voldoende om de codekwaliteit tot een acceptabel niveau te verbeteren. Maar ook als herschrijven van grotere stukken nodig is, kunnen we dat tegenwoordig met behulp van AI veel sneller en efficiënter en vroeger.

Bent u klaar om de risico’s in uw legacy-software aan te pakken?

Wij staan ​​klaar om u te helpen. Neem gerust contact met ons op om uw situatie te bespreken. Voor meer informatie kunt u onze whitepaper over legacy-code en onze blog raadplegen.