View source for Když commit zpráva šetří čas při hledání viníka změny

Asynchronní kód je další místo, kde vzniká zmatek. Nemíchejte async/await s .then() v jedné funkci. Zvolte jeden styl a držte se ho. U await vždy myslete na chyby – obalte volání do try/catch, nebo použijte pomocnou funkci, která vrací dvojici hodnot. Nikdy nenechávejte odmítnutý promise bez ošetření, jinak dostanete tichý pád, který se hledá těžko.<br><br>Rozdělte testování na několik úrovní. Unit testy ověřují jednotlivé funkce a běží rychle při každé změně. Integrační testy kontrolují spolupráci mezi moduly, například mezi sítí a lokální databází. UI testy simulují skutečné chování uživatele a odhalí problémy s rozvržením či navigací. Ruční průzkumné testování pak doplní to, co automatizace nepokryje – neobvyklé kombinace kroků, přerušení hovorem, otočení displeje, slabý signál.<br><br>Nasazení oddělte od testování. Jeden workflow, který po každém pushe do hlavní větve rovnou nasadí na produkci, je rychlá cesta k výpadku. Lepší je nechat testy běžet na každý push a nasazení vázat na větev, tag nebo ruční schválení. Do pipeline přidejte i kontrolu, že se běh dokončil v rozumném čase — tichý běh, který visí hodinu, blokuje frontu a odrazuje od častých commitů.<br><br>Parametrizované dotazy bezpečně oddělí data od kódu, ale jen pro hodnoty, které patří do klauzulí WHERE, VALUES nebo SET. Jakmile aplikace potřebuje měnit název sloupce pro řazení nebo název tabulky podle vstupu od uživatele, musí přijít jiná obrana. Řešením není escapování uvozovek, ale mapování na pevný seznam povolených hodnot. Uživatel pošle klíč, aplikace ho přeloží na konkrétní název sloupce. Pokud klíč v seznamu není, dotaz se vůbec nesestaví a vrátí se chyba. Tím zmizí prostor pro vložení poddotazu nebo podmínky, která vrátí celou tabulku.<br><br>Proč selhávají běhy a jak tomu předejít Nejčastější chyba není v syntaxi, ale v prostředí. Běhy startují v čistém kontejneru, kde nejsou žádné globálně nainstalované nástroje ani tajné proměnné. Pokud testy projdou na vašem počítači a v pipeline ne, hledejte rozdíl ve verzi jazyka, v chybějící závislosti nebo v proměnné prostředí. Verzi vždy přišpendlete, například node-version: 20, místo aby spoléhaly na výchozí hodnotu, která se může kdykoli změnit.<br><br>Každý commit v repozitáři je malý záznam o tom, co se změnilo a proč. Pokud zpráva říká jen „oprava" nebo „update", za půl roku nebudete vědět, co se opravovalo ani proč. Cílem není psát romány, ale dodat dost kontextu, aby se změna dala dohledat zpětně – od řádku kódu k důvodu, proč tam je.<br><br>Typická chyba je psát zprávu podle sebe, ne podle toho, kdo ji bude číst. Kolega, který za rok hledá, proč se změnilo chování tlačítka, potřebuje vědět, že šlo o opravu chyby na základě hlášení z provozu. Proto se vyplatí uvádět kontext: číslo úkolu, pokud existuje, ale i krátké vysvětlení, co bylo před změnou špatně. Stejně tak je chybou míchat do jednoho commitu refaktoring, opravu chyby a novou funkci – dohledatelnost tím trpí nejvíc.<br><br>Nakonec: čistota není jednorázový úklid, ale návyk. Před každým commitem si přečtěte, co jste napsali, a zkuste to zkrátit, aniž byste ztratili význam. Pokud váháte, zda je kód jasný, přečtěte ho nahlas. Kde se zaseknete, tam bude zaseknutý i kolega. Nástroje jako linter a formátovač nastavte hned na začátku projektu, ne až když je kód plný nekonzistencí. Automatické formátování odstraní hádky o styl a vy se můžete soustředit na logiku.<br><br>Základem je dodržet strukturu, kterou zvládne přečíst člověk i nástroj pro procházení historie. První řádek pište v rozkazovacím způsobu a kratce: „Oprav datum u faktury za prosinec". Do 50–72 znaků se vejde téměř vždy. Pokud potřebujete víc, dejte po prvním řádku prázdný řádek a teprve pak rozveďte podrobnosti – co bylo špatně, co jste změnili a proč zrovna takto.<br><br>Dobře napsaná zpráva se pozná tak, že při hledání v historii nemusíte otevírat samotný diff. Stačí projít seznam commitů a máte jasno. Zaveďte si jednoduchý zvyk: nejdřív napište, co změna dělá, pak proč, a teprve nakonec zmiňte, jak. Výsledkem je historie, která se dá číst jako deník projektu – a to je při zpětné dohledatelnosti změn ta nejcennější vlastnost.<br><br>Co do zprávy patří a co naopak škodí Užitečná zpráva odpovídá na tři otázky: co se změnilo, proč to bylo potřeba a jaký to má dopad. Místo „přidal jsem podmínku" napište „přidává kontrolu prázdného vstupu, aby aplikace nespadla při importu bez hlavičky". Vyhněte se odkazům na interní systémové zkratky, kterým po čase nikdo nerozumí, a vynechejte i výrazy jako „různé úpravy" nebo „úklid". Pokud commit obsahuje víc nesouvisejících změn, raději je rozdělte do několika menších – historie pak zůstane čitelná a snadno dohledatelná.