Hoe ga je om met een programmeur die veel bugs oplevert

Als je al enige ervaring hebt met het werken binnen IT projecten dan heb je het vast weleens meegemaakt; Een of meerdere programmeurs leveren code op met bugs, erg frustrerend!

Je steekt veel energie in het schrijven van goede requirements, de programmeur geeft aan dat de implementatie klaar is, vol verwachting sla je aan het testen… en het werkt niet!

“Heeft-ie zijn code überhaupt wel getest!?” “Dat had-ie zelf toch ook wel kunnen zien dat dat niet klopt” “Hoezo…”. Enfin, je kent het gevoel waarschijnlijk wel…

Hoe ga je hier nou mee om, en misschien nog wel belangrijker, hoe voorkóm je zoveel mogelijk dat er bugs in de opgeleverde code zitten?

Code is vrijwel nooit bug-vrij, maar met een goede structuur en setup van je IT project kun je het aantal bugs wel minimaliseren.

Voorkomen is beter dan genezen

Duidelijke vacature-omschrijving

Geef bij het inhuren van een freelance programmeur duidelijk aan wat de skills zijn die je nodig hebt. Vergelijk bijvoorbeeld de volgende twee taakomschrijvingen:

  • PHP Programmeur gezocht met 3+ jaar ervaring voor een webshop.
  • PHP Programmeur gezocht die ervaring heeft met MySQL en Laravel 5 voor een online community platform.

De eerste omschrijving is niet helemaal waardeloos, want er wordt tenminste al iets gevraagd dat je maar op één manier kan interpreteren, maar 3+ jaar ervaring is nog steeds geen garantie dat de programmeur de door jou gewenste frameworks en technieken beheert.

De tweede omschrijving geeft duidelijk aan dat je met o.a. MySQL en Laravel gaat werken, en dat de developer ervaring hiermee moet hebben. Je kan tijdens het interview dan bijvoorbeeld ook nog vragen of hij voorbeelden kan laten zien van waar hij aan gewerkt heeft. Op deze manier heb je een veel grotere kans dat deze kandidaat goed matcht met jouw project!

Duidelijke requirements

Zorg ervoor dat je een goede analyse maakt van de requirements, en dat je bij opstellen van de requirements ook rekening houdt met de testbaarheid en dat de requirement ondubbelzinnig wordt beschreven. Soms komt een bug in de software niet voort uit onkunde van de programmeur, maar uit onduidelijk opgestelde requirements. 

Code Style

Leg alle programmeurs eenzelfde code format op. Hierdoor is de code duidelijk te lezen en moeten er code comments worden opgeleverd in de code. Programmeurs met een rommelige stijl worden gedwongen om nette code op te leveren.

Hiervoor kan je gebruik maken van zogenaamde Lint of Linting software. Zo heb je specifieke lint-software voor verschillende talen (PHPLint, JSLint, et cetera).

Test-driven development

Bij Test-driven development worden eerst de tests geschreven, en dan pas de code. Hierdoor weet je vooraf zeker dat de opgeleverde code voldoet aan een aantal eisen die je zelf (of bijvoorbeeld je lead programmeur) hebt opgesteld.

Als het een programmeur niet lukt om code op te leveren die door de tests heenkomt dan kan je jezelf een hoop installatietijd en testtijd besparen, de code is dan niet goed (genoeg) en kan terug naar de programmeur.

Als het ondanks een goede project setup niet lukt

Lukt het de programmeur niet om binnen afzienbare tijd acceptabele code op te leveren, dan is het wellicht tijd om een andere freelancer te zoeken.

Begin met korte deelopdrachten

Werk je voor het eerst met iemand samen, bedenk dan een korte deelopdracht die binnen relatief korte tijd kan worden opgeleverd. Op deze manier kom je er snel genoeg achter of de programmeur capabel genoeg is.

Doe je dit niet dan kan het maar zo zijn dat je veel geld en kostbare tijd verder tot de conclusie komt dat de samenwerking niet goed loopt. Dit is zonde en onnodig.

Maximaliseer de kans op een goede uitkomst

Gebruik bovenstaande tips en concepten om de kans op slechte code te minimaliseren, en om een slechte programmeur zo snel mogelijk te spotten.

Ook zonder alles te weten van een specifiek framework of van de gebruikte programmeertaal kan met de juiste setup jouw IT project tot een succes worden gebracht!