Když zákazník chce časový odhad, řekněte mu to takto

Co by měl každý endpoint povinně obsahovat, aby byl použitelný? Každý popis endpointu musí kromě metody a cesty obsahovat i přesné schéma požadavku a odpovědi. To znamená uvést všechny parametry, jejich typ, povinnost a příklad hodnoty. Častou chybou je psát do příkladů pouze „string" nebo „integer" bez konkrétního obsahu. Frontend pak musí hádat, jestli pole obsahuje ID, kód nebo celý objekt. Mnohem lepší je uvést realistický JSON příklad, který vychází z obvyklé odpovědi serveru. Stejně důležité je popsat i chybové stavy – nejen HTTP status, ale i strukturu chybového těla, aby frontend mohl uživateli zobrazit srozumitelné hlášení.

Pokud chcete rychle zjistit, kde uživatele ztrácíte, sledujte jednoduchou metriku: čas dokončení klíčového úkolu. Požádejte tři osoby, ať provedou hlavní scénář (např. registrace), a pozorujte, kde váhají. Často zjistíte, že problém není v kódu, ale v nejasném popisku, špatně zvoleném výchozím stavu formuláře nebo schovaném tlačítku. Oprava těchto drobností obvykle zabere hodiny, ne dny, a výsledek je okamžitě znát.

Pokud se rozhodnete Redux použít, klíčové je pochopit, že celý stav by měl být jeden velký strom. Nemusíte ale do něj dávat všechno. Data z formulářů, dočasné UI stavy nebo třeba pozice scrollu patří do lokálního stavu komponenty. Do Reduxu patří data, která potřebují i jiné komponenty bez přímé vazby, nebo která je nutné uchovat po odpojení komponenty. Typická chyba začátečníků je ukládat do Reduxu i to, co se dá vyřešit obyčejným useState, a pak sledovat, jak se aplikace zbytečně zpomaluje.

Dalším častým přešlapem je přeceňování počtu technologií v životopise. Místo seznamu „znám Java, Python, C++, JavaScript" raději uveďte dva tři jazyky a u nich konkrétní věci, které jste s nimi vytvořili. Zaměstnavatelé oceňují hloubku u jednoho ekosystému víc než povrchní přehled. Pokud jste dělali backend, napište, jakou databázi jste použili a jak jste řešili autentizaci. Každý detail, který ukazuje praktickou zkušenost, má větší váhu než kurzovné.

Prvním krokem je vytvořit jednotný popis všech endpointů na jednom místě. Nejlépe ve formátu, který může backend rovnou generovat z kódu, a frontend si ho může stáhnout do svého vývojového prostředí. Vyhněte se ručně psaným dokumentům v textových editorech – ty rychle zastarávají a nikdo je neudržuje. Místo toho používejte nástroje, které popis API generují z anotací nebo z definic datových struktur. Díky tomu bude dokumentace vždy odpovídat skutečnému stavu aplikace, což je nejdůležitější podmínka pro to, aby jí lidé věřili a používali ji.

Nakonec si pohlídejte, jak často akce odesíláte. Pokud při každém stisku klávesy posíláte akci a tím spouštíte celý Redux cyklus, aplikace může začít zadrhávat. Zvažte debouncing nebo odesílání akce až po ukončení psaní. A také myslete na to, že Redux není jediné řešení. Pokud zjistíte, že většina kódu je o tom, jak stav zkopírovat a jak ho předat dál, možná je čas přejít na jednodušší nástroj, jako je Context API nebo jinou knihovnu pro správu stavu. Redux je skvělý, ale jen tehdy, když ho používáte s rozmyslem.

Důležité je také komunikovat, co odhad neobsahuje. Pokud se projekt může rozšířit o další požadavky, řekněte to předem: „Tento termín platí pro rozsah, který jsme si odsouhlasili. Pokud přidáte nové funkce, termín se může posunout." Tím se vyhnete situaci, kdy zákazník očekává zázrak a vy musíte vysvětlovat, proč to nestíháte. Zároveň to ukazuje vaši profesionalitu a schopnost myslet dopředu.

Když už redux máte, jak se vyhnout nejčastějším chybám Největší pastí je mutování stavu přímo v reduceru. I když používáte moderní knihovny, které umí změny detekovat, nikdy nespoléhejte na to, že se něco neprojeví. Vždy vracejte nový objekt a pomocí spread operátoru nebo metod jako map, filter a reduce vytvářejte neměnné kopie. Pokud potřebujete změnit hluboko zanořenou hodnotu, rozbalte cestu k ní krok za krokem. Je to pracnější, ale předchází to záludným bugům, které se objeví až při renderování.

Nakonec se vyplatí do dokumentace přidat i praktické interaktivní prostředí, kde si frontend může zavolat API přímo z prohlížeče. Nemusí to být nic složitého – stačí možnost zadat parametry a zobrazit odpověď. Až frontend narazí na nejasnost, místo psaní e-mailu si všechno vyzkouší sám. Taková dokumentace se stává nástrojem, ne přítěží. Pokud se navíc pravidelně kontroluje a aktualizuje při každé změně kódu, spolupráce se výrazně zrychlí a počet chyb klesne na minimum. Důležité je, aby dokumentaci vnímal jako svůj úkol celý tým, nejen backend.