Vertrouwen in Software

Martijn versluis

Geschreven door Martijn Versluis op 25-1-2018
3 minuten leestijd

Wanneer je in tempo krachtige software wilt ontwikkelen, is het belangrijk om vertrouwen te kunnen hebben in je applicatie. Heb geen zenuwen bij een deployment, maar druk met zelfvertrouwen op de knop!

Waarom vertrouwen belangrijk is

Software ontwikkelen draait om waarde creëren voor gebruikers en/of stakeholders. Maar wat als je niet uitrolt omdat jij of je klant bang is voor software falen? Je levert dan geen waarde. En, nog erger, de wachtrij van uit te rollen features zal alleen maar groeien, en de risico’s van toch uitrollen groeit mee.

Dus moet je alle bestaande features met de hand testen alvorens een nieuwe live te zetten? Dat zal met elke nieuwe feature langer duren, het zal dus de ontwikkeling vertragen en kosten exponentieel verhogen.

Waarom je wellicht geen vertrouwen hebt

Er kunnen verschillende redenen zijn waarom je je software niet vertrouwt. Een veel voorkomende reden is dat sommige teams (of vaak hun stakeholders) nieuwe features opstapelen omdat ze bang zijn het te laten zien aan de wereld. De feature moet compleet gefinetuned en goedgekeurd zijn voordat er genoeg moed is om uit te rollen.

mvp

Een andere oorzaak kan (gebrek aan) kwalitatieve code zijn. Als software rommelig is ingericht, is het lastig om nieuwe functionaliteit toe te voegen. De feature zelf zal waarschijnlijk al breekbaar zijn, daarnaast heb je geen idee of je misschien een ander stuk functionaliteit kapot hebt gemaakt.

Hieraan gerelateerd is gebrek aan (voldoende) kwalitatieve tests. Wanneer je test suite alle mogelijk routes door je applicatie test, zal niemand merken wanneer een van de routes niet meer of anders werkt als gevolg van een verandering in de software.

Hoe je vertrouwen (terug)krijgt

Deploy vaak

Meer vertrouwen ontwikkelen in je software kan op verschillende manieren worden gerealiseerd. Een belangrijke regel is om simpelweg vaak te deployen. Hoe kleiner de verandering die wordt uitgerold, hoe kleiner de impact van een mogelijke bug. Een bijkomend voordeel is dat een kleinere feature ook minder bugs zal bevatten. Bovendien, als de juiste hulpmiddelen voor handen zijn, zal je snel merken als er toch iets mis is en kan je snel een correctie live zetten. Als uiterste maatregel heb je (hopelijk) een rollback functie om de deployment ongedaan te maken.

Schrijf tests

Goede software heeft een verzameling goed doordachte automatische tests. End-to-end tests zijn bedoeld om gedrag van gebruikersna te bootsen en realistische scenarios te testen - bij elke uitrol. Tests op lager niveau, zogenaamde unit tests, zorgen ervoor dat elke mogelijke combinatie van invoer of acties zijn gecontroleerd.

Deze tests kunnen gedraaid worden in enkele minuten, of zelfs enkele seconden, en testen alle features na elke kleine verandering in de code. Geautomatiseerde tests zullen de software structuur verbeteren en bugs grotendeels opsporen, zelfs voordat ze in een release belanden.

Peer reviews en pair programming

Je kunt van een ontwikkelaar niet verwachten om volledig foutloze code te schrijven. Maar wat als een andere ontwikkelaar naar de code zou kijken? Het zogenaamd peer-reviewen van code is heel eenvoudig, bijvoorbeeld met behulp van GitHub’s Pull Request Reviews. Het gaat niet om kritiek leveren, maar feedback geven op code en mogelijke problemen signaleren voordat ze live gaan.

Er is echter nog iets beters dan peer-reviews. Als ontwikkelaars pair-programmeren, werken ze samen aan een feature en reviewen ze meteen elkaars werk.

Test voordat je uitrolt

Uiteraard zullen automatische tests nooit alle mogelijke scenarios afdekken. Zorg er dus voor dat voordat je iets live zet je de feature zelf ook met de hand uitprobeert. Daarnaast kan je collega’s, stakeholders of willekeurig elk persoon vragen om je software te testen.

Deploy continu

Als dit allemaal in order is, is het niet nodig om een handmatige stap te hebben voordat afgeronde functionaliteit live gaat. Richt je infrastructuur dus in om elke feature uit te rollen als deze klaar is. Als elke feature los wordt deployed, weet je waar je moet zoeken als er zich problemen voordoen.

Hoe staat het met jouw zelfvertrouwen?

Hoe verloopt een deployment van jouw volgende feature? Staat het zweet op je voorhoofd of deploy je met een glimlach?

Bij Kabisa kunnen we je helpen zelfvertrouwen te ontwikkelen. We hebben allemaal kennis van kwalitatieve code en van continuous testing en deployment. Laat een bericht achter als je met ons in contact wilt komen.

Martijn versluis

Martijn Versluis

Full-stack webdeveloper met passie voor goede software en tevreden klanten. Bezig met muziek als er niet geprogrammeerd wordt.