Když vývojář pochopí UI/UX, uživatel se vrací sám
Nezapomeňte, že první zaměstnání není o dokonalém kódu, ale o tom, jestli do týmu zapadnete a jestli se rychle učíte. Proto se vyhněte dvěma extrémům: nepřehánějte své zkušenosti a zároveň se nepodceňujte. Když firma hledá juniora, ví, že bude investovat do vašeho rozvoje. Vaším úkolem je ukázat, že tato investice nebude ztracená. Připravte si proto otázky na plat? Ne, to nechte na pozdější fázi. Místo toho se ptejte na mentoring, na to, jak vypadá první měsíc v práci, nebo na to, co by si přáli, abyste se naučil před nástupem.<br>
<br>
<br>
<br>
Posledním doporučením je testovat pipeline na menší větvi, ne rovnou na main. Vytvořte si větvičku s názvem test-actions, kde si ověříte, že všechny kroky fungují, a teprve poté změnu sloučíte. Tím se vyhnete situaci, kdy rozbijete produkční nasazení kvůli překlepu v YAML. Až budete mít pipeline stabilní, můžete přidat i nasazení do stagingu před produkci, aby se chyby odhalily dřív.<br>
<br>
<br>
<br>
UI/UX pro vývojáře není o tom stát se designérem. Jde o to, abyste při psaní kódu mysleli na lidské chování. Dobrá aplikace je taková, kterou uživatel nemusí studovat. Když odstraníte tření mezi záměrem a akcí, uživatel se vrací sám a vy nemusíte řešit stížnosti na podpoře. Začněte u nejčastějšího scénáře, opravte nejkřiklavější chyby a postupně vylepšujte. Tento přístup se vám vrátí vyšší spokojeností i nižšími náklady na vývoj.<br>
<br>
<br>
<br>
Než začnete s automatizací, rozhodněte, co přesně chcete pipelinem řešit. GitHub Actions není univerzální nástroj na všechno, ale pro běžné úlohy typu build, testy a nasazení na vlastní server je velmi praktický. Základem je soubor YAML v adresáři .github/workflows, kde definujete triggery, třeba push do větve main nebo pull request. Vyhněte se ale spouštění celého pipeline při každém pushi do libovolné větve – zbytečně plýtváte minutami a zpomalujete vývoj.<br>
<br>
<br>
<br>
Další past, do které začátečníci spadají, je přeceňování kvantity. Pět mini-projektů z tutoriálů na vašem GitHubu působí dojmem, že jen opisujete cizí kód. Jeden funkční projekt, který sami navrhnete a nasadíte, má desetkrát větší váhu. Nebojte se přiznat, co nefunguje nebo co jste museli přepsat. Firmy oceňují, když vidí vaši schopnost iterovat a zlepšovat se. Právě vaše chyby a jejich oprava jsou to, co vás odliší od stovek dalších uchazečů.<br>
<br>
<br>
<br>
Další pastí je testování chybových stavů. Vždy testujte i scénář, kdy API volání selže. Vytvořte mock, který vyhodí chybu, a ověřte, že je dispatchnuta akce pro chybu. Také si dejte pozor na to, abyste nemuseli používat reálné časové prodlevy. Pokud používáte setTimeout, nahraďte ho falešnými hodinami, které test runner poskytuje. Tím se testy stanou deterministické a rychlé. Nezapomeňte také na to, že getState by mělo vracet vždy stejný stav, pokud ho v testu používáte, jinak se snadno stane, že testy začnou být náhodné.<br>
<br>
<br>
<br>
Když už máte základní testy, zamyslete se nad pokrytím okrajových případů. Typicky to jsou prázdné stavy, null hodnoty nebo neočekávané typy akcí. Reducer by měl vždy vrátit aktuální stav, pokud nezná akci. Tento případ testujte, protože mnoho implementací na to zapomíná a vrací undefined. U async akcí zkontrolujte, že dispatch není volán vícekrát, než je nutné, a že se chyby nepolykají. Všechny tyto testy nevyžadují žádné integrační prostředí, jen čistou práci s mocky a funkcí. Po napsání testů je spusťte v prostředí, které nezatěžuje prohlížeč nebo server, a máte hotovo.<br>
<br>
<br>
<br>
Začněte tím, že si oddělíte čistou logiku od vedlejších efektů. Reducer by neměl obsahovat žádné volání API, časování ani generování náhodných čísel. Pokud takovou logiku najdete v reduceru, přesuňte ji do action creatoru nebo do samostatné funkce. Tento krok je zásadní pro snadné testování, protože čisté funkce jsou předvídatelné. Typická chyba začátečníků je testovat reducer přes celý stor s middlewarem, což zbytečně zpomaluje běh testů a znesnadňuje izolaci chyb. Místo toho vytvořte reducer přímo a testujte ho jako jakoukoli jinou funkci.<br>
<br>
<br>
<br>
Jak otestovat thunk akce a vyhnout se častým chybám Pro testování async akcí, které používají thunk, potřebujete vytvořit mock pro API volání nebo jinou závislost. Můžete použít funkci, která vrací Promise, a tu pak nahradit ve vašem testu. Například předpokládejme, že akce načítá uživatele. V testu vytvoříte mock, který vyřeší data, a zavoláte thunk s parametry (dispatch, getState). Poté zkontrolujete, jaké akce byly dispatchnuty. Důležité je nezapomenout na volání done nebo použít async/await, protože thunk vrací Promise. Častým problémem je, že zapomenete na to, že thunk může mít vedlejší efekty, které ovlivňují pořadí akcí.