Laravel-udvikling til forretningssystemer

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. Det akutte behov er en funktion eller en rettelse; det egentlige behov er, at endnu en person kan læse tingen.

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.

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 udviklingssamtalen, 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 efter en andens kalender.

Vejen igennem er kedelig, og den virker: én hovedversion ad gangen, med applikationen udrullet og kørende imellem hver. Findes der ingen testsuite, kommer en tynd én omkring de veje, der flytter penge eller mister data, først, fordi det er den, der gør resten af opgraderingen mulig at efterprøve frem for at håbe på. 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 springe det hele på én gang, og det er billigere, fordi den dyre del af en opgradering aldrig er kodeændringen. Det er de fjorten dage bagefter, hvor ingen kan sige, hvilken af fyrre ændringer der ødelagde faktureringen.

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. Timearbejde er 600 kr i timen ex. moms uden minimumsaftale, og hvor behovet er fast frem for lejlighedsvist, er udviklingspartnerskabet til 12.000 kr om måneden for 20 timer den nemmere form. Timeprisen er den samme — forskellen er, at timerne er sat af på forhånd, og at den enkelte opgave ikke skal prissættes og indplaneres forfra hver gang. Der er ingen binding på det, for en aftale, der skal håndhæves med en kontrakt, er en aftale, ingen har lyst til at være i.