6 zásad, jak zkrotit Redux a neztratit se v akcích
Jak poznáte, že je vaše pyramida postavená na písku Prvním krokem je revize stávající sady testů. Spočítejte si poměr mezi jednotkovými a end-to-end testy v projektu. Pokud dominují E2E, začněte je přesouvat na nižší úrovně — ale ne mechanicky. Většina byznys logiky se dá ověřit na úrovni jednotkových testů, zatímco E2E si nechte jen pro hlavní uživatelské cesty, jako je přihlášení nebo dokončení objednávky. Při přesouvání se zaměřte na to, co test opravdu ověřuje: jestli kontrolujete chování jedné třídy, je to unit test; jestli spolupracuje více modulů, je to integrační test.
Nejdřív si ujasněte, co budete verzovat. Webový projekt obvykle obsahuje zdrojové kódy, šablony, styly, skripty a konfigurační soubory. Do verzování nepatří vygenerované soubory, jako jsou minifikované CSS nebo JavaScript, cache, nahrané obrázky ani lokální konfigurace s hesly. Pro tyto soubory si připravte seznam ignorovaných souborů hned na začátku. Pokud ho nevytvoříte, budete do historie ukládat balast, který znepřehlední každý diff a zpomalí práci s repozitářem.
Důležité je také neměnit stav přímo. Vždy vracejte nový objekt, ať už pomocí spread operátoru, nebo immutable knihoven. Problém nastává, když zapomenete rozšířit vnořené pole a mutujete ho. Redux Toolkit používá Immer, který vám umožní psát mutace, ale pod kapotou vytvoří nový stav. Pokud používáte čistý Redux, dávejte pozor na ruční kopie. Pravidlem je: nikdy neměňte stav, který už je v store.
Klíčová je automatizace. Nástroje pro automatické testy vám ušetří hodiny práce, ale mají háček: automatizovat byste měli jen stabilní funkce, které se často opakují. Typická chyba začátečníků je snaha automatizovat úplně všechno, včetně vizuálních změn, které se každý sprint mění. Výsledkem je pak neudržovatelný testovací kód, který se musí přepisovat častěji než samotná aplikace.
Verzování webu už dávno není volitelné. Pokud nepoužíváte systém pro správu verzí, každá větší úprava šablony, skriptu či konfigurace znamená riziko, že něco rozbijete a už to nevrátíte zpět. Začít přitom není složité, stačí se vyhnout pár základním nástrahám. Tento text vám ukáže, jak na to, a upozorní na časté chyby, které dělají i zkušení vývojáři.
Jak vypadá první commit a proč ho nedělat narychlo Než provedete první commit, inicializujte repozitář v kořenovém adresáři projektu a zkontrolujte, co se vlastně bude verzovat. Pomocí příkazu pro zobrazení stavu si projděte všechny soubory a ujistěte se, že neobsahují žádná tajemství, jako jsou přihlašovací údaje do databáze nebo API klíče. První commit by měl obsahovat kompletní funkční základ projektu, ne jen polotovar. Typická chyba začátečníků je, že commitnou celý adresář s vendor knihovnami nebo node_modules, a pak se diví, proč je repozitář obrovský a pomalý.
Když přemýšlíš o první práci vývojáře, rychle narazíš na paradox: každý chce zkušenosti, ale nikdo ti nedá šanci je získat. Místo čekání na ideální nabídku se vyplatí jednat tak, aby tvoje dovednosti byly vidět i bez životopisu plného předchozích zaměstnání. Klíčem není jen psát kód, ale přemýšlet o tom, co firmy skutečně řeší – a tím se odlišit od ostatních uchazečů.
Poslední věc, na kterou mnoho lidí zapomíná, je realistický přístup k první nabídce. Neber práci, která je úplně mimo tvou oblast, jen proto, že je dostupná. Pokud chceš dělat backend, nezačínej jako tester, když ti to neleží – můžeš se tak na roky zaseknout na pozici, která tě nenaplňuje. Na druhou stranu buď otevřený tomu, že první práce nemusí být vysněná, ale měla by ti dát prostor růst směrem, který chceš. Ptej se na to, s jakými technologiemi budeš pracovat a jak vypadá mentoring – to je důležitější než drobné rozdíly v náplni práce.
Redux přináší do Reactu předvídatelný stav, ale jeho špatné použití dokáže aplikaci spíš zkomplikovat. Místo hromady boilerplate kódu se zaměřte na to, co Redux skutečně řeší: sdílený stav napříč komponentami, který potřebuje více než jeden konzument. Pokud data používá jen jedna komponenta, nechte je v jejím lokálním stavu. Tím snížíte počet akcí a reduktorů a aplikace zůstane čitelná.
Typickou chybou začátečníků je použití NoSQL pro data, která vyžadují vztahy a transakce. Pokud ukládáte faktury a položky faktur, potřebujete zaručit, že se buď uloží celý dokument, nebo se neuloží nic. Většina NoSQL databází sice nabízí transakce, ale jejich použití je často omezené a složitější než v SQL. Než začnete modelovat, ověřte si, jak daný systém řeší atomické operace. Další pastí je špatný výběr typu databáze: dokumentová databáze není vhodná pro grafy vztahů mezi uživateli, klíč-hodnota úložiště neumí efektivně dotazovat podle více atributů. Vždy si nejprve definujte, jak budete data číst, a teprve potom vyberte konkrétní nástroj.
