Sådan overtager du et Laravel-projekt fra et bureau

Af Nicklas K. Frank · Opdateret

Når en ny udvikler overtager en Laravel-applikation, skal kode, drift og adgange gennemgås, før de næste ændringer planlægges. Et code review viser, hvad der virker, hvad der haster, og hvad der kræver mere undersøgelse.

Jeg begynder med en afgrænset gennemgang. I får en risikoliste og et forslag til arbejdet og kan derefter beslutte, hvem der skal udføre det. Det er kernen i min ydelse til videreudvikling og overtagelse af Laravel-projekter.

De fire typiske situationer

Leverandøren forsvinder: bureauet lukker, skifter fokus eller nedprioriterer jer. Systemet kører, men ingen vedligeholder det.
Regningen vokser: udgifterne til vedligehold stiger, uden at I kan se, hvilke opgaver tiden går til.
Kvaliteten skrider: rettelser giver fejl andre steder i systemet. Reviewet undersøger blandt andet testdækning og afhængigheder mellem funktionerne.
Nøglepersonen siger op: den udvikler, der kendte systemet, er væk. Dokumentation og overdragelse dækker ikke det daglige arbejde.

Overtagelsen: tre trin med et beslutningspunkt

1

Code review af kodebase, infrastruktur og dokumentation

En afgrænset, fast prissat gennemgang. Jeg læser koden, kortlægger infrastrukturen og tester, om projektet overhovedet kan installeres og køres fra dokumentationen alene. Gennemgangen kan begynde med kode og dokumentation. Eventuel læseadgang til driftsmålinger aftales særskilt.
2

Prioriteret risikoliste

Hver risiko beskrives med konsekvens, anbefaling og prioritet. Listen skelner mellem det, der bør håndteres nu, det der kan vente, og det der fungerer fint som det er.
3

Plan og beslutningspunkt

Planen angiver rækkefølge, estimat og prismodel. I ejer både planen og risikolisten og kan vælge, om jeg eller en anden udvikler skal udføre arbejdet.

Hvad jeg kigger efter i et code review

Versioner: Laravel- og PHP-version og afstanden til supporterede versioner: supportfristerne indgår i vurderingen sammen med kendte sårbarheder og den måde, systemet er eksponeret på.
Tests og deployment: findes der automatiske tests, og kan der deployes uden håndkraft? Det afgør, hvor hurtigt der kan arbejdes sikkert i koden.
Sikkerhed og data: adgangsstyring, håndtering af persondata, hemmeligheder i koden og opdaterede afhængigheder.
Ejerskab og adgange: ejer I selv Git-repository, domæne, hosting og tredjepartskonti, eller ligger det hos den gamle leverandør? Manglende adgang kan blokere både udvikling og overdragelse.
Dokumentation og personafhængighed: kan en ny udvikler komme i gang fra det, der findes på skrift, eller kun fra det, der sidder i hovedet på folk, der er væk?

Skal man nogensinde bare bygge forfra?

Ja, hvis kodebasen er lille, den centrale arkitektur står i vejen, og kravene samtidig har ændret sig markant. Beslutningen skal tage højde for, at en kørende applikation ofte indeholder forretningsregler og kanttilfælde, som også skal findes, beskrives og bygges i en ny løsning.

Det mest forsvarlige udgangspunkt er ofte at stabilisere først og modernisere i dele, mens systemet er i drift. Aller-casen om performance på en ældre platform med høj trafik viser et markant resultat i et eksisterende system. Reviewet afgør, om samme tilgang giver mening i jeres kodebase.

Det praktiske: hav dette klar

Start med læseadgang til Git-repositoriet, en oversigt over hosting og databaser samt en liste over betaling, mail og andre integrationer. Beskriv også, hvilke opgaver den tidligere leverandør håndterer. Vi aftaler adgang til de nødvendige systemer under gennemgangen; den første mail behøver kun at indeholde et overblik.

Sidder I fast med et Laravel-projekt, andre har bygget?

Fortæl kort om systemet, situationen og hvilke adgange I har. Jeg svarer med, hvad et indledende code review bør dække, før jeg prissætter det.

Beskriv overtagelsen

Læs også