Console.log() je underrated: Proč "hloupé" logování často strčí debugger do kapsy

Znáš ten meme s křivkou IQ, ne? Úplně vlevo je junior, co píše console.log('tady'). Uprostřed je ten "mid-level" vývojář, co pohrdavě kroutí hlavou, tráví hodiny nastavováním debuggeru v IDE a analyzuje Call Stack. A úplně vpravo? Tam je seniorní architekt, který se vrací ke console.log, protože prostě potřebuje rychle vědět, co se děje, a nemá čas na blbosti.

Ve světě vývoje panuje takové divné stigma. Kdo nepoužívá debugger a breakpointy, jako by ani neprogramoval. Že prý console.log (nebo print či fmt.Println, dosaď si podle svého stacku) je pro amatéry.

Hele, ruku na srdce - to je nesmysl. Console.log() je jeden z nejvíc podceňovaných nástrojů, co máme. A často je efektivnější než ten nejvymakanější debugger ve VS Code. Pojďme se podívat proč.

1. Debugger je fotka, logy jsou film

Hlavní rozdíl je v čase. Když flákneš do kódu breakpoint, koukáš se na snapshot. Zastavil jsi čas. Vidíš přesný stav paměti v tu jednu konkrétní milisekundu. To je super, když potřebuješ zjistit, proč je sakra to user.id undefined.

Ale co když řešíš logiku, která běží v čase?

Představ si for cyklus, co jede padesátkrát, nebo nějaký stream dat. S debuggerem bys musel 50x kliknout na "Continue" a pamatovat si, jak se ty hodnoty měnily. To je o nervy.

Console.log ti vypíše historii. Vidíš ten příběh:

1. Iterace 1: Hodnota 0
2. Iterace 2: Hodnota 5
3. Iterace 3: Hodnota NaN (Bingo! Tady se to rozbilo)

Díky logům vidíš dynamiku a trend, ne jen zmrazený řez.

2. Heisenbergův princip v kódu (a.k.a. když debugger lže)

Tohle určitě znáš - chyba se děje, jen když se nikdo nedívá. Debuggery jsou totiž "invazivní". Tím, že zastavíš vykonávání kódu, změníš chování celé aplikace.

Kde tě to vytrestá nejvíc?

1. Časovače a asynchronní věci: Když zastavíš kód na breakpointu, setTimeout na pozadí tiká dál (reálný čas nezastavíš), ale tvůj kód stojí. Jakmile to pustíš dál, stane se úplně něco jiného, než co se děje za běžného provozu.
2. Síťové requesty: Zastavíš server na 30 vteřin, aby ses pokochal objektem? Klientovi mezitím vyprší timeout a spojení spadne. Gratuluju, právě sis vyrobil novou chybu.
3. Race conditions: Tím, že jedno vlákno nebo proces pauzneš, dáš ostatním čas "doběhnout". Chyba zmizí, ty jsi zmatený a v produkci to pak zase spadne.

Console.log do toho procesu sice taky trochu zasáhne (I/O něco stojí), ale tok programu nezastaví. Na ladění real-time věcí je to často jediná cesta.

3. Není to jen o .log(): Konzole umí psí kusy

Dost lidí na konzoli kašle, protože znají jen ten základní příkaz. Ale moderní prohlížeče (a Node.js taky) umí věci, ze kterých ti spadne brada:

1. console.table(): Máš pole objektů a loguješ to jako JSON? Nedělej to. Dej to do .table() a dostaneš krásnou tabulku, kde můžeš řadit sloupce. Okamžitě vidíš strukturu.
2. console.group() a console.groupEnd(): Super věc na zanořování. Pokud ladíš rekurzi nebo složitý strom komponent, tohle ti zachrání duševní zdraví.
3. console.time() a console.timeEnd(): Potřebuješ rychlý benchmark? Nemusíš tahat externí knihovny, tohle stačí.
4. console.dir(): Někdy ti .log vypíše HTML element jako string, ale ty chceš vidět jeho properties. .dir to zařídí.
5. CSS v konzoli: Jo, fakt. V Chrome můžeš logy stylovat.

Díky tomu si v té záplavě textu všimneš toho podstatného.

4. Rychlost a Flow (nechceš vypadnout z tempa)

Nastavení debuggeru vyžaduje "přepnutí kontextu". Musíš najít řádek, kliknout do lišty, ujistit se, že máš build se source mapami, spustit to v debug módu...

Napsat log(x) ti zabere dvě vteřiny.

Když jsi v "zóně" a píšeš kód, nechceš klikat v UI editoru. Chceš se jen rychle zeptat kódu: "Dostal ses až sem?" nebo "Co je teď v téhle proměnné?". Logování je nejrychlejší zpětná vazba. Je to "špinavé", ale zatraceně rychlé.

5. Místa, kam debugger nedosáhne

Debugger je fajn na localhostu. Ale co když se chyba děje jen na produkci? Nebo na mobilu uživatele, co sedí na druhé straně světa? Tam si breakpoint nenastavíš.

Zvyk používat logování tě učí psát appky tak, aby byly čitelné (tzv. observability). Když se naučíš logovat smysluplná data, přechod na profi nástroje jako Sentry, Kibana nebo Datadog je hračka. Debugger tě učí chytit zloděje při činu. Logování tě učí detektivní práci - najít pachatele podle stop. A věř mi, v DevOps světě je ta druhá schopnost k nezaplacení.

Kdy dát debuggeru šanci? (Abychom byli fér)

Nechci debugger úplně zatratit. Má svoje místo. Sáhni po něm, když:

1. Se hrabeš v cizím kódu ("spaghetti code") a vůbec netušíš, kudy to teče.
2. Potřebuješ detailně projít Call Stack a zjistit, kdo tuhle funkci sakra zavolal.
3. Máš podezření na memory leak a potřebuješ Memory Snapshot.
4. Loguješ toho tolik, že ti zamrzá prohlížeč.

V těchhle případech je debugger král.

Sečteno a podtrženo

Nestyď se za to. Přestaňme se tvářit, že console.log je pro lamy. Je to univerzální švýcarský nůž. Není tak chirurgicky přesný jako skalpel (debugger), ale v 90 % případů s ním problém vyřešíš rychleji.

Klíčem k senioritě není používání těch nejsložitějších nástrojů, ale schopnost vybrat si ten správný pro danou situaci. Někdy je to breakpoint. A někdy je to staré dobré:

console.log('WTF?', obj);

Pár "Pro Tips" na závěr:

1. Vždycky to popiš: Nepiš jen console.log(variable). Piš console.log('User data:', variable). Ušetříš si hromadu času, až budeš v konzoli hledat ten správný řádek.
2. Object shorthand je tvůj kámoš: V moderním JS piš console.log({ variable }). Ono to samo vypíše název proměnné i hodnotu: { variable: "hodnota" }. Geniální drobnost.
3. Ukliď si po sobě: Nechávat console.log v produkčním kódu je jako nechat lešení kolem hotového baráku. Nastav si linter (no-console), ať ti dá přes prsty, než to commitneš.