Jak psát smysluplné commit zprávy pro snadnou zpětnou dohledatelnost

Funkce by měly dělat jednu věc a dělat ji dobře. Pokud má funkce více odpovědností (např. načítá data a zároveň je zobrazuje), rozdělte ji na dvě menší. Dobrým testem je, když název funkce začíná slovesem – `getData()`, `renderList()`, `validateInput()`. Snažte se, aby funkce měla maximálně dva až tři parametry. Když jich je víc, zabalte je do objektu – usnadníte tím čtení i budoucí rozšiřování.

Jak na to: struktura a kontext Začněte krátkým shrnutím do 50 znaků, které vystihuje podstatu změny. Poté, pokud je třeba, přidejte prázdný řádek a pokračujte podrobnějším popisem. Vysvětlete, jaký problém řešíte, jaké jsou důvody volby řešení, a pokud má změna vliv na chování aplikace, popište i to. Nezapomeňte zmínit případné vedlejší účinky nebo nutnost migrace dat. Tento kontext je klíčový pro pochopení rozhodnutí, která jste udělali.

Nakonec si zvykněte na limitování výsledků. Pokud potřebujete jen prvních sto řádků, použijte LIMIT. Databáze pak může ukončit zpracování dřív, než projde celou tabulku. Stejně tak se vyhněte přenosu obrovských datasetů do aplikace – zpracujte agregace na straně databáze. Pravidelně čistěte staré záznamy, ale pokud to není nutné, nearchivujte do stejné tabulky. Udržování tabulek v dobré kondici – bez fragmentace – také pomůže.

Jak správně psát JOIN a subdotazy Při spojování tabulek se vyhněte křížovým spojením a dbejte na to, aby každý JOIN měl jasnou podmínku. Vždy spojujte přes indexované klíče. U subdotazů zkuste nejprve myslet na to, jestli je nelze přepsat pomocí JOIN. Například dotaz s IN (SELECT ...) může být po přepsání na JOIN rychlejší, ale ne vždy – záleží na databázi a distribuaci dat. Měřte obě verze a porovnejte.

Při psaní zprávy se držte přítomného času, rozkazovacího způsobu – to je běžný standard. Nezapomeňte také na konzistenci v rámci týmu. Domluvte si šablonu, třeba s prefixy jako „feat:" pro nové funkce, „fix:" pro opravy, „refactor:" pro úpravy bez změny chování. Taková pravidla zvyšují čitelnost a umožňují automatické generování changelogů.

Před odesláním pull requestu si ověřte, že váš kód prochází všemi testy. Pokud projekt žádné testy nemá, zkuste alespoň spustit sestavení. Typickou chybou je poslat změny, které fungují jen u vás, ale rozbijí něco jiného. Po odeslání pull requestu se může stát, že vám správci napíšou připomínky. Nebuďte z toho frustrovaní – je to běžná součást spolupráce. Reagujte na komentáře věcně, vysvětlujte své rozhodnutí a případně upravte kód.

Druhým častým problémem je používání funkcí na sloupcích v podmínkách. Pokud napíšete WHERE YEAR(datum) = 2024, index na sloupci datum se nepoužije, protože databáze musí funkci aplikovat na každý řádek. Řešení spočívá v porovnávání intervalů: WHERE datum >= '2024-01-01' AND datum <'2025-01-01'. Stejně dejte pozor na operace typu LIKE s divokou kartou na začátku vzoru, které také znemožní využití indexu.

Nejdřív si vyberte projekt, který vás skutečně zajímá a používáte ho. Otevřete si jeho repozitář a projděte sekci pro nováčky – obvykle bývá označená jako „issues" nebo „contribute". Hledejte štítky jako „good first issue" nebo „help wanted". Tato místa jsou určená přesně pro začátečníky, takže se nemusíte bát, že byste něco rozbili. Přečtěte si také soubor s pokyny pro přispěvatele, pokud existuje – najdete v něm pravidla pro formát kódu, styl commitů i postup pro pull request.

Typickou chybou je psát dlouhé podmínky s mnoha logickými operátory. Místo `if (uzivatel && uzivatel.prava && uzivatel.prava.admin)` si vytvořte pomocnou proměnnou nebo funkci, třeba `jeAdmin(uzivatel)`. Stejně tak se vyhněte hlubokému vnořování – když potřebujete tři úrovně `if` nebo cyklů, zamyslete se, jestli to nejde zjednodušit. Často pomůže včasný návrat: místo jedné velké podmínky s návratem na konci použijte `if (!podminka) return;` hned na začátku.

Pozor také na ignorování konvence týmu. Pokud máte nastavený formát pro commit zprávy (např. prefixy jako feat, fix, refactor), dodržujte ho. Konvence nejsou byrokracie, ale nástroj pro rychlé filtrování v logu. A pokud začínáte nový projekt, nastavte si jednoduché pravidlo hned na začátku – snáz se to udržuje než později.

Pozor na používání DISTINCT, které často maskuje chybu v JOINu, kdy se řádky zbytečně násobí. Pokud vidíte DISTINCT, zeptejte se, proč tam je. Obvykle je lepší spojení upravit tak, aby nebylo potřeba. Také se vyhněte používání funkcí na agregovaných sloupcích v WHERE, protože to nutí databázi zpracovat všechna data. Místo toho použijte HAVING, ale pamatujte, že HAVING se aplikuje až po agregaci, takže je pomalejší než WHERE.