Algemeen bekend: software bevat altijd defects. Minder bekend is, dat we 86% voor en tijdens de bouw kunnen elimineren, tegen een tiende van de kosten als dat pas later gebeurt.
Uit onderzoeken blijkt dat een uitstekend ingeregeld realisatieproces de doorlooptijd halveert en resulteert in meer wendbaarheid, een betere functionaliteit en aanzienlijk minder fouten bij productie.
In deze blog gaan we in op zeven verbeteringen die in de praktijk bewezen zijn te werken.
Schrijf goed commentaar
Een eenvoudige verbetering die toch vaak over het hoofd wordt gezien. Commentaar is bedoeld om bij later onderhoud inzicht te geven in wat een stuk code doet. Het helpt door aan te geven wat specifieke uitgangspunten zijn, bijzondere dingen die de code doet of dingen waarvan de programmeur aanneemt dat ze geregeld zijn.
Totaal nutteloos is commentaar als “Hier wordt het bedrag opgeteld bij het totaal”: dan kun je beter zelf-verklarende code schrijven. En dat brengt ons gelijk op het volgende punt:
Kies je namen van variabelen met zorg
Ooit code gezien als “A414 = recal(tekst)”? Zulke code is technisch leesbaar maar absoluut niet duidelijk. Bij onderhoud is de kans op fouten groot, want je zult maar A141 schrijven!
Er zijn over variabelenamen allerlei afspraken mogelijk. Het is goed als iedereen zich aan afspraken houdt want dat zorgt voor herkenbare code.
Welke afspraak ook geldt, kies altijd voor namen die gelijk aangeven waar het over gaat. “FactuurTotaal += FactuurregelBedrag(IndexOverRegels)” geeft aan wat de bedoeling is en helpt later onderhoud foutloos uit te voeren.
Bedenk de goede architectuur en hou je eraan
Eigenlijk een vanzelfsprekendheid, en toch, in de praktijk lukt het vaker niet dan wel. De kunst is om objecten zoveel mogelijk self-contained te maken: zoveel mogelijk gegevens binnen een object te houden. Maximale cohesie heet dat in het vakjargon. Samen met minimale koppeling: houd de koppelingen tussen objecten zo minimalistisch als mogelijk.
Die twee uitgangspunten helpen sourcecode robuust te maken: je kunt objecten (die een representatie van iets in de buitenwereld zijn) veranderen zonder vervelende bijeffecten. Je kunt functies toevoegen of een berekening verfijnen en dat zonder extra risico dat het geheel niet meer goed werkt. Wat daarvoor ook enorm helpt:
Valideer elke invoer op geldigheid
Als je object-georiënteerd werkt (en wie doet dat tegenwoordig niet?) kan een functie of eigenschap nu en in de toekomst vanuit elk willekeurig ander object worden benaderd. Je weet bij een aanroep niet of de argumenten zuiver zijn, en fouten in argumenten kunnen binnen een object ongewenste gevolgen hebben.
Al lijkt het op het eerste gezicht overbodig, als je elke invoer controleert voorkom je vervelende bijeffecten. Als bij onderhoud een aanroep verkeerd gedaan wordt zie je dat meteen en kun je nog tijdens coderen herstellen. Bovendien kan een foutmelding meer feitelijke details geven over de oorzaak.
Doe een uitgebreide foutcontrole
Meer dan eens zien we dat run-time fouten niet worden afgevangen en leiden tot een programma-crash. Niet alleen vermindert een crash het vertrouwen in een programma, het is erg lastig zoeken als een programma niet meer informatie geeft dan dat er, als voorbeeld, overflow optrad.
Een vergelijkbare maatregel is:
Ontwerp robuustheid, privacy en security
Robuuste programma’s, programma’s die niet bij elke storing de geest geven, ontstaan niet vanzelf. Het loont de moeite om vooraf na te gaan waar dingen verkeerd kunnen gaan en al maatregelen te treffen in het ontwerp.
Waarom ontwerp? Net als bij een gebouw is het heel moeilijk en tijdrovend achteraf structuren aan te passen. Als je eenmaal volgens een bepaald stramien programmeert en later blijkt dat, als voorbeeld, encryptie van gegevens nodig is, dan is dat ingrijpend. Terwijl het tijdens ontwerpen veel eenvoudiger is gewenste functionaliteiten op elkaar af te stemmen en te laten bouwen.
En dan als laatste:
Voorkom technische schuld
Agile ontwikkelen is een goede manier van programmeren, uitzonderingen daar gelaten. Eén van die uitzonderingen is dat programmeurs, in het zicht van de eindstreep, gauw nog wat wijzigingen aanbrengen. Copy-Paste, vlug wat variabelen aanpassen, en het werkt. Demo geven, volgende sprint.
Als dat regelmatig zo gebeurt ontstaat er een wirwar van routines en klassen, gedupliceerde code, en dode code die nooit meer wordt bereikt en wel onderhouden moet worden. Voor je het weet is de code van een systeem zo ontoegankelijk dat verder onderhoud onmogelijk wordt.
Wat dan moet gebeuren is een sprint om de code te refactoren, routines samen te voegen, variabele namen te herstellen, dat soort dingen. Een foutgevoelig proces dat, op de keeper beschouwd, niets oplevert.
Dat zijn de zeven meest cruciale maatregelen die je in de constructiefase kunt nemen om voortreffelijke code te schrijven, code die later geen onnodige defects bevat.
Een softwareproject waarvan de codekwaliteit onvoldoende is, dat is in wezen kapitaalvernietiging. Er gaat veel tijd en geld in onderhoud, tijd en geld die niet aan nieuwe dingen kan worden besteed. Een goed ingeregeld realisatieproces voorkomt dat. ITs Jaap kan u daarbij helpen.