Dnes jsem na Twitteru napsal následující:
Pokud si pamatujete klávesové zkratky pro Step Into, Step Over a Step Out, děláte to špatně.
— Borek Bernard (@borekb) June 15, 2012
… po čemž se mi ozvalo hned několik lidí, takže si to asi zaslouží kratší vysvětlení.
Osobně si tyto klávesové zkratky nepamatuji z následujících důvodů:
- Debugování nepoužívám příliš často, a pokud ano, většinou mi stačí zastavit se na nějakém breakpointu a podívat se na obsah proměnných. Jen málokdy potřebuji kód krokovat.
- Mám špatnou mechanickou paměť a bez mnemotechnických pomůcek si kl. zkratky dokážu zapamatovat jen velmi těžko. Takže zatímco třeba u
Ctrl+Dještě dokážu udržet, že to znamená “duplicate line(s)” nebo “delete line(s)”, u klávesF1-F12jsem ztracený. - Bohužel nemám to štěstí, abych mohl používat jedno IDE nebo editor, a můj mozek, v kombinaci s předchozím bodem, není schopný si zapamatovat a produktivně používat víc sad desítek klávesových zkratek (jakž takž zvládám víc sad jednotek klávesových zkratek). Zrovna u ladění navíc bohužel moc konzistence napříč různými nástroji neexistuje.
Takže toto byl poměrně důležitý kontext k tvítu. Možná děláte na projektu, kde je ladění časté, nebo používáte jen jeden nástroj, a v tom případě je snadné si zapamatovat všechny klávesové zkratky, apod. Ale tvít jsem přesto poslal do světa v této podobě, jednak jako narážku na mého oblíbeného twitteristu, a potom jako námět k zamyšlení:
Pokud totiž ladíte tak často, že třeba i přes používání různých IDE znáte jejich klávesové zkratky pro ladění, zamyslete se, jestli by to nešlo dělat líp. Třeba automatizovaně testovat. Nebo psát srozumitelnější kód. Prostě a jednoduše, ladění by měl být až nástroj poslední instance.
Mezi laděním a testováním je propastný rozdíl. Jedno nenahrazuje druhé. Jsem přesvědčen, že lidé málo krokují své kódy a měli by to dělat častěji. Pomůže to uvědomit si nedokonalosti kódu a objevit chyby, na které se poté napíše test.
Pokud si člověk nepamatuje klávesové zkratky, je jeho práce méně efektivní, a to jednoznačně dobře není.
DG: Právě že ladění a testování v mnoha případech nahraditelné jsou, jedná se o jednu ze základních premis test-first přístupů. Samozřejmě, občas je debugger k nezaplacení, ale IMO se ladění nadužívá, ne naopak.
Ach jo, to je zase Roubíčkovina. Borku, ty asi nemáš moc integračních a UI testů, že? Tam by sis ladění užil a klávesové zkratky by sis zapamatoval i pro 10 různých IDE (anebo si je přenastavil všude stejně).
Mimochodem přesně na tyto generalizace jsem narážel v jednom z posledních tweetů o univerzálních kladivech na všechno. Někdy se prostě hodí debugování, někdy testování, někdy se dá jedno druhým nahradit a jindy zase ne – záleží na projektu a na situaci.
Debugování se nadužívá jen a pouze proto, že lidi většinou nepíšou testy.
Tomáš: Přesně tak, kratší texty jsou jen námět k zamyšlení.
Při mém vývoji potřebuji krokování jen zcela výjimečně, a když už ho potřebuji, je to téměř vždy známka toho, že je něco hodně špatně – buďto hledám bug v 3rd party knihovnách nebo je aplikační kód napsaný tak špatně, že mu nejsem schopen porozumět.
A jsem rád, že to vyznělo jako roubíčkovina, přesně to byl můj záměr. Generalizace nesnáším :)
Chjo, další co si neumí nastavit IDE tak aby to měl všude stejně. A pak ještě sype moudra o ladění. Borku, Borku, chtělo by to víc projektů kde musíte honit čas (manažer zas něco slíbil), čelit nervozitě zákazníka (proč to tolik trvá když za to tolik platím?) a nepředvídatelným chybám (proč se to zhroutí na produkci když to prošlo testami?)
tom: Z článku je důležitý především poslední odstavec, ostatní je omáčka a subjektivní vysvětlení toho, proč já osobně si kl. zkratky pro krokování nepamatuju.
Možná to souvisí s technologií, ve které dělám, ale znovu zopakuji: já osobně i u kódu, který není pokrytý testy, potřebuji krokování jen zcela výjimečně (řekněme jednou, dvakrát do měsíce). A potřebuji to v situacích, které by ideálně neměly nastávat, tj. např. když je kód tak zprasený, že nejsem schopen se v něm vyznat, nebo když se, jak píšeš, dějí podivné věci a nevysvětlitelné chyby. Pak je debugger záchrana a super užitečná věc, jen, jak píšu, by to měl být až nástroj poslední instance.
Nevidím na tom celkem nic kontroverzního.
Pokud píšete nejdřív testy a pak kód, pak je debugger potřeba jen na integrační záležitosti (např zjistit jak a s jakými parametry vás volá aplikační server), kterých není tolik. Ale to neznamená že si nemusim pamatovat ty tři zkratky:)
Já bych ten tweet přeformuloval jako “Pokud si nepamatujete klávesové zkratky pro Step Into, Step Over a Step Out, nepíšete asi moc složité aplikace.” :-)
Teze o nahrazení ladění testy platí jen u jednoduchých aplikací. Třeba PEG.js mám kompletně pokryté testy, ale často když udělám nějakou změnu, začnou failovat a netuším proč. Chyba je někde ve 20 kB kódu vygenerovaného parseru. Nejrychlejší cesta, jak ji odhalit, je začít ten parser debugovat.
Debugování taky potřebuju každou chvíli, když je nějaký problém v kódu který neznám (typicky nějaká knihovna nebo framework, na kterém je aplikace vystavěná). Byť v komentáři píšeš, že to už je “hodně špatně”, má zkušenost je, že to dělám každou chvíli.
Jinak se ale musím přiznat, že obecně častěji než debugování prostě přidám do kódu logování na pár důležitých míst — je to často pohodlnější a k vyřešení problému to stačí. Debugger mnohdy zapínám až když tahle primitivnější metoda selže.
Pingback: Gmail i jeho rozhraní je jeden velký fail | JiKra.Name
Osobne si myslim, ze pokud je neco moc slozite, neni to nikdy dobre. Uvnitr sloziteho programu se vzdy najde jednoduchy, ktery dela tu samou vec. Navic, me se teda urcite lepe spravuje aplikace slozena z nekolika jednoduchych modulu, ktere mezi sebou komunikuji, nez jeden velky moloch.
Pokud je program potreba krokovat, je to podle me znamka toho, ze je kod moc slozity, nebo ze si nejsem dostatecne jisty co jsem presne vytvoril, a nebo jsem hodne liny a nechce se mi premyslet.
Pokud je tomu tak, je to spatne a mel bych s kodem/ze sebou neco delat.
Takze tady plne souhlasim s autorem.
Asi typický názorový střet aplikačního vývojáře s někým, kdo jako příklad uvádí parser generator :) Já jsem taky aplikační vývojář.