Udvikling
Laravel udvikler til forretningssystemer
En stor del af de danske forretningssystemer kører på Laravel: kundeportaler, booking, fakturering og interne værktøjer, der er vokset ud af et regneark. Jeg bygger dem, udvider dem og overtager dem, når den, der skrev dem, er videre.
Hvornår giver det mening
- Et Laravel-system driver en del af forretningen, og præcis én person forstår det
- I skal bruge en funktion, der rører database, kø og fakturering på én gang
- Framework-opgraderingen er blevet udskudt så længe, at opgraderingen nu er sit eget projekt
- Et baggrundsjob fejler i stilhed, og I hører det fra en kunde frem for fra en alarm
- I har egne udviklere og mangler seniorkapacitet uden at ansætte fast
Sådan foregår det
- 01
Kortlæg
Jeg læser kodebasen, databasen og jobbene igennem, før jeg rører noget, og fortæller, hvad jeg fandt — også det, I ikke spurgte om.
- 02
Byg
Funktioner eller opgradering, i små stykker der kan gå live hver for sig. I ser det køre på staging frem for i en statusrapport.
- 03
Overdrag
Migrationer, miljøvariabler og udrulning skrevet ned. Alarmerne peger på jer og ikke på mig, så intet afhænger af, at jeg bliver hængende.
Hvad arbejdet dækker
- Nye funktioner, refaktorering og oprydning i det, der gør enhver ændring langsom
- Opgradering af framework og PHP-version, trinvist frem for som ét spring
- Køer, planlagte jobs og det baggrundsarbejde, der fejler i stilhed
- Test omkring de steder, hvor en fejl koster penge
- Integrationer til økonomi-, betalings- og CRM-systemer, med genforsøg og alarmer
- Databasearbejde: indeks, skemaændringer og de forespørgsler, der var fine ved en tiendedel af datamængden
- Udrulning og miljøopsætning skrevet ned, så en ny version ikke afhænger af én bestemt person
- Kodegennemgang og en ekstra seniorvurdering ved siden af jeres egne udviklere
- De offentlige sider server-renderet med opmærkning, så priser og ydelser kan findes i Google og citeres i et AI-svar
Den situation, siden her er skrevet til
En Laravel-applikation, der driver en del af en forretning, lander næsten aldrig hos mig, fordi nogen ønsker sig en ny funktion. Den lander, fordi den, der byggede den, er holdt op eller er blevet selvstændig og ikke svarer så hurtigt længere, og fordi virksomheden har opdaget, at et system, den bruger hver dag, ikke forstås af nogen på lønningslisten. Den konkrete opgave er en funktion eller en rettelse, og det underliggende behov er, at mere end én person forstår systemet.
Det præger de første uger. Før jeg giver pris på funktioner, læser jeg skemaet, migrationerne, de køafviklede jobs og de planlagte kommandoer, og skriver ned, hvordan applikationen faktisk hænger sammen. Kunder bliver af og til overraskede over, at det er fakturerbart, og det er den del med den længste tilbagebetaling: alle estimater derefter hviler på systemet, som det er, frem for som det blev beskrevet.
Opgraderinger, og hvorfor de bliver udskudt
Den tilstand, jeg oftest finder en Laravel-kodebase i, er flere hovedversioner bagud med en composer.lock, ingen har turdet røre. Det er et fornuftigt sted at ende. En opgradering har ingen synlig gevinst for nogen uden for udviklerteamet, den er reelt risikabel, når der ikke er test, og der er altid noget mere presserende. Så kommer der en sikkerhedsmeddelelse på en afhængighed, der ikke kan lappes uden opgraderingen, og så haster det pludselig på en andens præmisser.
Metoden er trinvis: én hovedversion ad gangen, med applikationen udrullet og kørende imellem hver. Findes der ingen testsuite, kommer der først en lille en omkring de dele, der flytter penge eller kan miste data, fordi det er den, der gør resten af opgraderingen mulig at efterprøve. PHP-version og framework-version er hvert sit skridt, taget hver for sig, så en fejl har én åbenlys årsag.
Det er langsommere end at tage det hele i ét spring, og billigere. Det meste af prisen for en opgradering ligger i de fjorten dage bagefter, hvor ingen kan sige, hvilken af fyrre ændringer der ødelagde faktureringen, og kun lidt af den i selve kodeændringen.
Samarbejde med de udviklere, I allerede har
En pæn del af Laravel-arbejdet er slet ikke en overtagelse. Der er et team eller én intern udvikler, og det, der mangler, er kapacitet eller en ekstra seniorvurdering. Den slags passer mig fint: review af pull requests, de stykker ingen har tid til, eller at sidde sammen om den del af systemet, alle har gået udenom.
Det prissættes som alt andet. Enkeltopgaver prissættes for sig uden minimumsaftale, og hvor behovet er fast frem for lejlighedsvist, er udviklingspartnerskabet til en fast månedlig pris den nemmere form. Forskellen er, at tiden er sat af på forhånd, og at den enkelte opgave ikke skal prissættes og indplaneres forfra hver gang. Der er ingen binding, og aftalen kan opsiges med en måneds varsel.
Hvornår Laravel er det rigtige valg
Laravel er et PHP-framework, og det er et godt valg, når det, der skal bygges, er et forretningssystem med brugere, rettigheder, databaser, køer, e-mails og betalinger. Det meste af det følger med i frameworket og er gennemprøvet i tusindvis af systemer, så timerne går til jeres egne forretningsregler. PHP kan hostes næsten alle steder, og der er mange danske udviklere, der kan tage over.
Det er et dårligere valg, når opgaven er en ren indholdsside, hvor WordPress er billigere, eller når brugerfladen er så interaktiv, at den alligevel skal bygges som en React-applikation. Så kan Laravel stadig være backenden bag, og det er en kombination, jeg bruger ofte. Har I allerede et Laravel-system, handler opgaven som regel om at bringe det op på en version, der stadig får sikkerhedsopdateringer.
Ofte stillede spørgsmål
- Hvad koster Laravel-udvikling?
- Det afhænger af omfanget, og hvor meget af det eksisterende system opgaven rører. En afgrænset opgave får en fast pris og en leveringsdato, som vi aftaler skriftligt, før jeg går i gang. Beskriv opgaven, så får du en pris efter en kort snak.
- Kan du opgradere en gammel Laravel-version?
- Ja, og det er værd at gøre, før det haster. Jeg opgraderer én hovedversion ad gangen med testsuiten og staging imellem hvert trin. Findes der ingen testsuite, kommer en lille testsuite omkring de kritiske dele først.
- Kan du arbejde sammen med vores nuværende udvikler?
- Ja. At reviewe pull requests, tage de stykker ingen har tid til, eller være den ekstra seniorvurdering er en helt normal aftale. Jeg forsøger ikke at blive den eneste, der forstår jeres system — det er netop den situation, de fleste kunder ringer om.
- Hvad med databasen?
- Det er som regel dér, det rigtige problem ligger. Manglende indeks, et skema der passede til den oprindelige idé og ikke til den nuværende, og forespørgsler der var fine ved en tiendedel af datamængden. Jeg arbejder i Postgres og MySQL og siger til, når en langsom side i virkeligheden skyldes databasen.
- Kan du arbejde på et Laravel-projekt helt uden test?
- Ja, og det er almindeligt. Det, der ændrer sig, er rækkefølgen frem for om det kan lade sig gøre: en lille testsuite omkring de dele, der flytter penge eller kan miste data, kommer først, for uden den kan hverken du eller jeg vurdere, om en ændring var sikker. Det er typisk nogle dage, ikke et projekt, og det er det, der gør de senere estimater værd at tro på.
- Hvordan håndterer du udrulning og hosting?
- Det, I allerede kører, hvis det virker — en VPS, en hostet platform eller en containeropsætning, nogen satte op én gang. Er der ingenting, sætter jeg en udrulning op, der kører fra et git push med migrationer og en vej tilbage, og skriver ned, hvordan den virker. Jeg bygger og driver også selv en hostingplatform, og jeg siger rent ud, når jeres er fin, og en flytning bare ville være uro.
- Hvad hvis systemet skal skrives om frem for repareres?
- Så siger jeg det, med begrundelsen og prisen, og det er jeres beslutning frem for min. Omskrivninger bliver anbefalet langt oftere, end de er berettigede, som regel fordi det er sværere at læse en andens kode end at skrive sin egen. En teknisk gennemgang afgør det spørgsmål, før nogen af os binder sig til et tal, og svaret er ofte, at en målrettet rettelse køber tre år mere.
- Skriver du under på en NDA, og arbejder du i produktionsdata?
- En NDA er helt fin og almindelig. Produktionsdata håndteres anderledes: jeg arbejder på anonymiserede eller reducerede kopier, hvor opgaven tillader det, fordi den sikreste måde at undgå at behandle personoplysninger forkert er ikke at ligge inde med dem. Hvor der reelt er brug for produktionsadgang, er den tidsbegrænset, logget og navngiven, og GDPR-siden af det bliver skrevet ned frem for forudsat.
- Skal en Laravel-applikation kunne findes i Google og i AI-svar?
- Det, der ligger bag login, skal ingen crawler nogensinde se, og der er ingen grund til at bruge timer på det. Det, der ligger foran — forsiden, ydelserne, priserne, et katalog, en hjælpesektion — er tit det eneste, en fremtidig kunde og en AI-assistent får at se, og det er som regel den del, der er bygget sidst og målt mindst. Blade leverer færdig HTML, så udgangspunktet er godt: det, der mangler, er normalt opmærkning med rigtige tal, titler og canonical per side, en robots.txt, der er skrevet med vilje, og et sitemap, der matcher det, der faktisk findes.
- Laravel eller WordPress til vores projekt?
- Hvis hovedopgaven er at udgive indhold, I selv vil rette, så WordPress. Hvis hovedopgaven er logik — brugere, rettigheder, beregninger, et forløb med tilstande — så Laravel, og så bruger I mindre over tre år end ved at presse den anden på plads.
Andre teknologier jeg arbejder i
Ved du ikke, hvad du skal vælge?
Skriv et par linjer om, hvad du gerne vil opnå. Du får svar inden for 24 timer, og et ærligt ja eller nej.