5 zásad, které vám ušetří hodiny hledání chyb ve verzování webu

Nakonec si zkuste představit, že zprávu čte někdo, kdo nezná kód. Pokud po přečtení tuší, co se změnilo a proč, je to dobrá zpráva. Pravidelně se vracejte ke starým commitům a hodnoťte, zda byste podle nich dokázali rekonstruovat rozhodovací proces. Časem vám psaní smysluplných zpráv půjde samo a stane se přirozenou součástí práce.

Prvním krokem je důkladná analýza schématu. MySQL umožňuje automatické přetypování řetězců na čísla nebo používá implicitní konverze, které PostgreSQL odmítá. Typickým příkladem je sloupec typu enum – v PostgreSQL se doporučuje převést na varchar s kontrolním omezením, protože enum zde nelze snadno rozšiřovat. Podobně dopadnou sloupce s nulovými hodnotami a prázdnými řetězci: PostgreSQL rozlišuje NULL a prázdný řetězec, zatímco některé aplikace psané pro MySQL je zaměňují.

Konzolová aplikace je ideální hřiště, kde si osvojíte logiku, ladění a práci s chybami. Až zvládnete vstupy, výstupy a podmínky, zkuste přidat smyčku, která program spustí opakovaně. Tím získáte základ pro složitější projekty, jako jsou třeba hry nebo nástroje pro zpracování dat. Začněte malými kroky a nebojte se chyb – každá vás posune dál.

Největší zrádce: řazení a porovnávání textu Dalším častým problémem je řazení. MySQL ve výchozím nastavení používá porovnávání bez ohledu na velikost písmen a ne vždy respektuje českou diakritiku. PostgreSQL používá pravidla podle zvolené locale. Pokud vaše aplikace spoléhá na konkrétní pořadí výsledků, musíte to ošetřit explicitně – buď definováním collation přímo u sloupce, nebo použitím funkce lower v dotazech. Jinak se může stát, že se výpis uživatelů seřadí podle ASCII hodnot a „Černý" skončí až za „Zelený", což je pro uživatele matoucí.

Přechod z MySQL na PostgreSQL bývá častější, než se zdá. Důvodem bývá potřeba pokročilejších datových typů, lepší podpory fulltextového vyhledávání nebo jen touha po robustnější správě souběžného přístupu. Samotná migrace ale není kopírováním souborů. Klíčové je pochopit rozdíly v chování obou systémů a připravit si data i schéma tak, aby přenos proběhl hladce.

Dalším častým problémem jsou funkce a triggery. MySQL a PostgreSQL mají odlišnou syntaxi pro uložené procedury a triggery. Většinu kódu budete muset přepsat, a to nejen kvůli syntaxi, ale i kvůli rozdílnému chování transakcí. PostgreSQL klade větší důraz na atomicitu a izolaci, což může odhalit chyby v logice, které v MySQL nebyly vidět. Otestujte všechny kritické operace, zejména ty, které zapisují více tabulek najednou.

Myslete také na kontext. Commitová zpráva není místo pro kompletní dokumentaci, ale měla by obsahovat odkazy na související úkoly nebo čísla ticketů, pokud je to ve vašem týmu zvykem. Důležité je, aby čtenář okamžitě pochopil, k čemu se změna vztahuje. Nepoužívejte ale zkratky bez vysvětlení – „oprava #123" neřekne nic, pokud čtenář nemá přístup k systému. Raději napište „oprava výpočtu daně (ticket #123)".

Další pastí je míchání nesouvisejících změn do jednoho commitu. Pokud opravujete chybu a zároveň přejmenováváte proměnné, vznikne z toho nepřehledná směs. Budoucí čtenář nebude schopen rozlišit, co je podstatné. Dělejte menší commity, každý zaměřený na jednu logickou jednotku. Pokud potřebujete provést více změn, rozdělte je do více commitů, i kdyby to znamenalo více práce navíc. Historii pak lze snadno číst a případně vracet zpět.

Prvním krokem je vytvořit jednotný popis všech endpointů na jednom místě. Nejlépe ve formátu, který může backend rovnou generovat z kódu, a frontend si ho může stáhnout do svého vývojového prostředí. Vyhněte se ručně psaným dokumentům v textových editorech – ty rychle zastarávají a nikdo je neudržuje. Místo toho používejte nástroje, které popis API generují z anotací nebo z definic datových struktur. Díky tomu bude dokumentace vždy odpovídat skutečnému stavu aplikace, což je nejdůležitější podmínka pro to, aby jí lidé věřili a používali ji.

Začněte krátkým shrnutím v rozsahu maximálně padesáti znaků. Toto shrnutí by mělo vystihovat podstatu změny, ideálně ve formátu „když…, tak…" nebo „aby…". Například „aby se přihlášení nezaseklo, když API vrátí prázdný token" je mnohem užitečnější než „fix login". Dlouhé zprávy rozdělte na více řádků – první řádek je nadpis, další řádky jsou podrobnosti. Většina nástrojů zobrazí jen první řádek, takže ten musí být srozumitelný sám o sobě.

Dalším častým problémem je ignorování výjimek. Když uživatel zadá místo čísla text a vy ho převedete pomocí Convert.ToInt32(), program spadne. Místo toho použijte int.TryParse(), který vrátí true nebo false podle toho, jestli se převod podařil. Tím zajistíte, že se program nerozběhne po každém špatném vstupu. Vyzkoušejte si to na jednoduché kalkulačce – sčítání dvou čísel, kde uživatel zadá hodnoty a program vypíše výsledek. Budete překvapeni, kolik toho takový malý projekt naučí.