Na závěr si řekněme, čemu se vyhnout. Nikdy necommitujte citlivé údaje, jako jsou hesla, API klíče nebo přihlašovací údaje. I když později soubor smažete, historie commitu ho stále obsahuje. Pokud se tak stane, je nutné přepsat historii, což je pro začátečníka složité. Dále se vyhněte commitování velkých binárních souborů, pokud to není nezbytně nutné – repozitář se tím rychle nafoukne a zpomalí. A hlavně: verzování není jen o ukládání změn, ale o přemýšlení nad tím, co děláte. Pravidelný a smysluplný commit vám dá jistotu a svobodu tvořit bez strachu, že něco rozbijete.<br>
<br>
<br>
<br>
Začněte u názvů. Funkce by měla být pojmenovaná podle toho, co dělá, ne jak to dělá. Místo processData použijte filterOrdersByStatus. Proměnné popisujte jejich obsah: userList místo arr, isLoading místo flag. Vyhněte se zkratkám, které nejsou zjevné – cfg, tmp nebo data neříkají nic. Pokud si nejste jistí názvem, znamená to, že funkce pravděpodobně dělá více věcí najednou.<br>
<br>
<br>
<br>
<span style="font-weight: 900;">Dalším krokem je rozdělení</span> <span style="font-weight: 700;">kódu do malých funkcí</span>. Pokud funkce dělá více než jednu věc, rozdělte ji. Například místo jednoho bloku, který validuje formulář, ukládá data a posílá notifikaci, vytvořte tři samostatné funkce. Výhodou je snadnější testování a opětovné použití. Pozor ale na přehnané členění – příliš mnoho jednorázových funkcí zbytečně komplikuje čtení. Ideální je najít rovnováhu.<br>
<br>
<br>
<br>
Základní cyklus práce s Gitem vypadá takto: provedete změny, označíte je jako připravené a potvrdíte je. Nejprve si zkontrolujte stav pomocí git status. Poté přidejte soubory do tzv. staging area příkazem git add . (všechny) nebo git add název_souboru (jen vybrané). Následně změny uložíte pomocí git commit -m "Popis změny". Každý commit by měl mít stručný a výstižný popis, který říká, co jste upravili a proč. Vyhněte se hromadným commitům typu "opravy" – později se v nich nevyznáte.<br>
<br>
<br>
<br>
Začněte tím, že si jasně nadefinujete, co od databáze potřebujete. Napište si seznam dotazů, které bude aplikace skutečně spouštět, a zkuste je promítnout do modelu. Pokud potřebujete flexibilní schéma, kde každý záznam může mít jiné pole, dokumentová databáze vám ušetří práci s migracemi. Typický příklad: ukládáte produktová data, která se liší podle kategorie – elektronika, oblečení, potraviny. V SQL byste buď použili EAV (entity-attribute-value) a přišli o výhody relačního modelu, nebo byste dělali velký počet prázdných sloupců. V dokumentové databázi to prostě uložíte jako strukturu, která odpovídá realitě.<br>
<br>
<br>
<br>
NoSQL není jeden nástroj, ale rodina databází, které se liší datovým modelem. Existují dokumentové (JSON), sloupcové, klíč-hodnota a grafové. Každý typ řeší jiné problémy. Dokumentové databáze se hodí pro obsahově heterogenní záznamy, které byste v SQL řetězili přes deset JOINů. Sloupcové jsou vhodné pro analytiku nad obrovskými tabulkami, kde čtete jen vybrané sloupce. Klíč-hodnota je extrémně rychlá pro jednoduché operace, a grafové databáze zase skvěle modelují vztahy – typicky sociální sítě, doporučovací systémy nebo řízení práv.<br>
<br>
<br>
<br>
Další důležitou dovedností je umět se vrátit k předchozímu stavu. Pokud jste provedli commit a zjistíte, že je něco špatně, můžete se pomocí historie podívat na jednotlivé commity a vybrat ten, ke kterému se chcete vrátit. Pozor ale na to, že pokud jste provedli další změny a ty nejsou commitnuté, mohou se dostat do konfliktu. Vždy si proto před návratem uložte nebo zahoďte aktuální rozpracovanou práci. Dobré je také vědět, že commit nemusí být trvalý – můžete jej upravit, sloučit s jiným, nebo úplně odstranit, dokud nedojde k publikaci.<br>
<br>
<br>
<br>
Nakonec pamatujte, že čistý kód není cíl, ale proces. Pravidelně provádějte code review, používejte lintery a formátovací nástroje, ale hlavně přemýšlejte nad každým řádkem – jestli by mu porozuměl někdo, kdo projekt nezná. Tento přístup se vám vrátí nejen v údržbě, ale i ve vlastním pohodlí při dalším vývoji.<br>
<br>
<br>
<br>
Čistý kód není o osobním vkusu, ale o udržitelnosti projektu. Když píšete JavaScript, každé rozhodnutí – od názvu proměnné po strukturu funkcí – ovlivní, jak snadno se bude kód číst a měnit. Základním pravidlem je, že kód se píše jednou, ale čte se mnohokrát. Proto se vyplatí investovat čas do srozumitelnosti hned na začátku, místo abyste se k němu vraceli později s frustrací.<br>
<br>
<br>
<br>
Jak kombinovat Grid a Flexbox bez chaosu Představte si, že stavíte rozvržení stránky. Grid používáte pro hlavní mřížku – třeba pro umístění hlavičky, obsahu, bočního panelu a patičky. Flexbox pak nechte na menší komponenty, jako je navigace, tlačítka nebo karty uvnitř jednotlivých sekcí. Tímto způsobem oddělíte makro a mikro úroveň návrhu. Například hlavní kontejner může mít definici grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)); a každý prvek uvnitř pak použije display: flex; pro zarovnání obsahu. Tento přístup je přehledný a snadno udržovatelný.
