Vaak wordt er binnen een IT-project een strakke deadline gesteld, waarbij IT-medewerks extra hard moeten werken om deze deadline te kunnen halen. Als gevolg hiervan worden bepaalde technische zaken slordig opgezet, aangezien er weinig tijd is om de zaken eerst goed door te nemen.
Bij dergelijke slordigheden moet voornamelijk gedacht worden aan architecturele beslissingen, die achteraf niet juist blijken te zijn. Kijken we naar programmeerwerk, dan hebben we hierbij te maken met code-structuren die in het eerste geval toereikend lijken, maar na verloop van tijd tekort komen als de functionaliteit verandert moet worden.
Complexe spaghetti-code
Vaak blijft programmacode zich ontwikkelen: Er wordt functionaliteit toegevoegd en weggehaald, naar mate het pakket van wensen en eisen verandert. Iedere verandering kan echter implicaties hebben op andere bestaande functionaliteit.
Bij spaghetti-code wordt de logica van een applicatie zo complex, dat bij een verandering er direct ongewenste bugs optreden. Deze bugs moeten vervolgens weer worden opgelost, wat leidt tot nieuwe bugs. Vanwege een te complexe structuur zijn er veel manuren nodig om een relatief simpele wijziging door te voeren.
Wie heeft dit geschreven?
Spaghetti-code wordt niet alleen gekenmerkt door complexe structuren. Ook de leesbaarheid van de code valt vaak tegen. Er wordt bijvoorbeeld een slechte naamgeving van variabelen of functies gebruikt, verschillende onderdelen hebben overlappende functionaliteiten, en er is geen gebruik gemaakt van commentaar in de code.
De code is hierdoor niet of nauwelijks over te dragen op een andere programmeur. Een nieuwe programmeur moet zich in eerste instantie inlezen in de code, wat vaak weken kan duren. Dit kost u geld.
Foute code in het kort
- Spaghetti-code is alleen leesbaar voor de oorspronkelijke auteur
- Nieuwe functionaliteit zorgt ervoor dat oude functionaliteit omvalt
Kostenplaatje
Misschien is het belangrijkste argument om spaghetti-code te voorkomen wel het kostenplaatje. Ook al lijkt het in eerste instantie een goed idee om snel tot resultaat te komen, de uiteindelijke kosten om alles beheersbaar te houden zullen de initiele kosten overtreffen. De totale kosten zullen hierdoor veel hoger zijn dan de kosten die zouden worden gemaakt wanneer in eerste instantie de code goed was opgezet.
Het ideale plaatje
Om code goed op te zetten is het niet alleen belangrijk dat er netjes wordt geprogrammeerd. Het is ook nodig dat er in eerste instantie goed na wordt gedacht over de applicatie als geheel. Dit betekent dat er vaak veel tijd wordt gespendeerd aan denkwerk of het opzetten van een achterliggende architectuur, zonder dat er direct functionaliteit zichtbaar is.
Een deadline kan meespelen in het ontstaan van spaghetti-code, maar het betekent niet dat iedere deadline rommelige code veroorzaakt. Het succes van de code ligt ook vaak aan de competenties van de betrokken programmeurs. Een programmeur dient eigenlijk ook een systeem-architect te zijn om de business logica op een abstract niveau te kunnen vertalen naar een technische architectuur.
Lees meer
