Slovník pojmů

Debugování

Cílem není potlačit chybovou hlášku, ale najít příčinu a ověřit, že se stejná chyba nevrátí.

Stručná definice

Od pozorovaného problému k ověřené příčině.

Debugování začíná konkrétním příznakem: chybovou stránkou, špatným výsledkem, pomalou odpovědí nebo neočekávaným stavem dat. Vývojář si vytvoří opakovatelný scénář, sesbírá důkazy a postupně vylučuje hypotézy, dokud nenajde místo, kde se očekávané chování rozchází se skutečným.

Není to totéž co logování ani testování. Logování zachycuje vybrané informace z běhu a může dát stopu. Test dopředu ověřuje očekávané chování. Debugování zkoumá už pozorovaný problém; po opravě ho má uzavřít test, který chybu nenechá potichu vrátit.

Kdy pomáhá

Když příznak nestačí k vysvětlení příčiny

Nejrychlejší je začít malým, přesně popsaným případem místo procházení celého projektu.

chyba při konkrétním formuláři nebo HTTP požadavku, která se objevuje jen u části vstupů
neočekávaná výjimka nebo prázdná odpověď aplikace
nesprávný výsledek výpočtu, importu či změny objednávky
problém, který se projevil až po nasazení nebo při určité kombinaci dat
regrese po změně kódu, konfigurace nebo závislosti

Praktický příklad

Sleva v objednávce občas skončí chybou

Podpora nahlásí, že objednávka s dárkovým poukazem skončila chybovou stránkou. Nejdřív je potřeba získat stejné vstupy: typ poukazu, položky košíku, jazyk a čas chyby. Bez reprodukce by se vývojář mohl dívat na zcela jinou cestu aplikace.

Stack trace ukáže, že problém vznikl při výpočtu slevy. Breakpoint nebo bezpečný lokální výpis hodnot odhalí, že jedna větev předala prázdnou hodnotu tam, kde kalkulátor očekává číslo. Oprava doplní jasné pravidlo pro chybějící hodnotu a PHPUnit test se stejnými vstupy se stane regresním testem.

Postup

Pět kroků od chyby k opravě

Každý krok má zmenšit počet možných příčin. Přeskakování kroků často vede jen k dočasné záplatě.

Popsat příznak Zapiš, co se stalo, komu, kdy a jaký výsledek byl očekávaný. Připoj bezpečný identifikátor požadavku nebo chyby, ne heslo ani celý citlivý payload.
Reprodukovat problém Najdi nejmenší opakovatelný postup a stejné podmínky. Pokud se chyba nedá zopakovat, rozšiřuj pozorování místo hádání opravy.
Vytvořit hypotézu Například: „Chyba nastane jen při chybějící slevě.“ Hypotéza musí jít vyvrátit jedním cíleným pozorováním.
Získat důkaz Čti stack trace, porovnej vstupy a stav, případně použij breakpoint v lokálním nebo bezpečném vývojovém prostředí. Sleduj cestu k příčině, ne jen poslední řádek hlášky.
Opravit a ohlídat návrat Oprav příčinu, zopakuj scénář a přidej regresní test. Nakonec ověř i blízké hraniční případy, které používají stejnou část pravidla.

Nástroje a hranice

Co jednotlivé techniky umí a neumí

Dobrá diagnostika kombinuje malé množství relevantních důkazů. Více výpisů automaticky neznamená více porozumění.

Logování

Log uchová vybrané informace z běhu, například čas, identifikátor požadavku nebo typ chyby. Je užitečnou stopou, ale sám neukáže všechny hodnoty ani důvod rozhodnutí. Citlivé údaje, tokeny a celé osobní payloady do logu nepatří.

Stack trace a breakpoint

Stack trace ukazuje cestu volání k místu chyby. Breakpoint běh zastaví a dovolí prohlédnout hodnoty a větve. Breakpoint je vhodný hlavně lokálně; produkční požadavek nesmí zdržet ani vystavit data.

Testování

Automatický test ověřuje předem popsaný scénář. Debugování hledá příčinu scénáře, který už selhal. Po opravě je vhodné přidat regresní test v PHPUnitu, aby se chyba při další změně objevila dřív.

Statická analýza

Statická analýza kódu prochází možné typy a rozpory bez spuštění konkrétního scénáře. Může odhalit podobnou chybu dřív, ale nenahradí reprodukci ani zkoumání skutečných provozních dat.

Výhody a rizika

Rychlejší hledání bez nebezpečných zkratek

Co funguje

jeden konkrétní scénář a jasně popsaný očekávaný výsledek
malé hypotézy, které lze rychle potvrdit nebo vyvrátit
stack trace, kontext chyby a bezpečně zvolená pozorování
regresní test přidaný spolu s opravou

Na co pozor

náhodné úpravy kódu bez důkazu o příčině
vypnutí výjimky nebo ztlumení logu místo opravy pravidla
debug výpisy a veřejné stack trace v produkci
zachycení jen příznaku, zatímco chybný stav vzniká dříve

Praktické použití

Nejdřív zmenšit problém, potom zmenšit změnu.

U běžné chyby stačí reprodukce, stack trace a jeden cílený test. U problému mezi více službami je potřeba sledovat bezpečné korelační identifikátory, časovou osu a hranice mezi systémy. I tehdy je lepší ověřit několik malých hypotéz než číst všechen dostupný log.

Pokud problém souvisí s výkonem, postup se mění: místo breakpointu je potřeba měřit čas a počet volání. V Symfony aplikaci může v lokálním vývoji pomoci profiler, v produkci však patří diagnostika do bezpečného monitorování, ne do veřejného debug panelu.

Kontrolní seznam

Co má zůstat po vyřešení chyby

Cílem není jen zelená obrazovka, ale dohledatelná příčina a důvěra, že oprava pokrývá dané pravidlo.

stručný popis příznaku, očekávání a kroků reprodukce
bezpečný záznam kontextu bez tajných údajů a osobních dat navíc
pojmenovaná příčina, ne jen seznam změněných souborů
regresní test a případně statická kontrola pro blízké typové riziko
malá dohledatelná změna ve verzovací historii s vysvětlením dopadu

Časté otázky

Co debugování znamená v praxi

Je debugování totéž co přidání logu?

Ne. Log je jeden zdroj důkazů. Debugování zahrnuje reprodukci, hypotézy, porovnání očekávání se skutečností a ověření opravy.

Proč po opravě přidávat regresní test?

Test zachytí stejný scénář při příští změně dříve než uživatel. Má ověřovat pozorovatelné pravidlo, které bylo porušené, ne jen řádek implementace.

Mohu použít breakpoint v produkci?

Běžně ne. Zastavení procesu může zdržet uživatele, odhalit citlivá data a zhoršit výpadek. V produkci používej bezpečné logy, metriky a trasování s omezeným přístupem.

Ukazuje stack trace vždy skutečnou příčinu?

Ukazuje, kde se chyba projevila a jak se tam program dostal. Příčina může ležet dříve: ve špatném vstupu, konfiguraci, stavu dat nebo chybném předpokladu.

Jak pracuji s kvalitou v praxi

Chybu řeším od příčiny až po ověřenou ochranu proti návratu.

Při vývoji kombinuji reprodukovatelné scénáře, testy a statickou kontrolu tak, aby změny zůstaly srozumitelné i bezpečné pro další úpravy.

Zobrazit zkušenosti s testováním a kvalitou Nezávazně probrat projekt