Když přestanete psát kód pro stroj, začne ho číst i člověk > 자유게시판

Dokumentaci udržujte na jednom místě a považujte ji za součást kódu. Když se změní chování endpointu, změňte dokumentaci ve stejném commitu jako kód. Ideálně tak, aby se dokumentace generovala nebo alespoň kontrolovala automaticky. Ruční kopírování do externího nástroje dříve nebo později zastará. Pokud to jde, přidejte do repozitáře i ukázkové požadavky a odpovědi, které lze spustit proti testovacímu prostředí. Frontend si tak ověří integraci dřív, než narazí na produkci.

Délka funkcí je druhý nejčastější problém. Funkce, která má přes padesát řádků, obvykle dělá tři věci najednou. Rozdělte ji tak, aby každá část měla jednu odpovědnost a šla popsat jednou větou. Když se v těle funkce objeví vnořené if uvnitř for uvnitř if, je to signál k extrakci. Čitelnost nezískáte zkrácením zápisu, ale zmenšením toho, co musí čtenář udržet v hlavě najednou.

Fixtury místo kopírován

Každý projekt dřív nebo později narazí na moment, kdy ruční nasazení přestane stačit. Někdo zapomene zkopírovat soubory, někdo spustí testy na špatné verzi, někdo jiný nasadí osvětlení v obýváku pátek odpoledne a v pondělí řeší, co se pokazilo. GitHub Actions nabízí cestu, jak tyto opakované kroky svěřit stroji. Nejde o nic magického – jde o soubor s definicí úloh, který se spouští při událostech v repozitáři.

Začněte tím, že si vytáhnete přesnou verzi nástroje i všech závislostí. Většina selhání vzniká v momentě, kdy se na jednom stroji použije novější vydání než v CI. Zapište verze do souboru, který je součástí repozitáře, a v pipeline je vynuťte. Pokud se spoléháte na to, co je zrovna nainstalované na serveru, dřív nebo později narazíte na nekonzistentní výsledky, které se budou obtížně reprodukovat.

Typická chyba je tiché ignorování chyb. Příkaz, který skončí nenulovým návratovým kódem, ale skript pokračuje dál, vytvoří artefakt, jenž vypadá v pořádku, dokud se nepokusíte o nasazení. Nastavte přísné chování při chybě a logujte výstup včetně návratových kódů. Zároveň se vyhněte příliš agresivnímu mazání mezipaměti při každém běhu — zbytečně prodlužuje build a maskuje skutečnou příčinu.

Na závěr: nespouštějte pytest jen ručně před commitem. Nastavte si, aby se testy pouštěly automaticky při každé změně, ať už přes editor, nebo přes jednoduchý skript. Výsledek je stejný jako u ručního testování, jen vás přestane bolet hlava z toho, co jste zapomněli zkontrolovat.

Ověřování před spuštěním, ne až po něm Kontrolní krok zařaďte před samotný build. Ověřte přístupová práva, existenci konfiguračních souborů a dostupnost cache. Chybějící proměnná prostředí se projeví jako nesouvisející chyba až uprostřed kompilace a člověk pak hledá problém na špatném místě. Krátký skript, který tyto podmínky zkontroluje a vypíše srozumitelnou zprávu, ušetří hodiny dohadování.

Na závěr si nastavte měřitelný signál. Sledujte dobu běhu, počet opakovaných spuštění a četnost ručních zásahů. Jakmile některý ukazatel začne růst, projděte poslední změny v konfiguraci. Většina problémů s tímto krokem se dá odstranit do hodiny, pokud víte, kde hledat, a pokud ne, dokáže blokovat vydání celé týdny.

Dalším rizikem je sdílení jednoho úložiště cache mezi větvemi. Data z jedné větve mohou ovlivnit výsledek v jiné a chyba se projeví nepravidelně. Oddělte klíče cache podle větve nebo podle otisku konfigurace. Pokud používáte paralelní běhy, zajistěte, aby si vzájemně nepřepisovaly výstupy. Kolize v názvech souborů se projeví jako poškozený artefakt, který projde testy jen náhodou.

Začněte pojmenováním. Proměnná data nic neznamená, seznamObjednavek už ano. Funkce handleClick neříká, co se stane, odesliFormular ano. Pokud název potřebuje komentář, je název špatný. Platí to i pro zkratky: usr, tmp nebo val šetří tři znaky a stojí minuty přemýšlení při každém čtení. Pište celá slova, dokud se to nezačne vymykat kontrole.

Čistý kód v JavaScriptu není o estetice ani o tom, kdo má raději taby a kdo mezery. Je to o tom, že za půl roku budete stejně zmatení jako kolega, který váš soubor otevře poprvé. Rozdíl mezi kódem, který se dá číst, a kódem, který se dá jen spustit, vzniká v maličkostech, které se dají zavést okamžitě.

Nakonec komentáře. Komentář, který opisuje, co řádek dělá, je šum. Užitečný komentář vysvětluje proč: proč je tu zpoždění, proč se kontrola přeskočí, odkud pochází magická konstanta. Pokud kód potřebuje vysvětlení na každém druhém řádku, není problém v komentářích, ale v návrhu. Čistý kód se nepozná podle toho, že se líbí autorovi, ale podle toho, že v něm kolega najde chybu dřív, než ztratí trpělivost.

Should you adored this post in addition to you would want to receive more information regarding http://lineage2.Hys.cz/ generously pay a visit to the page.