Kde parametrizace končí a začíná ruční prá

Požadavek na sloučení nemá být formalita. Napište do něj, co změna řeší, jak jste ji otestovali a na co si dát pozor. Recenzent nemá hádat záměr z deseti commitů. Když je změna velká, rozdělte ji na několik menších požadavků. Malé změny se kontrolují rychleji a snáze se vracejí, pokud se něco pokazí. Nikdy neschvalujte vlastní změnu jen proto, že spěcháte.

Pro vzdálenou spolupráci slouží git push a git pull. Po prvním propojení s remote úložištěm stačí git push -u origin main. Před každým pushnutím si stáhněte změny ostatních: git pull --rebase. Vyhnete se zbytečným merge commitům a konfliktům, které vznikají zbytečně. Konflikt neřešte panickým mazáním souborů. Otevřete soubor, najděte značky >>>>>>, ručně vyberte správnou verzi, soubor uložte, přidejte přes git add a dokončete rebase nebo merge commitem.

Typické chyby: honit číslo místo chování, testovat jen šťastnou cestu, ignorovat chyby v datech a závislosti, nebo si myslet, že pokrytí nahradí ruční průzkumné testování. Také je chyba měřit pokrytí u kódu, který se často mění a brzy zmizí. U nestabilních částí systému je lepší investovat do lepšího návrhu než do testů, které za týden přestanou platit.

Na co si dát pozor v praxi První chyba je zvolit NoSQL jen proto, že je moderní. U transakcí, kde potřebujete atomicitu přes více entit, je relační databáze stále bezpečnější volba. NoSQL transakce existují, ale mívají slabší záruky a složitější obsluhu. Druhá chyba je ignorovat modelování podle dotazů. V relační databázi navrhnete tabulky a dotazy přijdou později. U NoSQL je to obráceně: nejdřív zjistěte, jak se data budou číst, a podle toho navrhněte dokumenty nebo klíče. Třetí chyba je podcenit konzistenci. Distribuované systémy často volí dostupnost před okamžitou shodou, takže se můžete setkat s zastaralými daty. Pro platby nebo skladové zásoby je to nepřijatelné.

Nejčastější chyba je git commit bez předchozího git add. Výsledkem je prázdný commit nebo zpráva, že nejsou žádné změny. Další častá past je git reset --hard. Tento příkaz nevratně zahodí necommitnuté změny. Pokud ho omylem spustíte, Git vám sice může pomoci přes git reflog, ale pouze u commitů, které už existovaly. Neuložené soubory jsou v nenávratnu. Před každým tvrdým resetem si udělejte záložní kopii složky nebo změny nejprve commitněte.

NoSQL není jedna technologie, ale skupina databází, které opouštějí pevné tabulky a cizí klíče. Místo toho ukládají data jako dokumenty, klíč-hodnota páry, široké sloupce nebo grafy. Každý typ řeší jiný problém: dokumentové databáze drží celý objekt pohromadě, klíč-hodnota slouží k bleskovému čtení podle identifikátoru, grafové databáze zvládají vztahy mezi entitami. Než začnete, položte si otázku, jestli vůbec potřebujete měnit přístup. Pokud data sedí v tabulkách a dotazy jsou rychlé, přechod jen přidá práci.

Než začnete cokoliv ukládat, nastavte si jméno a e-mail: git config --global user.name "Jana Nováková" a git config --global user.email "jana@example.com". Bez toho Git odmítne commit vytvořit nebo k němu přiřadí nesmyslné údaje. U globálního nastavení pozor na firemní počítač, kde se může míchat soukromá a pracovní identita. Pro konkrétní repozitář použijte příkaz bez přepínače --global. Zkontrolujte výsledek pomocí git config --list.

Git ukládá historii projektu jako sérii snímků. Každý snímek vznikne tak, že označíte změny příkazem git add a uložíte je příkazem git commit -m "popis". Tento commit je pak dohledatelný podle jedinečného hashe. Pokud ho neuděláte, změny zůstanou jen v pracovním adresáři a při přepnutí větve nebo neopatrném příkazu git checkout -- . zmizí bez varování. Proto platí: když dokončíte logický celek, commitněte. Ne za hodinu, ne večer, ale hned.

Praktický postup je jednoduchý. Sepište si přístupové vzory: co se čte, jak často, podle čeho se filtruje a co se zapisuje. Zjistěte, jestli data porostou do stovek milionů záznamů a jestli musí být dostupná i při výpadku části clusteru. Pak zvolte typ databáze. Pro katalog produktů s různými atributy se hodí dokumentový model. Pro relace mezi uživateli, doporučení a sítě je přirozený graf. Pro čítače, cache a fronty zvolte klíč-hodnota. A pokud potřebujete analytiku přes mnoho dimenzí, NoSQL nemusí být správná odpověď.

Hlavní důvod, proč NoSQL vzniklo, je škálování a pružnost schématu. Relační databáze zvládne vertikální růst jen do určitého bodu, pak je potřeba rozdělit data na více strojů. Distribuované NoSQL databáze to dělají nativně, často pomocí shardingu a replikace. Druhý důvod je vývoj: když se struktura dat mění každý týden, migrace tabulek zdržuje. Dokumentové databáze umožní uložit různé verze objektu vedle sebe a aplikace si poradí s chybějícími poli. To je výhoda i past, protože bez kontroly schématu snadno vznikne nekonzistentní nepořádek.