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
Goed verhaal. Een styleguide is uitermate belangrijk als het om overzichtelijke en, nog belangrijker, overdraagbare en begrijpelijke code moet gaan. Bij OutSystems hebben we dat opgelost door, binnen ons geintegreerde Agile Platform, gebruik te maken van Visual Modeling, waarbij mensen geen code meer hoeven te kloppen maar op een visuele manier een applicatie ‘samenstellen’ met beschikbare en herbruikbare componenten(UI, Business Logic, Integraties, Security, etc.). Dit heeft als direct voordeel dat de leercurves zeer kort zijn en overdraagbaarheid eenvoudig is vanwege de logische visuele (drag&drop)opbouw waardoor een applicatie snel te doorgronden is en verschillen in ontwikkelenstijlen tot een absoluut minimum beperkt kunnen worden.