Průvodce TypeScriptem pro začínající vývojáře
Na co si dát pozor při psaní testů Nejčastější chybou bývá testovat implementaci místo chování. Pokud test kontroluje, jak přesně funkce interně pracuje, stává se křehkým a každá změna kódu ho rozbije, i když je výsledek stále správný. Testujte tedy vstupy a výstupy, nikoliv vnitřní proměnné. Dalším častým problémem je používání reálných časů, náhodných hodnot nebo síťových volání přímo v testech – takové testy jsou pomalé a někdy i nespolehlivé. Řešením je tyto závislosti nahradit falešnými objekty, tzv. mocky, nebo alespoň testovat s pevně stanovenými daty.
Migrace databáze mezi MySQL a PostgreSQL patří k častým úkolům při změně technologického stacku. Přestože oba systémy jsou relační a podporují SQL, liší se v detailech, které mohou způsobit neočekávané chyby. Nejde jen o export a import dat – je nutné upravit schéma, typy sloupců, syntaxi dotazů i některé funkce. Připravte si proto dostatek času na testování a postupujte krok za krokem.
Typická chyba začátečníků je testovat příliš mnoho v jednom testu. Jeden test by měl ověřovat jedno chování. Pokud testujete formátování data, neověřujte zároveň práci s časovými pásmy. Pokud test selže, mělo by být okamžitě jasné, která část kódu je rozbitá. Další častý problém je spoléhat se na konkrétní implementaci – test pak musíte měnit pokaždé, když upravíte vnitřek metody. Testujte rozhraní, ne to, jak metoda funguje uvnitř.
Při práci s funkcemi si osvojte volitelné parametry (znak ?) a výchozí hodnoty. Volitelné parametry umožňují zavolat funkci bez daného argumentu, ale uvnitř musíte kontrolovat, zda je hodnota definovaná. Výchozí hodnoty vám ušetří ruční přiřazování undefined. Dávejte si také pozor na typy, které se mění v průběhu času – použijte generické typy, pokud chcete, aby funkce fungovala s libovolným typem při zachování typové bezpečnosti. Například funkce pro zpracování pole by měla být generická, abyste nepřišli o informaci o typu prvků.
Typová inference a praktické tipy TypeScript se snaží uhodnout typy automaticky, což znamená, že nemusíte psát anotace všude. Pokud ale deklarujete proměnnou bez inicializace, dostanete typ any, který vypne veškerou kontrolu. To je častý zdroj chyb. Místo any používejte unknown nebo konkrétní typ, případně zúžený typ pomocí typeof či instanceof. Další častou pastí je práce s poli – pokud máte pole, které může obsahovat různé typy, definujte to explicitně jako union, aby nedošlo k neočekávanému chování při volání metod.
Důležité je také udržovat databázový systém a knihovny aktuální. Dodavatelé opravují známé zranitelnosti, a pokud používáte starou verzi, vystavujete se riziku, které už je veřejně známé. Zavedení těchto opatření – parametrizace, validace, omezení práv, bezpečné chybové hlášky a pravidelné aktualizace – výrazně snižuje pravděpodobnost úspěšného útoku. SQL injection není problém, který by se dal vyřešit jednou provždy, ale kombinací správných návyků a nástrojů ji můžete efektivně eliminovat.
Pro efektivní práci s více jazyky je klíčové také správné nastavení automatického formátování. Nechte editor formátovat při uložení, ale vždy s ohledem na aktuální jazyk. Typická chyba je použití univerzálního formátovače, který sice upraví odsazení, ale rozbije například řetězce v Pythonu nebo šablony v JSX. Vždy si ověřte, že máte pro každý jazyk nainstalovaný jeho nativní formátovač (např. Prettier pro TypeScript, Black pro Python, ale pozor – tyto názvy uvádím jako obecné pojmy, ne jako doporučení konkrétního produktu). Dále si nastavte, aby se automatické doplňování kódu řídilo podle typu souboru, ne podle obsahu – tím předejdete nechtěnému vkládání importů z jiného jazyka.
Časté chyby a jak je odstranit Jednou z typických chyb je dynamické sestavování dotazů pomocí řetězců, zejména když potřebujete řadit podle sloupce zvoleného uživatelem. Pokud uživatel může ovlivnit název sloupce nebo směr řazení, parametrizace nepomůže. V takovém případě vždy použijte seznam povolených hodnot, který ověří, že zadaný řetězec odpovídá skutečnému názvu sloupce. Druhou častou chybou je zapomínání na vstupy vstupující do LIKE, IN nebo ORDER BY klauzulí. I zde platí, že místo přímého vkládání vstupu použijte placeholder a pro dynamické části aplikujte whitelist.
Začněte analýzou stávajícího schématu. MySQL často používá typy jako TINYINT, ENUM nebo AUTO_INCREMENT, které v PostgreSQL nemají přímý ekvivalent. V PostgreSQL použijte typ SMALLINT pro TINYINT, ENUM lze nahradit typem VARCHAR s CHECK omezením nebo nativním typem ENUM (ale jen pokud si uvědomíte jeho omezení při přidávání hodnot). AUTO_INCREMENT se transformuje na SERIAL nebo GENERATED AS IDENTITY – druhá varianta je modernější a doporučovaná. Dávejte pozor také na rozdíly v práci s řetězci: v MySQL je porovnání obvykle case-insensitive, v PostgreSQL záleží na collation, takže budete muset použít ILIKE nebo citext.