Verzování webu: rychlý start do Git a jiných nástrojů
Dalším praktickým tipem je používat jednotný formát pro všechny odpovědi, ať už jde o úspěch nebo chybu. Pokud backend vrací data v obalu s meta informacemi, frontend si na tento vzor rychle zvykne a nemusí řešit výjimky. Tady pozor na častý nešvar – někteří vývojáři přidávají do odpovědi jen to, co zrovna potřebují, a časem se struktura rozpadne. Domluvte se na konvenci a striktně ji dodržujte. Dokumentace by měla obsahovat i příklad, jak vypadá seznam položek, prázdný výsledek nebo případ, kdy je pole null. Právě tyto okrajové stavy dělají frontendu největší problémy.<br>
<br>
<br>
<br>
Pozor si dejte na testování sítě. Mobilní aplikace se používají na špatném signálu, s přepínáním mezi Wi-Fi a mobilními daty nebo úplně offline. Simulujte tyto situace nástroji, které omezí rychlost připojení nebo ho úplně vypnou. Typický problém, který takto odhalíte, je aplikace, která po obnovení připojení zobrazí nesprávná data nebo se zacyklí.<br>
<br>
<br>
<br>
Další častou chybou je přepisování historie větví, které už někdo jiný stáhl do svého lokálního úložiště. Pokud použijete příkaz, který změní pořadí commitů nebo je sloučí do jednoho, ostatní členové týmu přestanou mít konzistentní obraz o tom, co se děje. Proto historii měňte pouze u větví, které jsou výhradně vaše, nebo u commitů, které ještě nikdo nesdílel. U sdílených větví vždy raději vytvořte nový commit, který danou změnu opraví, než abyste přepisovali minulé záznamy.<br>
<br>
<br>
<br>
Když začínáte vyvíjet webové stránky, pravděpodobně pracujete na lokálním počítači a výsledek nahráváte na hosting. Dokud pracujete sami a projekt je malý, možná si vystačíte s ručním kopírováním souborů. Jakmile ale začnete měnit více věcí najednou, přidáte druhého vývojáře, nebo potřebujete vrátit nefunkční změnu, začnete řešit, kde je stará verze souboru. To je moment, kdy se vyplatí začít s verzováním.<br>
<br>
<br>
<br>
Pozor na soubory, které by se do repozitáře dostat neměly. Patří sem konfigurace s hesly, lokální nastavení, dočasné soubory nebo složky s nainstalovanými balíčky. Pro tyto případy existuje speciální soubor, který říká, co má verzovací nástroj ignorovat. Vytvořte si ho hned na začátku a postupně ho doplňujte. Pokud už jednou nějaký soubor s citlivými údaji vložíte do historie, jeho smazání z aktuální verze nestačí – zůstane v historii a může být zneužit.<br>
<br>
<br>
<br>
Správné testování není o množství případů, ale o jejich smysluplnosti. Zaměřte se na funkce, které generují příjmy, a na ty, které jsou nejnáchylnější k chybám. A než aplikaci vydáte, projděte si ještě jednou všechny kritické cesty na reálném zařízení. Těch deset minut navíc vám ušetří stížnosti uživatelů a opravy, které by stály desetkrát víc.<br>
<br>
<br>
<br>
Nezapomínejte ani na verze API a na to, jakým způsobem se řeší zpětná kompatibilita. Frontend často běží v produkci a nemůže si dovolit, aby backend přestal podporovat staré parametry přes noc. Dokumentace by měla jasně označovat, která verze je aktuální a kdy bude starší verze ukončena. Dobrým zvykem je také popsat, jak vypadá autentizace a oprávnění – které endpointy vyžadují token, jak ho frontend získá a co se stane, když vyprší. Tyto informace bývají často roztroušené v kódu, ale pro frontend jsou zásadní.<br>
<br>
<br>
<br>
Proč je důležité zvážit budoucí uplatnění? Pokud tě láká analýza dat nebo umělá inteligence, sáhni po Pythonu. Jeho syntaxe je čitelná a má obrovskou podporu knihoven pro matematiku a statistiku. Ale pozor: Python není nejrychlejší jazyk, a pokud plánuješ vývoj mobilních aplikací, zvolíš spíš Swift pro iOS nebo Kotlin pro Android. Než se rozhodneš, projdi si nabídky práce v okolí a zjisti, co firmy skutečně hledají. Často zjistíš, že poptávka se liší podle regionu.<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
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í.