Wanneer is goed, goed genoeg?

Toekomstbestendig, kwalitatief hoogstaand, veilig… Tijdens het ontwikkelen van software moet je als developer rekening houden met allerlei voorwaarden waaraan voldaan moet worden. Deze termen klinken mooi, maar het blijven ‘holle’ termen als we eigenlijk niet weten wat er precies mee bedoeld wordt. En hoe meten we of we voldoen aan deze voorwaarden?

‘Echt beter’

Wat ik altijd leuk vind, is om in ‘discussie’ te gaan over de vraag waarom het toch ‘echt beter’ is om voor werkwijze X te kiezen, terwijl werkwijze Y in de helft van de tijd kan worden uitgevoerd. Jammer genoeg geloven mijn collega’s of klanten mij niet altijd op mijn blauwe ogen, en moet ik ‘echt beter’ toch even uitleggen.

Er is een hoop waar we als ontwikkelaar op moeten letten. Als we bijvoorbeeld het woord ‘toekomstbestendig’ nemen, heeft dit tijdens het maken van code wel een duidelijke definitie: Code moet uit te breiden of aan te passen zijn zonder dat het bestaande functionaliteit breekt. Het breken van oude functionaliteit noemen we ook wel een regressiefout. Er is niks zo vervelend als iets wat werkte en weer kapot is gegaan.

Discussiepunt

Maar hoe weten we nu dat we aan een term als ‘kwalitatief hoogstaand’ voldoen? Er zijn binnen de softwarewereld allerlei methodieken die je kunnen helpen om ‘betere’ code te schrijven. Hier wil ik je op dit moment niet mee lastig vallen. De implementatie van zo’n methodiek blijft namelijk een discussiepunt. Ik kan zelf mijn implementatie namelijk wel mooi genoeg vinden, mijn collega valt er bij wijze van spreken nog net niet van uit zijn stoel.

Meetlint

Gelukkig hebben we een oplossing vanuit tooling die ervoor zorgt dat we kunnen voldoen aan onze hoge kwaliteitsstandaard. Een tool functioneert als meetlint dat controleert of code nog wel voldoet aan onze eisen. Dit gebeurt automatisch op meerdere punten in ons ontwikkelproces. Al tijdens het schrijven van code krijgen we, net als bij spellingscontrole, rode kringels als we verkeerd bezig zijn geweest.

Een voorbeeld van zo’n tool is ‘PHPMD’. PHP is de code die we schrijven en MD staat voor Mess Detector. Een leuk en waardevol onderdeel van deze tool is dat het kan detecteren of iets té moeilijk geschreven is. Oftewel, we hadden onze dag niet en de code is gewoon troep. Troepcode komt er met gebruik van deze tool niet meer doorheen en zullen we moeten opruimen. Zo blijft de code netjes.

Code controleren

Af en toe zeggen we als developer: “Als het werkt dan is het goed genoeg.” En hup, door naar het volgende. Maar hoe weten we dan zeker dat het blijft werken? We zullen continue moeten valideren of het nog steeds werkt zoals verwacht. Maar elke dag handmatig controleren of code nog werkt, daar kun je je dag wel mee vullen. Daarom hebben wij dit proces geautomatiseerd. We laten als het ware een robot door de website klikken en kijken of functionaliteit nog werkt. Dit is natuurlijk geen fysieke robot, maar een losstaand programma dat met behulp van code een bepaald script afloopt waarop geklikt moet worden.

Raceauto of fiets?

Naast het automatisch valideren, controleren we elkaars werk zodat we van elkaar kunnen leren. Hiervoor hebben we goede afspraken gemaakt, zodat voor iedereen duidelijk is waar functionaliteiten minimaal aan moeten voldoen. Niet meer en niet minder, zodat we geen raceauto bouwen waar een fiets ook voldaan had.