Skoro polovina projektů, které v poslední době přebíráme, přichází po jiném dodavateli. Někdy klient není spokojený se servisem, někdy původní vendor zanikl, někdy projekt jednoduše přerostl. Ať je důvod jakýkoli, naše první fáze je vždy stejná: důkladný audit. Tohle je náš seznam kroků a postup.

První schůzka — diagnostika

Před jakýmkoli kódem potřebujeme rozumět kontextu:

  • Jaký byl původní účel projektu a jak se za roky změnil?
  • Jaké jsou aktuální bolesti — výkon, chyby, chybějící funkce, bezpečnost?
  • Co během refactoru absolutně nesmí přestat fungovat?
  • Existuje dokumentace? Sada testů? Staging prostředí?

Rozhovor trvá typicky 60–90 minut. Po něm už máme první hypotézy o tom, kde leží hlavní problém.

Audit kódu — postup

Po získání přístupu do repozitáře procházíme technickou kontrolou:

  1. PHP verze a kompatibilita — běží projekt na PHP, které je ještě podporované?
  2. Verze frameworku — Nette/Symfony/Laravel/WordPress aktuální, nebo několik hlavních verzí pozadu?
  3. Závislosti v Composeru — kolik balíčků má známé CVE? composer audit dá rychlou odpověď
  4. Statická analýza — PHPStan na úrovni 5+ nebo Psalm odhalí typické chyby
  5. Pokrytí testy — existují vůbec testy? Jaký je poměr pokrytí?
  6. Architektura — oddělení zodpovědností, MVC vs špagety, byznys logika v controllerech?

Infrastruktura — server, databáze, závislosti

Audit kódu nestačí, kontrolujeme i provoz:

  • Konfigurace serveru — Apache/Nginx, PHP-FPM, OPcache, paměťový limit, logování chyb
  • Databáze — verze MySQL/Postgres, strategie záloh, indexy, log pomalých dotazů
  • HTTPS — platný certifikát, HSTS, redirect z HTTP
  • Bezpečnostní hlavičky — CSP, X-Frame-Options, Referrer-Policy
  • E-mail — SPF, DKIM, DMARC pro transakční e-maily

Bezpečnostní slabiny

Tohle je nejčastěji nejtemnější část auditu. Běžně nacházíme:

  • SQL injekce přes přímé skládání SQL řetězců
  • XSS chyby z neošetřeného výstupu ve starých šablonách
  • Přihlašování bez omezení počtu pokusů — otevřené dveře pro brute force útok
  • Rizika krádeže session — session_id v URL, chybějící secure cookies
  • Soubory nahrávané do veřejného adresáře bez kontroly typu
  • Hesla natvrdo ve zdrojovém kódu

U každého nálezu hodnotíme zneužitelnost a dopad. Kritické (RCE, SQL injection na admin endpointu) řešíme okamžitě, ostatní plánujeme do sprintů refactoru.

Refactor plán — co přepsat a co nechat

Nejčastější chyba při přebírání projektu je „přepíšeme to celé od nuly". Žije z toho ego programátora, ne byznys klienta. My přistupujeme jinak:

  1. Stabilizace (1–4 týdny) — opravit kritické bezpečnostní a stabilitní problémy bez změny funkčnosti
  2. Modernizace infrastruktury (2–4 týdny) — aktualizace PHP, menší aktualizace frameworku, aktualizace závislostí
  3. Postupný refactor (průběžně) — při každé nové funkci nebo opravě chyby refactorovat dotčenou část kódu
  4. Strategický refactor (pokud je třeba) — jen specifické moduly, které jsou architektonicky beznadějné

Plné přepsání je poslední možnost — jen když náklady na údržbu starého kódu převyšují náklady na nové řešení.

Komunikace s původním dodavatelem

Tohle je jemné téma. Když je klient nespokojený, neznamená to, že původní dodavatel dělal špatnou práci — někdy jsou mezi nimi nereálná očekávání nebo špatná komunikace. My se nikdy nepouštíme do hodnocení jejich práce veřejně. Při přebírání projektu žádáme:

  • Přístupy do repozitáře a na servery
  • Dokumentaci, pokud existuje
  • Kontakt na konzultaci k nejasným částem (často placenou)
  • Souhlas s ukončením předchozího servisu ke konkrétnímu datu

Profesionální dodavatel předá projekt bez problémů. Pokud narazíme na obstrukce, umíme to řešit právně, ale za 25+ let to nebyl moc častý scénář.

Závěr

Audit zděděného projektu je investice 5–15 hodin seniorního času, ale dává klientovi přesnou odpověď, co má a co s tím dělat. Bez auditu se rozhodnutí dělají v mlze a typicky vedou ke zbytečnému přepsání. Pokud přebíráte projekt po jiném dodavateli, ozvěte se nám — umíme audit udělat za pevnou cenu se závazným reportem.