Bez dobré dokumentace API se frontend a backend navzájem zablokují

Z Mazovia
Wersja z dnia 20:46, 11 paź 2026 autorstwa CarlotaSauceda0 (dyskusja | edycje) (Utworzono nową stronę "Poslední věc, která rozhoduje o tom, jestli vám nástroje ušetří čas, je konzistence. Když si zkratky nastavíte jednou a budete je používat každý den, přestanete nad refaktoringem přemýšlet a začnete ho dělat průběžně. Průběžné malé úpravy bolí méně než jednorázové velké čištění. Začněte dnes třemi zkratkami a do týdne poznáte rozdíl v tom, kolik času vám zbývá na skutečnou práci.<br><br>Po nástupu se soustřeď…")
(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)

Poslední věc, která rozhoduje o tom, jestli vám nástroje ušetří čas, je konzistence. Když si zkratky nastavíte jednou a budete je používat každý den, přestanete nad refaktoringem přemýšlet a začnete ho dělat průběžně. Průběžné malé úpravy bolí méně než jednorázové velké čištění. Začněte dnes třemi zkratkami a do týdne poznáte rozdíl v tom, kolik času vám zbývá na skutečnou práci.

Po nástupu se soustřeď na čtení cizího kódu, ne na psaní vlastního. První dva týdny se ptej, ale vždy po vlastním pokusu. Nauč se používat ladicí nástroje a číst chybové zprávy do konce. Nenechávej si úkol bez odhadu času a bez průběžné kontroly. Největší chyba juniora je mlčet, když narazí, a předstírat práci až do posledního dne. Malý dotaz včas je vždy levnější než odevzdání ve skluzu.

Nejprve zjistěte, koho chyba skutečně zasahuje. Jinak vypadá situace, kdy selhává platba nebo přihlášení, a jinak kosmetická vada v málo používané obrazovce. Sepište, kolik lidí to potkalo, zda jde o ztrátu dat, nebo jen o nepohodlí, a jestli existuje rozumný způsob, jak se tomu vyhnout. Teprve potom rozhodujte o tempu. Bez tohoto kroku se opravy hromadí podle toho, kdo si nejhlasitěji stěžuje, ne podle skutečné škody.

Nejčastější důvod, proč se spolupráce frontendu a backendu zadrhne, není technický dluh ani špatná architektura. Je to dokumentace, která buď chybí, nebo popisuje něco jiného, než API skutečně dělá. Výsledkem jsou dohady v chatu, zbytečné přepisování kódu a zpoždění, které nikdo neplánoval. Dokumentace přitom není administrativa navíc – je to nástroj, který určuje, kdo co může dělat a kdy.

Při testování sledujte, jak se limit chová při souběžných požadavcích. Typická chyba je testovat pouze jeden požadavek za sekundu a pak být překvapen, že ostrý provoz dostává 429. Použijte nástroj, který umí poslat stovky požadavků najednou, a ověřte, že se počítadla správně resetují. Do odpovědi přidejte hlavičku Retry-After, aby klient věděl, kdy může zkusit znovu. Pokud omezujete podle IP, pamatujte, že za proxy musíte nastavit trust proxy, jinak všechny požadavky vypadají jako z jedné adresy.

Selektory a normalizace d