Typická chyba začátečníků je snaha naučit se všechno najednou. Místo toho si dejte malé cíle: zobrazit text, reagovat na stisk tlačítka, uložit hodnotu po otočení obrazovky. Další častá chyba je ignorování správy paměti a kontextu – aplikace pak spadne při rotaci nebo při přechodu na jinou obrazovku. Vždy testujte na více zařízeních s různými verzemi systému. Emulátor sice stačí na základní ověření, ale skutečný telefon odhalí problémy s výkonem i s ovládáním.

Typická chyba je snaha udržet poměr 70/20/10 za každou cenu. Pokud tým tráví víc času opravováním testů než psaním kódu, poměr je špatně. Další častá chyba je nahrazení pomalu běžících end-to-end testů jednotkovými testy, které ale netestují integraci. Výsledkem je zelená sada, která nic neověřuje. Pyramida má sloužit toku hodnoty, ne naopak.

Častou chybou je příliš agresivní limit, který zablokuje i běžné procházení. Uživatel, který rychle kliká, může narazit. Proto vždy nastavte limit s rezervou a testujte. Další chyba je ignorování hlaviček z proxy. Pokud nepoužijete správné nastavení, všechny požadavky přijdou z IP proxy a vy zablokujete celý svět. Také nedělejte rate limiting na úrovni celé aplikace, pokud to není nutné. Lepší je aplikovat ho jen na kritické routy pomocí router-level middlewaru.

Nakonec se vyplatí měřit, ne hádat. Změňte jeden prvek, změřte dobu a plán, a teprve pak dělejte další úpravu. Sledujte nejpomalejší dotazy průběžně, protože seznam se mění s tím, jak rostou data. Výkon není jednorázový úkol, ale rutina: aktualizovat statistiky, hlídat nevyužívané indexy a kontrolovat, jestli podmínky nebrání jejich použití.

Propojení obou repozitářů řešte při nasazení, ne v kódu. Aplikace by měla konfiguraci načítat z předem dané cesty nebo z proměnných prostředí, nikoli odkazovat na konkrétní soubor v repozitáři s kódem. Názvy klíčů a strukturu formátu držte v obou repozitářích shodné, ideálně popsané jednou šablonou. Když se formát změní, upravte šablonu v repozitáři s kódem a hodnoty v repozitáři s konfigurací. Rozdíl odhalíte testem, který ověří, že všechny povinné klíče jsou přítomné.

Typescript není o tom naučit se všechny typy nazpaměť. Je o tom vytvořit prostředí, kde chyby vznikají co nejdříve a kde kód vydrží i po letech. Pokud začnete s přísným režimem a malými kroky, brzy zjistíte, že vám Typescript nezpomaluje práci, ale naopak zrychluje opravy a úpravy. Největší pastí je snaha přepsat celý projekt naráz. Mnohem lepší je zavádět typy postupně, soubor po souboru, a nechat kompilátor, ať vás vede.

Jak začít bez zbytečných složitostí Základem je soubor tsconfig.json. Bez něj Typescript neví, jak se má chovat. Většina začátečníků zkopíruje výchozí konfiguraci a pak se diví, proč jim nefunguje import nebo proč se soubory nekompilují. Klíčové je nastavit "strict": true. Ano, ze začátku to bolí, ale odhalí to chyby, které byste jinak hledali hodiny. Dále nastavte "target" na verzi, kterou váš runtime skutečně podporuje. Pokud vyvíjíte pro prohlížeč, použijte "ES2015" nebo novější. Pro Node.js zvolte verzi odpovídající vaší instalaci.

Poslední věc, kterou mnoho vývojářů podcení, je nastavení editoru. Moderní editory umí Typescript kontrolovat průběžně a nabízet opravy. Pokud ale nemáte správně nastavenou verzi Typescriptu, můžete vidět chyby, které ve skutečnosti neexistují, nebo naopak přehlédnout ty skutečné. Zkontrolujte, že editor používá stejnou verzi Typescriptu jako váš projekt. To znamená nainstalovat Typescript lokálně a v nastavení editoru zvolit cestu k této verzi. Předejdete tak zmatkům, které pramení z rozdílného chování různých verzí.

Typescript není jen Javascript s typy. Je to nástroj, který mění způsob, jakým přemýšlíte o kódu. Pokud jste zvyklí psát rychle a bez omezení, první dny s Typescriptem vás mohou frustrovat. Kompilátor hlásí chyby, které byste dříve ignorovali, a vy musíte neustále definovat rozhraní a typy. To je ale přesně ten bod, kdy se zvyšuje kvalita výsledného kódu. Nejde o to psát méně, ale psát s jistotou, že chyba neprojde do produkce.

Typy nepíšete všude. Typescript umí odvodit typy z přiřazené hodnoty. Pokud tedy napíšete const pocet = 5, kompilátor ví, že jde o číslo. Zbytečné explicitní typy jen znepřehledňují kód. Naopak u parametrů funkcí a návratových hodnot se vyplatí typy uvádět. Zabráníte tak tomu, aby někdo funkci zavolal s nesprávným argumentem. Typickým přešlapem je použití typu any. Ten vypne kontrolu a celý smysl Typescriptu mizí. Když narazíte na situaci, kdy typ neznáte, použijte unknown a proveďte kontrolu za běhu.