Development / Opinie
Zonder styleguide mislukt agile-ontwikkeling
We leven in een wereld waar alles elke dag anders kan zijn. Waar op een dag iemand met een simpel idee plotselinge concurrentie biedt of een nieuwe wet een heel bedrijfsproces overhoop kan gooien. In deze wereld hopen we met agile werkstijlen steeds sneller te kunnen reageren. Jammer dat agile onmogelijk wordt gemaakt door ontbrekende kwaliteitsbewaking op codeniveau. Styleguide kan hierin volgens Jan-Hendrik Kuperus verandering brengen.
Bij softwareontwikkeling is kwaliteitsbewaking van cruciaal belang. Ontwikkelmethoden als RUP en Scrum kunnen heel duidelijk een nadruk leggen op de kwalitieitsbewaking, maar laten wel een heel belangrijk deel liggen. Waar het bij kwaliteit vaak om draait is in hoeverre de requirements zijn gehaald en hoe veel (of liever weinig) bugs er in het eindresultaat zitten. Dat is in termen uit de testwereld pure blackbox kwaliteitsbewaking. Maar hoe zit het met de code? Dat is tenslotte waar de hele applicatie uit bestaat. Dat juist daar kwaliteitsbewaking de slagingskansen van het product verhoogt, is men zich blijkbaar niet van bewust.
Stel dat zes mensen aan een nieuw software project werken. De ontwikkelaars gebruiken de best practices van de nieuwste agile methoden. Helaas blijkt dat de originele deadline niet gehaald kan worden en na ongeveer driekwart jaar ontwikkelen wordt besloten om een aantal extra developers in te zetten op het project. De kans is groot dat de nieuwe ontwikkelaars te maken krijgen met zes verschillende stijlen code. De kans is zelfs nog groter dat er naast het functioneel ontwerp en de requirements amper documentatie is. Dat betekent voor de nieuwe mensen een enorme drempel om te leren werken met het systeem, nog voordat ze een bijdrage kunnen leveren aan het verder ontwikkelen ervan. Alles behalve flexibel.
Tijdrovend
De reden dat stijlvolle code vaak verliest van ad hoc geschreven materiaal is simpel: "Dat kost toch alleen maar tijd?". Het beeld leeft bij veel ontwikkelaars en managers dat als code eenmaal werkt, het goed is en vooral niet meer gewijzigd moet worden. In plaats van het aanbrengen van stijl in de code kan de ontwikkelaar immers ook verder met het volgende onderdeel. Dat het in de toekomst meer tijd gaat kosten als er iets veranderd moet worden, lijkt iedereen over het hoofd te zien.De oplossing
Een goed gedefinieerde styleguide is in feite een aanvulling op de architectuur van de applicatie. De architectuur beschrijft hoe de applicatie er in grote lijnen uit zal zien. Een goede styleguide legt hiernaast ook nog eens op microniveau vast hoe de code er uit moet zien en met welke procedures de kwaliteit van de code hoog wordt gehouden. Afspraken over de maximale grootte van methoden, gebruik van witruimte, hoeveelheid documentatie, maar ook het regelmatige gebruik van bepaalde tools dragen bij aan een goed gefundeerde codestijl.
Alleen het hebben van een styleguide is uiteraard niet genoeg. De set met afspraken moet ook worden nageleefd. Het liefst zouden alle ontwikkelaars op een afdeling hetzelfde ‘stijldialect' moeten spreken. Dit dialect moet dusdanig standaard worden dat op termijn niemand er meer over nadenkt, maar het gewoon doet.
De voordelen
Wanneer je als ontwikkelaar bij een team komt dat goed gebruik maakt van een styleguide, is het inwerken een kwestie van de architectuur en de styleguide doorlezen. Daarna zouden er zich in de code van de applicatie geen verrassingen meer voor mogen doen. Bovendien zal een dergelijke applicatie ook in de toekomst beter te onderhouden zijn. Ook het overstappen naar andere beheerpartijen is eenvoudiger. De styleguide kan in dat geval als contractvoorwaarde worden meegenomen. De sourcecode zal immers meer weg hebben van een goed boek dan van een stapel bijeengeraapte krantenknipsels.
Kijk dus bij het ontwikkelen van applicaties niet alleen naar de kwaliteit die extern is te observeren, maar hou ook de interne kwaliteit hoog in het vaandel. Als de code makkelijker is om te lezen, is deze ook makkelijker te onderhouden, kunnen nieuwe medewerkers er sneller op ingewerkt worden en kunnen ook nieuwe features eenvoudiger worden ingebouwd.
Wees trots op je stijlvolle code!
Jan-Hendrik Kuperus, software engineer/Java-coach Sogeti
- 11:15 ICT Automatisering voor het eerst in het rood
- 09:19 SAP RPM ondersteunt vooral zichzelf
- 09:01 Oracle Primavera staat nog in de steigers
- 16:07 CBR vernieuwt PDA's na backofficeprobleem
- 10:18 Zakelijke tablet-PC's met aanraakscherm van HP
- 09:51 Intel introduceert Xeon processor 5600
- 08:54 Microsoft Office Enterprise Project Management
- 10:43 Autisten krijgen 130.000 euro startkrediet
- 09:37 HP PPM Center faalt op rapportagebied
- 09:00 Mobillion komt met videoplatform voor bedrijven
Kwaliteit en agile software development
Agile is “hot”. Agile projecten beloven sneller software te leveren, die na elke iteratie onmiddellijk in......
SAP-maatwerk, duur beheer
Als er veel wordt gesleuteld aan een SAP-applicatie, zorgt dat voor hogere beheerkosten na het project. Maar het is lastig aan de organisatie duidelijk te maken dat maatwerk niet altijd de beste oplossing is.
Meer maatwerk bij SAP maakt beheer duurderZakelijke tablet-PC's met aanraakscherm van HP
17-03 10:18 HP introduceert twee tablet-pc's met touchscreen voor zakelijke gebruikers. Daarnaast is de ProBook-serie uitgebreid met drie modellen die geschikt zijn voor zowel grote- als...
Development productenBol.com ontwikkelt sneller nieuwe applicaties
01-03 11:14 In de strijd om de beste business cases van 2009 heeft ook Xebia een inzending gedaan. Met het project 'Bol.com' dingen zij mee naar de prestigieuze Computable-prijs. Het...
Development praktijk'HRM-software kan nog volop verbeterd worden'
17-02 10:15 De afgelopen jaren heeft de ontwikkeling van hrm-software zo goed als stil gestaan. Dat meent althans Jan Hoogstra van KPMG IT Advisory. KPMG deed onderzoek naar de...
Development achtergrondGrip op de onbekende
14-03 10:42 Als testers moeten we steeds vaker op basis van minder concrete input gaan testen. De klant neemt besluiten/risico's om zo snel mogelijk naar de markt te kunnen. Men weet vaak...
Development opinie

