Laravel dává velkou svobodu – a to je skvělé. Jenže právě tahle volnost může postupem času vést k neudržitelnosti. Jakmile přibývají nové funkce, třídy, služby a do projektu vstupují další programátoři, začíná být aplikace složitější, křehčí a méně čitelná. Zvlášť ve chvíli, kdy se mění požadavky, projekt roste a na systematický refaktoring „není čas“.

V tomto článku se podíváme na to, jak pomocí nástrojů jako PHPStan (Larastan), Rector, Laravel Pint nebo Duster udržet Laravel projekty přehledné, konzistentní a připravené na další vývoj – ať už na nich pracujete sami, nebo v týmu.

Obsah článku

PHPStan / Larastan – statická analýza, která odhalí chyby dřív než runtime

PHPStan je nástroj pro statickou analýzu kódu v PHP. Ve světě Laravelu se nejčastěji používá v kombinaci s rozšířením Larastan, které přidává podporu pro Eloquent, facády a další Laravel-specific konstrukce.

Proč ho používat?

  • Zachytí typové chyby a potenciální bugy, které by jinak vyšly najevo až za běhu.
  • Pomáhá udržet kód konzistentní a bezpečnější.
  • Snadno se integruje do CI pipeline a běží automaticky při každém commitu

➡️ PHPStan na GitHubu | Larastan na GitHubu

Rector – automatizovaný refaktoring

Jakmile aplikace běží delší dobu, hromadí se v ní zastaralý kód. Nové standardy, novější verze PHP, změny v Laravelu – to všechno přináší příležitosti pro refaktoring. Ale ručně upravovat stovky tříd a konfiguračních souborů? To nechce dělat nikdo. Právě tady nastupuje Rector.

Příklady použití:

  • Přepis array() na []
  • Automatický upgrade na novější verze PHP (např. využití readonly, match, enum…)
  • Odstranění mrtvého kódu nebo zastaralých konstrukcí
  • Laravel upgrady – např. z Laravel 8 na 9 pomocí předdefinovaných setů

🟡 Tip: Rector je výkonný nástroj, ale při prvním spuštění může udělat stovky změn. Doporučuji ho používat ve vedlejší větvi s verzovacím systémem (Git) a nejdřív si otestovat výstupy na menším vzorku.

➡️ Rector na GitHubu

Laravel Pint – čistý a jednotný kód

Laravel Pint je oficiální nástroj pro formátování kódu od Laravel týmu. Vychází z PHP CS Fixeru, ale je jednodušší na konfiguraci a lépe sladěný s Laravel ekosystémem.

Pint podporuje vlastní konfiguraci v souboru pint.json, ale pro většinu projektů vystačí s výchozím nastavením. Mezi výhody patří:

  • Dodržování stylu Laravelu bez nutnosti řešit každý detail ručně
  • Možnost spouštět v CI nebo jako předcommit hook
  • Podpora pro „diff“ mód, kdy Pint pouze zkontroluje odchylky

➡️ Laravel Pint na GitHubu

Duster – all-in-one nástroj

Duster je open-source nástroj od Spatie, který kombinuje více nástrojů (PHPStan, Pint, Rector a další) do jednoho rozhraní. Díky tomu nemusíte psát deset různých příkazů – vše zvládnete jedním:

Výhodou je:

  • Jednoduchost – snadná integrace do CI
  • Konzistence – jeden příkaz spustí vše potřebné
  • Možnost přizpůsobit si, které nástroje chcete zapnout

Duster je ideální pokud se vám nechce psát deset různých příkazů, vendor/bin/duster fix udělá většinu práce za vás.

CI integrace – spouštění automaticky při každém pushi

Nejlepší způsob, jak udržet tyto nástroje živé a funkční v každodenním vývoji, je napojit je na váš CI nástroj – třeba GitHub Actions nebo GitLab CI. Jakmile se kontroly spouští automaticky při každém commitu nebo pull requestu, máte jistotu, že problémy se zachytí včas a neprojdou dál.

Nemusíte hned začít se složitými buildy – stačí jednoduchý krok, který zkontroluje formátování nebo chyby. Hlavní je nastavit „kulturu“, kde se „špinavý commit“ do mainu nedostane. Jakmile se tohle stane standardem, udržíte kvalitu kódu i v týmu s více vývojáři.

Proč to celé řešit?

Používání těchto nástrojů vám nezaručí, že kód bude vždy perfektní. Ale nastaví vám mantinely, které výrazně snižují riziko průšvihů – a to je v týmu k nezaplacení. Díky automatické kontrole, formátování a statické analýze získáváte:

  • méně bugů,
  • čitelnější kód,
  • snadnější onboarding nových vývojářů,
  • větší důvěru v to, že refaktoring nic nerozbije.

Čím dřív je nasadíte, tím větší úsporu vám přinesou – v čase, šálcích kávy i kvalitě výsledku. Já je nasazuju vždy hned při init commitu.

Bojujete s technickým dluhem? Mrkněte na můj další článek, kde se touhle tématikou zabývám: Jak technický dluh zpomaluje vývoj a co s tím dělat.