Co kontroluji při převzetí existující Laravel aplikace

Převzetí existující Laravel aplikace je úplně jiný typ práce než stavba nového projektu od nuly. U nového projektu si člověk nastaví pravidla, strukturu a workflow podle sebe. U existující aplikace nejdřív vstupuje do rozhodnutí, která už někdo udělal před ním. Některá dávají smysl, některá vznikla pod tlakem a některá možná zůstala v kódu jen proto, že na jejich úklid nikdy nebyl čas.

Proto se při převzetí nesnažím hned přepisovat kód. Nejdřív potřebuji pochopit, co aplikace dělá, jak je provozovaná a kde jsou největší rizika. Dobrý audit není hon na chyby. Je to způsob, jak získat mapu projektu a rozhodnout, co je potřeba řešit okamžitě, co může počkat a co je jen odlišný styl, který není nutně problém.

První spuštění a základní orientace

Začínám tím nejjednodušším: dá se aplikace vůbec spustit podle instrukcí v repozitáři? Pokud README neexistuje, je zastaralé nebo chybí lokální setup, je to první signál, že projekt může být obtížně předatelný. Nejde jen o pohodlí vývojáře. Pokud se aplikace nedá rychle spustit lokálně nebo ve stagingu, každá budoucí změna bude pomalejší a rizikovější.

• Kontroluji verzi PHP, Laravelu, Node.js a databáze.

• Dívám se na .env.example, Docker/Sail setup a dokumentaci lokálního spuštění.

• Ověřuji, jestli fungují migrace, seedery a základní testy.

• Zapisuji si kroky, které chybí nebo nejsou jednoznačné.

Stav závislostí a frameworku

Další vrstva je stav závislostí. Zajímá mě, na jaké verzi Laravelu aplikace stojí, jestli používá dlouhodobě podporované balíčky a zda nejsou v projektu opuštěné knihovny. Starší verze frameworku sama o sobě nemusí být problém, ale je důležité vědět, kolik práce bude stát bezpečná aktualizace.

U Composeru a NPM se dívám nejen na počet aktualizací, ale i na typ rizika. Některé balíčky jsou drobné pomocné knihovny, jiné tvoří základ autentizace, administrace, plateb nebo front. Čím blíž je balíček k bezpečnosti a datům, tím větší pozornost si zaslouží.

Architektura a hranice odpovědností

Potom přichází čtení kódu. Nehledám dokonalou architekturu, ale hranice odpovědností. Chci vědět, jestli jsou doménová pravidla rozumně oddělená od kontrolerů, jestli Form Requesty opravdu validují vstupy, jestli modely nejsou přetížené a jestli business logika není rozprostřená na deseti místech bez jasného důvodu.

• Kde vznikají side effecty: e-maily, notifikace, synchronizace, platby?

• Jsou kritické akce pokryté policies nebo jiným autorizačním mechanismem?

• Existují service třídy, akce nebo joby, které dávají systému čitelnou strukturu?

• Je z kódu poznat, co je doménové pravidlo a co jen technická implementace?

Databáze a kvalita dat

Databáze často řekne o projektu víc než samotný kód. Kontroluji migrace, indexy, foreign keys, unikátní omezení i názvy tabulek a sloupců. Zajímá mě také, jestli databáze odpovídá tomu, co si aplikace myslí v modelech. Pokud kód předpokládá vztah, který databáze nijak nechrání, je to potenciální zdroj tichých chyb.

U existující aplikace je důležité dívat se i na reálná data. Prázdná hodnota tam, kde by být neměla, duplicitní záznamy nebo historicky špatně uložené stavy mohou ovlivnit jakýkoliv refaktor. Než se začne měnit kód, potřebuji vědět, jak moc je produkční realita vzdálená od ideálního modelu.

Testy, statická analýza a kvalita změn

Pokud projekt testy má, zjišťuji, co vlastně chrání. Není tak důležité samotné číslo coverage jako to, jestli testy pokrývají kritické business scénáře. Zajímá mě přihlášení, oprávnění, platby, objednávky, důležité formuláře, importy, exporty a integrace. Test, který jen ověřuje triviální detail, nepomůže při převzetí tolik jako test klíčového flow.

• Spouštím test suite a sleduji rychlost, stabilitu a typ selhání.

• Kontroluji Pint, Larastan/PHPStan, případně Rector.

• Dívám se, jestli existuje CI a jestli se používá před mergem změn.

• Rozlišuji mezi chybami, které blokují práci, a chybami, které lze řešit postupně.

Deploy, provoz a rollback

Kód je jen jedna část aplikace. Stejně důležité je pochopit, jak se projekt nasazuje a provozuje. Zajímá mě server, PHP procesy, queue workers, scheduler, storage, cache, logy, zálohy a rollback plán. Aplikace může mít přijatelný kód, ale pokud se nasazuje ručně bez jasného postupu, je každá změna zbytečně stresující.

Na konci převzetí by měl vzniknout jednoduchý seznam priorit. Co je kritické bezpečnostní riziko? Co blokuje běžný vývoj? Co zvyšuje cenu každé budoucí změny? A co je jen technický dluh, který můžeme řešit postupně? Bez takového rozlišení se z auditu snadno stane nekonečný seznam výtek. Smyslem ale není kritizovat minulost. Smyslem je získat kontrolu nad budoucností projektu.