Wat te doen als je Laravel developer stopt
Je Laravel developer stopt ermee. Of is al gestopt. De applicatie draait, maar niemand weet meer hoe het werkt. Wat nu? Een praktische gids voor een situatie die vaker voorkomt dan je denkt.
Het telefoontje komt altijd onverwacht. Je vaste developer gaat iets anders doen. Of het bureau waarmee je werkte bestaat niet meer. De Laravel applicatie waar je bedrijf op draait staat er nog, maar niemand weet meer precies hoe het werkt. Wat nu?
Geen paniek, wel actie
Laten ik begin met het goede nieuws: Laravel applicaties zijn over het algemeen goed over te nemen. Het framework volgt conventies die ervaren developers herkennen. De structuur is voorspelbaar. Dat betekent niet dat elke overname eenvoudig is, maar het is zelden hopeloos.
De eerste stap is inventariseren wat je hebt. Klinkt voor de hand liggend, maar in de praktijk weten veel bedrijven niet precies wat er draait en waar.
Checklist: wat heb je nodig?
Voordat je een nieuwe developer of partij benadert, verzamel het volgende:
Toegang tot de code Staat de broncode in een Git repository zoals GitHub, GitLab of Bitbucket? Heb je daar toegang toe? Als de code alleen op de laptop van de vertrokken developer stond, wordt het lastiger maar niet onmogelijk.
Server toegang Waar draait de applicatie? Heb je inloggegevens voor de server? Kun je bij de database? Zonder servertoegang kun je weinig.
Documentatie Is er documentatie? Een README bestand? Technische specificaties? In de praktijk is dit vaak beperkt of verouderd, maar elk beetje helpt.
Wachtwoorden en API keys Denk aan koppelingen met betaalproviders, mailservices, externe systemen. Zijn die credentials ergens vastgelegd?
De code laten beoordelen
Met bovenstaande informatie kun je een ervaren Laravel developer vragen om de code te beoordelen. Zo een code audit geeft antwoord op belangrijke vragen:
Hoe is de algemene kwaliteit van de code? Zijn er security risicos? Hoe moeilijk wordt het om de applicatie te onderhouden en door te ontwikkelen? Welke Laravel versie draait er en is een upgrade nodig?
Een goede audit kost enkele dagen werk, maar voorkomt dat je blind ergens instapt. Je weet vooraf waar je aan toe bent.
Kiezen: repareren of opnieuw bouwen?
Na de audit volgt de belangrijkste beslissing. Soms is de code prima en kun je gewoon verder met een nieuwe developer. Soms is de technische schuld zo hoog dat doormodderen duurder wordt dan opnieuw beginnen.
Er is geen standaard antwoord. Het hangt af van de omvang van de applicatie, de kwaliteit van de code, je budget en je tijdlijn. Een eerlijke partner geeft je de informatie om zelf die afweging te maken.
Hoe vind je de juiste partij?
Zoek iemand met aantoonbare Laravel ervaring. Vraag naar eerdere projecten, specifiek naar overnames van bestaande codebases. Dat is namelijk een vak apart. Nieuwe code schrijven is anders dan andermans code doorgronden en verbeteren.
Let op hoe de gesprekken verlopen. Wordt er geluisterd naar jouw situatie? Worden er realistische verwachtingen geschetst? Een partij die direct belooft dat alles snel en goedkoop kan, zonder de code gezien te hebben, is zelden de beste keuze.
Voorkom dit in de toekomst
Als de acute situatie opgelost is, neem dan maatregelen om herhaling te voorkomen:
Zorg dat de broncode in een repository staat waar jij eigenaar van bent. Niet op het account van de developer, maar op dat van jouw bedrijf.
Laat documentatie bijhouden. Geen romans, maar de basis: hoe zet je een ontwikkelomgeving op, waar staan welke credentials, hoe deploy je nieuwe versies.
Houd credentials centraal bij in een password manager. Niet in de mailbox van iemand die misschien ooit vertrekt.
Overweeg een onderhoudscontract. Regelmatig onderhoud houdt de applicatie gezond en zorgt dat er altijd iemand is die de code kent.
Tot slot
Een developer die stopt voelt als een crisis, maar het is een oplosbaar probleem. Met de juiste informatie en een ervaren partij kun je de draad weer oppakken. De applicatie die je bedrijf draaiende houdt, kan dat blijven doen.