Čtyři chyby, které mě stály po dni — a ve všech mi lhaly moje nástroje
Crawler, který si vymýšlel chyby, černé screenshoty, middleware zastíněný prázdnou složkou a render pipeline bez rendereru. Čtyři ztracené dny a jeden návyk, který by je zachránil.
Chyby, které mě stály nejvíc času, nikdy nebyly těžké chyby. Těžké chyby jsou poctivé — hlásí se, vyhodí stack trace a vy je opravíte. Drahé jsou ty, kde vám nástroj sebejistě lže a vy strávíte den laděním něčeho úplně jiného.
Tady jsou čtyři z posledních měsíců. Každá spolkla zhruba den. Tématem spolu nesouvisejí a tvarem jsou totožné.
1. Crawler, který si vymýšlel chyby
Na kontrolu vlastních projektů pouštím crawler webu: rozbité odkazy, řetězce přesměrování, chybějící hlavičky, takové věci. U jednoho webu se vrátil se zdí červené — chybějící bezpečnostní hlavičky, strukturální problémy, skóre stažené dolů napříč vším.
Strávil jsem hodiny kontrolou hlaviček, které se prokazatelně odesílaly. curl je ukazoval. Prohlížeč je ukazoval. Crawler trval na tom, že tam nejsou.
Skutečná příčina: crawler si stránky vyžádal s přijetím komprese Brotli a odpovědi v Brotli neuměl správně dekódovat. Všechno, co z těch stránek „přečetl“, byl blábol, takže selhalo všechno, co kontroloval. Skóre bylo podhodnocené na každé jednotlivé stránce.
Vynucení gzipu to spravilo okamžitě.
Co jsem si z toho odnesl: když nástroj hlásí problém, ověřte jiným nástrojem, že problém existuje, dřív než začnete opravovat. Jedno curl -I hned na začátku by ušetřilo celý den, protože by rozpor ukázalo okamžitě.
2. Screenshoty, které byly černé
Dělal jsem hru v Unity a chtěl, aby se build v rámci automatické kontroly sám vyfotil — udělat screenshot, podívat se na něj, potvrdit, že se scéna skutečně vykresluje.
Naskládaly se dvě pasti na sebe. Zaprvé, vykreslení kamery do textury zachytilo 3D scénu, ale potichu vynechalo ladicí UI kreslené v immediate mode — takže přesně ta informace, kterou jsem chtěl ověřit, v obrázku nikdy nebyla. Když jsem pak přešel na snímání obrazovky na úrovni systému, macOS vrátil naprosto platný, naprosto černý PNG. Žádná chyba. Žádný dotaz na oprávnění. Jen čerň.
Zelená fajfka nad pipeline, která fotila nic.
Co jsem si z toho odnesl: ať testovaná věc vyrábí důkaz sama, zevnitř vlastní vykreslovací smyčky, a ať hlasitě selže, když to nejde. Automatická kontrola, která neumí rozlišit „všechno je v pořádku“ od „nic jsem neviděl“, je horší než žádná kontrola, protože vyrábí falešnou jistotu.
3. Middleware, který fungoval v produkci a lokálně ne
Web v Next.js měl middleware, který řešil přesměrování. V produkci fungoval. Lokálně nedělal vůbec nic — žádné logy, žádný efekt, jako by ten soubor neexistoval.
Zkontroloval jsem matcher, umístění souboru, runtime, verzi Nextu. Všechno v pořádku.
Příčinou byl prázdný adresář src/pages, který zbyl po staré migraci. Už jeho pouhá existence změnila, jak se vyhodnocuje struktura projektu, a middleware v kořeni se do buildu vůbec nedostal. Smazání prázdné složky to spravilo.
Stopa byla v build manifestu — middleware tam prostě nebyl uvedený. Našel jsem to po hodinách přemýšlení nad vlastním kódem, přitom jsem to mohl najít za minutu tím, že bych se zeptal, co si framework myslí, že postavil.
Co jsem si z toho odnesl: když se chování liší mezi dvěma prostředími se stejným kódem, přestaňte číst kód. Porovnejte oba výstupy buildu. Rozdíl je v tom, co se postavilo, ne v tom, co jste napsali.
4. Renderer, který žádný renderer neměl
Při automatizaci Blenderu bez GUI kvůli výrobě videa jsem měl pipeline, která proběhla celá bez chyb a nevyprodukovala žádný videosoubor. Dvě samostatné příčiny, objevené postupně: build, který jsem řídil, neměl vůbec k dispozici FFmpeg zapisovač, a API, na které jsem se u animačních křivek spoléhal, bylo ve verzi, na kterou jsem přešel, odstraněné. A když už snímky ven začaly chodit, výchozí správa barev udělala z plochých kreslených barev vymydlenou šeď — což není chyba, jen výchozí nastavení dělá přesně to, k čemu bylo navrženo, v kontextu, kde to je špatně.
Co jsem si z toho odnesl: u jakéhokoli nástroje bez GUI si ověřte, že schopnost vůbec existuje, dřív než postavíte workflow, který na ní stojí. Jeden řádek, který se předem zeptá „umíš zapsat tenhle formát?“, místo aby se to dovozovalo z toho, že na konci chybí soubor.
Společný tvar
Všechny čtyři mají stejnou strukturu:
- Nástroj něco nahlásil — selhání, úspěch, prázdný výsledek.
- Já tomu hlášení uvěřil.
- To hlášení byl artefakt nástroje, ne fakt o mém systému.
Řešení není nedůvěřovat ničemu. Je levnější: než začnete podle hlášení jednat, ověřte tentýž fakt z jednoho nezávislého směru. Druhý nástroj, syrový požadavek, výstup buildu, přímý dotaz na schopnost. Stojí to minutu a buď to vaši realitu potvrdí, nebo tu lež okamžitě odhalí.
Druhý návyk je přísnější: tichý úspěch považujte za selhání, dokud se neprokáže opak. Černý screenshot prošel. Prázdná video pipeline skončila čistě. Middleware selhal tím, že nedělal nic. V každém z těch případů byl systémový způsob, jak mi říct, že je něco špatně, mlčení — a den jsem ztratil jen proto, že jsem mlčení četl jako souhlas.
Nic z toho není důmyslné. Je to jen rozdíl mezi laděním vlastního kódu a laděním vlastních přístrojů — a vědomím, které z toho zrovna děláte.