Legacy code
Een veel voorkomend vakjargon binnen de ICT en software ontwikkeling: Legacy Code. Ontwikkelaars praten er veel over. Vaker negatief dan positie. Want immers alleen jouw eigen code is natuurlijk de beste ter wereld! Wat is nu precies legacy code en is het dan altijd maar negatief of zitten hier ook positieve kanten aan? Ook een paar kleine punten die ik zelf altijd toepas wanneer ik in andermans code mag gaan wroeten.
Wat is dan legacy code?
Legacy code is de broncode die geërfd is van een collega developer of van een oudere versie van de software. Termen die hier bij kunnen komen zijn: niet te begrijpen code, moeilijk te wijzigen, spaghetti code, enige bron van informatie, jarenlange kennis en kunde in verwerkt. Niet alle termen zijn dus meteen negatief. Moet ik zelf wel bekennen dat over het algemeen de termen “niet te begrijpen” en “moeilijk te wijzigen” regelmatig in mijn gesprekken met andere developers naar voren zijn gekomen.
De twee kampen
Over het algemeen heb je twee kampen: De positieve en de negatieve, de managers en de developers. De “ja, we hebben tijd gewonnen” en de “nee, dit had ik sneller zelf opnieuw geschreven”. En alle smaken hier tussenin natuurlijk. De “ja, we hebben tijd gewonnen” zijn vaak ook gevaarlijke, als je niet oplet snijden ze één-op-één de planning terug wat hier origineel voor stond. Legacy code is natuurlijk niet iets nieuws. Het is wel sterk afhankelijk hoe de code wordt aangeleverd; als spaghetti code, met of zonder documentatie. Veel bepalend wat bruikbaar gaat zijn en hoeveel tijd het mogelijk gaat kosten. In de PC code werken ze hier dagelijks mee. Immers wordt Windows 10 niet elke maand herschreven wanneer er een software-update komt. Dit wordt allemaal netjes bijgehouden, totdat ze het na 10 jaar kotsbeu zijn en dan ineens roepen dat ze het niet meer ondersteunen en elke Windows gebruiker over moet naar de volgende versie. Binnen de PLC code ligt dit net wat anders.
Mijn eerste klus
Mijn allereerste klus, toen ik net van school af kwam, was het analyseren van een bestaande PLC code en deze vervolgens te optimaliseren. Ik kon al snel onderscheid maken tussen de subsystemen. Vol enthousiasme pakte ik pen en papier en begon met flow diagrammen te schetsen. Eerst hoe het erin zat om de kennis boven water te krijgen hierna hoe we het graag hadden willen zien. Het systeem had al enkele klussen uitgevoerd dus had zich bewezen voor het functioneren ervan. De gedachte was om de met elkaar verweven subsystemen uit elkaar te halen in de software. Wat opnieuw arrangeren en klaar is Kees. Niets was minder waar. Het bleek al snel spaghetti code te zijn en herschrijven van de volledige code was de beste optie. Projecturen waren hier niet op gebaseerd. Maar met het analyseren van de bestaande code kwamen er al bergen met kennis naar boven. Dat gaf een goede opstap verder te gaan om de functies uit te breiden en zo de subsystemen weer opnieuw op te bouwen. De nieuwe code werd in een simulatie omgeving getest. Tot op de dag van vandaag wordt deze code nog steeds gebruikt. Met gepaste trots kan ik ook wel zeggen dat we met het team van destijds een hele mooie prestatie hebben weggezet.
Legacy code: niet aanraken!
Een ander mooi voorbeeld is van een bedrijf in het dorp waar ik vandaan kom. Zij reviseren oude degelijke Duitse zaagstraten. Dus een grote zaagmachine waarmee verschillende soorten metaalprofielen op lengte worden gemaakt. Een hele berg per minuut, machines van 20 jaar oud of iets dergelijks. Prachtige techniek om naar te kijken. Deze machines hebben nog steeds de PLC van die tijd. Daar zitten de CE- en veiligheidsdocumentatie op. Iets wat goed is moet je niet kapot repareren!
Financieel gezien heeft het geen baat dat de PLC wordt vervangen voor een hypermoderne, supersnelle cpu met nieuwe programmatuur erin. De machine met zijn sequencing zal volledig moeten worden geanalyseerd, vertaald en dan geprogrammeerd worden. Dat soort machines zitten ook nog eens bordenvol met nokkenasjes die van alles getimed uitvoeren. Zoals ik al zei; prachtige techniek. Als automatiseerder jeuken je handen om het in een nieuw PLC jasje te kunnen steken, maar helaas gaat daar dan meteen je winst van het reviseerproject. Dus legacy code, wanneer je het niet aanraakt kan het prima nog jaren mee, zolang het mechanisch niet versleten is.
Rappe (w)rappers
Wat ik ook veel zie is, dat wanneer een bepaald subsysteem is getransformeerd tot een standaard product, die specifieke software niet meer wordt aangeraakt. Het is voor het bedrijf in beton gegoten. Wanneer dit standaard product in een nieuw systeem wordt geïntegreerd blijkt ineens de software niet meer te kunnen werken met het nieuwe systeem. Velen streven naar perfectie en zo zie je ook dat de manier van software ontwikkelen ook evolueert, van architectuur, programmeertaal tot specifieke algoritmes. Helemaal niks mis mee, betekent niet dat je legacy code weg moet gooien. In de software engineering wordt wel eens met de term ‘wrapper function’ gegooid. In basis is dit een functie die een onderliggende complexiteit van een andere functie omhult en verbergt, doormiddel van een goed gedefinieerde interface. Dit betekend dus eigenlijk dat we nooit meer legacy code weg hoeven te gooien. Niet persé dat natuurlijk, maar het helpt heel goed om oud en nieuw of code van engineer A en -B met elkaar te kunnen laten werken.
Arrangeren
De Dikke van Dale zegt het volgende:
ar·ran·ge·ren (arrangeerde, heeft gearrangeerd)
1in orde brengen; = rangschikken
2(muziek) bewerken van een compositie voor (een) ander(e) instrument(en)
Nummer 2 vind ik interessant. Wanneer je muziek voor ‘code’ vervangt en dat hetzelfde doet voor compositie naar ‘project’, voor wordt ‘van’ en instrument wordt voor het nette ‘collega’. Doordat software implementatievisies veranderen gedurende de tijd, kan het dus zijn dat een stukje code totaal niet meer logisch lijkt opgebouwd. Nog wel bruikbaar, maar het ligt niet meer in lijn met de rest van de code. Je kunt er dan voor kiezen om de code opnieuw te rangschikken volgens de gevolgde architectuur, maar dit gaat niet helemaal zonder slag of stoot. Door de kaarten wild te schudden kan het zomaar eens zijn dat er stukken code verloren gaan. Maar goed, daar kom je snel genoeg achter wanneer je systeem niet meer werkt zoals zou moeten.
Analyseren
Zelf vind ik legacy code lang niet altijd negatief. Immers, een collega developer heeft er zijn tijd, moeite en kennis ingestoken om het tot iets te maken. Of dit nu goed of slecht is, is veelal een grijs gebied omdat het ook deels is gebaseerd op persoonlijke meningen. Je kunt de spaghetti code wel onderscheiden van een gestructureerd stukje code, de kennis van de lariekoek. Wat ik heb geleerd, is om een gedegen analyse te maken van code om te bepalen wat de status is. Dit kan een dag of enkele dagen duren, afhankelijk van de beschikbare documentatie en de grootte van het project. Op basis hiervan maak ik pas mijn planning, voordat er door hoger management 400 uur wordt geschrapt, onder het mom van: “het heeft toch gewerkt met die software? Dan is het toch goed?!”. Dan kun je zo nu en dan nog voor verassingen komen te staan. Zelf vind ik het handig om met visio de functies en de samenhang weer te geven middels blokjes en pijltjes. Dit houdt het lekker visueel. Het opnieuw arrangeren van de code is net een schaakspel, waarbij je goed na moet denken over welke stappen je hebt gezet en welke je nog gaat zetten. Zelf maak ik ze nooit te groot, dan is het makkelijker om een keer een stapje terug te zetten. Verder vind ik het zelf altijd wel interessant om in andermans code te mogen zitten. Ik heb daar veel van geleerd door de jaren heen, hoe het mogelijk ook kan, maar zeker hoe het niet moet.
