Když testy začnou brzdit vývoj, proveďte audit a rozdělte role

Zároveň nezapomínejte na zálohování a obnovu dat. NoSQL systémy často nabízejí replikaci do více uzlů, ale to není totéž jako záloha. Když omylem smažete kolekci, replika smazání zkopíruje na všechny uzly. Pravidelně exportujte data do nezávislého úložiště a testujte obnovu. V praxi se vyplatí začít s NoSQL tam, kde přináší jasnou výhodu – třeba u ukládání uživatelských relací nebo logů – a zbytek aplikace nechat na SQL. Kombinace obou přístupů je častější, než se zdá, a mnoho firem tak řeší výkon bez zbytečného kompromisu.

Nejlepší první volba je taková, která má rychlou zpětnou vazbu a přívětivou syntaxi. Python a JavaScript jsou pro začátek ideální – krátký zápis, čitelný kód a obrovská komunita. U Pythonu se soustřeďte na automatizaci a datové zpracování, u JavaScriptu na interaktivní prvky webu. Když začnete s C++ nebo Javou, čeká vás více technických detailů, které odvádějí pozornost od logiky. Neznamená to, že jsou špatné, ale pro první měsíce učení představují zbytečnou zátěž.

Většina vývojářů sahá po relační databázi automaticky. SQL je osvědčený standard, který se učí na školách a používá v milionech aplikací. Jenže každý projekt má jiné požadavky a právě v okamžiku, kdy potřebujete ukládat nestrukturovaná data nebo škálovat na obrovský objem čtení, začne klasický model narážet na své limity. NoSQL není náhrada za SQL, ale nástroj pro specifické případy, kdy výkon a flexibilita převažují nad striktní konzistencí.

Typickým prohřeškem je, že se e2e testy snaží pokrýt vše. Pak jsou pomalé, nestabilní a jejich údržba vás stojí víc času než psaní nových funkcí. Místo toho je používejte střídmě a na kritické cesty. Když e2e test selže, chcete hned vědět, co se rozbilo. Proto v nich nepoužívejte dlouhé čekací časy na náhodné prvky, ale raději explicitní počkání na konkrétní stav aplikace. A hlavně – když test začne být křehký, neopravujte ho přidáváním čekání, ale zkuste přijít na to, proč je nestabilní. Často to odhalí skutečný problém v aplikaci.

Užitečným nástrojem je takzvaný „test coverage" pro určení kritických částí. Nemusíte dosáhnout stoprocentního pokrytí – pokrytí 70–80 % klíčové obchodní logiky je obvykle rozumné. Důležitější je zaměřit se na rizikové části: platby, oprávnění uživatelů, zpracování souborů. Pokud máte v těchto místech slabé pokrytí, doplňte testy i za cenu, že jinde jich ubude. Pravidelně kontrolujte, které testy se nejčastěji mění. Pokud některý test upravujete při každé implementaci funkce, pravděpodobně testuje příliš mnoho nebo je špatně navržený.

Začněte auditem současného stavu. Projděte si testovací sadu a rozdělte testy do tří kategorií: čisté jednotkové (bez I/O), testy s falešnými závislostmi a plnohodnotné integrační. Každou kategorii měřte zvlášť podle času provedení a četnosti změn. Typická chyba je mít desítky integračních testů, které testují jednu obchodní logiku přes HTTP rozhraní. Přitom stačí jeden integrační test na celý tok a zbytek logiky pokrýt jednotkovými testy s falešnými objekty.

U jednotkových testů si dejte pozor na testování implementace místo chování. Testujte, co funkce dělá, ne to, jak to dělá. Když test začnete plnit kontrolami vnitřních stavů, každá refaktorizace kódu test rozbije, i když chování zůstává stejné. U integračních testů zase hrozí, že budete testovat samotnou databázi, což je zbytečné. Zaměřte se na to, aby test prokázal, že vaše vrstvy spolu správně komunikují, ne že databáze funguje – to už ověřil její výrobce.

Jazyk byste měli měnit pouze v případě, že vám dlouhodobě nevyhovuje způsob myšlení, který vyžaduje. Například pokud vás nebaví psát deklarace typů, vyhněte se Javě. Když nesnesete složené závorky, raději zvolte Python. Nejdůležitější je, abyste se k jazyku vraceli denně, ideálně 20–30 minut. Pravidelnost porazí dávkování – lepší je každý den hodinu než jednou týdně sedm hodin.

Jak si ověřit, že vám jazyk sedne, než do něj investujete měsíce Otevřete si oficiální dokumentaci a zkuste napsat první program podle příkladu. Pokud vám zápis připadá jako řečtina, zkuste jiný jazyk. Důležité je, abyste rozuměli každému řádku, ne jen kopírovali. Dále si najděte tři různé tutoriály na stejné téma – pokud je pochopíte bez hledání dalších zdrojů, máte vyhráno. Pozor na falešné začátečnické jazyky, které sice vypadají jednoduše, ale v praxi vás nenaučí základy, jako jsou proměnné, cykly nebo podmínky.

Základní pravidlo: oddělte konfiguraci pro každý jazyk zvlášť Většina moderních editorů umožňuje vytvořit konfigurační soubory přímo v kořenovém adresáři projektu. Využijte to. Pro Python nastavte formátování podle PEP 8, pro JavaScript použijte standardní styl nebo Prettier, pro TypeScript zase vlastní pravidla. Nezapomeňte, že konfigurace se může lišit nejen mezi jazyky, ale i mezi verzemi stejného jazyka. Pokud používáte více verzí Pythonu, ověřte, že máte pro každou z nich odpovídající interpret. Jinak hrozí, že váš kód bude fungovat lokálně, ale na serveru spadne.