Jak propojit design a kód: UI/UX základy pro vývojáře
Vyvarujte se také hlubokému vnořování. Pokud máte tři úrovně if-else nebo for smyček, je to signál k refaktoringu. Použijte early return: místo if (condition) { … } else { … } napište if (!condition) return; a pokračujte rovnou. Tím se snižuje mentální zátěž a kód je lineárnější. Stejně tak se vyhněte opakování – pokud se nějaká logika vyskytuje na více místech, vytáhněte ji do sdílené funkce.
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.
Čistý kód není o osobním vkusu, ale o udržitelnosti projektu. Když píšete JavaScript, každá funkce, proměnná nebo komentář buď pomáhá, nebo zavazí. Základní pravidlo zní: kód se čte několikrát častěji, než se píše. Proto se vyplatí myslet na toho, kdo bude váš kód číst za půl roku – a tím člověkem budete nejspíš vy sami.
Psaní testů bývá často odkládáno na později, ale s knihovnou pytest se z něj stane překvapivě rychlá a příjemná činnost. Na rozdíl od složitějších frameworků nabízí pytest jednoduchou syntaxi, která nevyžaduje psát třídy ani dědit z testovacích základů. Stačí obyčejné funkce, které začínají slovem test_, a pytest je automaticky najde a spustí. Díky tomu se dá testování naučit za odpoledne a postupně ho zapojit do běžného vývoje.
Když se řekne REST API v Node.js, většina vývojářů sáhne po frameworku Express. Není to náhoda – Express je minimalistický, dobře zdokumentovaný a díky své flexibilitě vám umožní postavit API přesně podle potřeb. Než ale začnete psát první endpoint, ujasněte si, co vlastně chcete, aby vaše API dělalo. Bez jasné definice zdrojů a jejich vztahů snadno skončíte u nepřehledného kódu, který se bude těžko udržovat.
Výběr správného vývojového prostředí (IDE) pro Python není jen otázkou osobního vkusu, ale především efektivity práce. Každý projekt má jiné nároky: jednoduchý skript pro automatizaci zvládnete i v textovém editoru, ale rozsáhlá aplikace s frameworkem, testy a verzováním si žádá nástroj s pokročilými funkcemi. Než se rozhodnete, zvažte, co budete skutečně psát, a nepodléhejte módním vlnám. Většina IDE nabízí bezplatné verze, ale placené funkce jsou často zbytečné pro začátečníky i pro středně pokročilé.
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.
Základní test vypadá tak, že do souboru s názvem test_nazev.py napíšete funkci test_něco() a uvnitř použijete příkaz assert. Například chcete-li ověřit, že funkce secti(2, 3) vrací 5, stačí napsat assert secti(2, 3) == 5. Pytest při selhání ukáže, které hodnoty se lišily, takže nemusíte psát vlastní hlášky. Důležité je testy psát tak, aby byly nezávislé na pořadí, a proto se vyhýbejte sdíleným proměnným napříč testy. Pokud potřebujete připravit data, použijte takzvané fixture, které se definují pomocí dekorátoru @pytest.fixture a pak se předávají jako parametry funkce.
Nakonec pamatujte na konzistenci. Zvolte si styl – úvodzovky, středníky, odsazení – a držte se ho v celém projektu. Využijte nástroje, které formátují kód automaticky, a nastavte si lintovací pravidla na začátku projektu. Čistý kód není o dokonalosti, ale o tom, aby se v něm dalo snadno hledat chyby a přidávat nové funkce bez rizika rozbití stávajícího chování.
Rozdělte kód na malé, jednoúčelové funkce Funkce by měla mít jednu odpovědnost. Ideální délka je do dvaceti řádků, ale jde spíš o to, aby se dala pochopit na první přečtení. Typická chyba začátečníků je psát dlouhé funkce, které validují vstup, mění stav a renderují UI. Místo toho rozdělte logiku do samostatných funkcí s jasnými vstupy a výstupy. Například funkce pro výpočet ceny by neměla zároveň ukládat data do localStorage.
Pozor také na přístupnost, kterou vývojáři často podceňují. Nejde jen o povinnost, ale o praktickou funkčnost. Uživatelé se zhoršeným zrakem, pohybovým postižením nebo jen s modrým filtrem na obrazovce ocení, když dodržíte kontrastní poměry, nastavíte správné alt texty u obrázků a umožníte ovládání klávesnicí. Typická chyba? Spoléháte na to, že stačí barevně odlišit tlačítko, ale ignorujete, že barevně slepý uživatel nerozpozná, že je aktivní. Přidejte ikonu nebo textovou změnu kromě barvy, a problém je vyřešen.