Verzování webu: Průvodce pro začínající kodéry: Unterschied zwischen den Versionen

Aus MeinWiki
Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „Druhý častý problém je ignorování dotazovacích vzorů. NoSQL databáze nejsou univerzální – každý typ má specifické možnosti dotazování. Než…“)
 
K
 
Zeile 1: Zeile 1:
−
Druhý častý problém je ignorování dotazovacích vzorů. NoSQL databáze nejsou univerzální – každý typ má specifické možnosti dotazování. Než nasadíte, zkuste si napsat pět nejčastějších dotazů, které vaše aplikace bude spouštět. Pokud zjistíte, že potřebujete fulltextové vyhledávání nebo složité agregace, možná je lepší zůstat u relační databáze nebo zkombinovat obojí (tzv. polyglot persistence). Také si rozmyslete, jak budete data mazat – některé NoSQL databáze nemají efektivní operaci pro smazání velkého rozsahu dat.<br><br>Stavba REST API v Node.js s frameworkem Express patří mezi základní dovednosti backendového vývojáře. Express je minimalistický, ale dostatečně flexibilní nástroj, který vám umožní rychle vytvořit funkční rozhraní. Než začnete, ujistěte se, že máte nainstalovaný Node.js a že rozumíte základům JavaScriptu, jako jsou async/await a práce s objekty. Celý postup je vhodné rozdělit do menších kroků, abyste se vyhnuli chaotickému kódu a usnadnili si budoucí údržbu.<br><br>Na závěr si osvojte testování API pomocí nástrojů jako Postman nebo přímo v rámci integračních testů. Pravidelně kontrolujte, jak vaše API reaguje na neexistující cesty, neplatná data nebo příliš velké požadavky. Express sice zvládá základní limity, ale pro produkci byste měli přidat kompresi a ochranu proti DoS útokům. A pamatujte – kvalitní REST API není jen o tom, aby fungovalo, ale aby bylo robustní, konzistentní a snadno použitelné pro ostatní vývojáře.<br><br>Nejprve si otevřete vývojové prostředí. Doporučuji použít Visual Studio Community nebo Visual Studio Code, obojí je zdarma. Po spuštění vytvořte nový projekt typu „Konzolová aplikace" (Console App) pro jazyk C#. Jméno projektu zvolte bez diakritiky, třeba „PrvniAplikace". Po vytvoření uvidíte soubor Program.cs s předpřipraveným kódem. Smažte vše, co tam je, a napište následující kód: Console.WriteLine("Ahoj, světe!"); a stiskněte F5. Program se spustí a v okně se zobrazí text. Tím máte za sebou první funkční aplikaci.<br><br>Nakonec si osvojte práci s vysvětlením plánu dotazu (EXPLAIN). Tento nástroj vám ukáže, jak databáze dotaz zpracovává, které indexy používá a kde dochází k sekvenčnímu procházení. Než optimalizujete, vždy se podívejte na tento výstup. Často zjistíte, že problém není v dotazu, ale v chybějícím indexu, který se tváří jako existující, ale ve skutečnosti se nepoužívá.<br><br>Routování a zpracování požadavků Express používá pro definici koncových bodů metody jako app.get(), app.post(), app.put() a app.delete(). Každá z nich přijímá cestu a callback funkci, která má přístup k objektům req a res. Při psaní rout je důležité používat parametry cest, třeba /users/:id, a validovat je ještě před samotným zpracováním. Typickou chybou je zapomenout na asynchronní zpracování – pokud vaše handler funkce nepoužívá async/await, může dojít k neošetřeným rejectovaným promisům, které aplikaci spadnou. Vždy proto obalujte asynchronní operace do try/catch bloků.<br><br>Další praktickou záležitostí je správa stavových kódů HTTP. Vracejte 200 pro úspěšné GET požadavky, 201 pro vytvoření nového zdroje, 204 pro úspěšné smazání a 400 nebo 404 pro chybové situace. Nepoužívejte univerzální 500 pro vše, co se nepovede. Konkrétní kódy pomáhají klientům rychleji diagnostikovat problém. Rovněž se vyhněte vracení surových chybových hlášení z databáze – vytvořte si jednoduchý middleware, který zachytí výjimky a převede je na JSON s přátelským popisem.<br><br>Další důležitou dovedností je umět se vrátit k předchozímu stavu. Pokud jste provedli commit a zjistíte, že je něco špatně, můžete se pomocí historie podívat na jednotlivé commity a vybrat ten, ke kterému se chcete vrátit. Pozor ale na to, že pokud jste provedli další změny a ty nejsou commitnuté, mohou se dostat do konfliktu. Vždy si proto před návratem uložte nebo zahoďte aktuální rozpracovanou práci. Dobré je také vědět, že commit nemusí být trvalý – můžete jej upravit, sloučit s jiným, nebo úplně odstranit, dokud nedojde k publikaci.<br><br>Nejjednodušší a pro menší týmy nejpraktičtější je model trunk-based development. Všechny změny směřují do hlavní větve, ale každá funkce nebo oprava dostane vlastní krátkodobou větev. Pravidlo zní: jedna větev = jeden úkol. Větve pojmenovávejte podle čísla úkolu nebo srozumitelného popisu, například feature/login-form nebo fix/empty-state. Hlavní větev zůstává vždy stabilní a připravená k nasazení.<br><br>Až je práce hotová, nemažte staré větve hned po sloučení. Nechte je ještě pár dní, ale označte je jako uzavřené. Pokud se objeví chyba, můžete se k nim vrátit. Když si tým zvykne na tato pravidla, ušetříte hodiny času, které by jinak padly na řešení konfliktů a na dohady, kdo co měl udělat jinak. Pravidelná revize workflow po každém větším projektu pomůže odhalit slabá místa a upravit proces podle aktuálních potřeb.
+
Typická chyba, kterou v praxi vidím, je snaha pokrýt end-to-end testy úplně všechno. Pak se stane, že jeden test trvá dvě minuty a celá sada půl hodiny. Vývojáři čekají na výsledek, ztrácí kontext a testy se stávají spíše brzdou než pojistkou. Řešení je jednoduché: použijte pravidlo 80/15/5 – 80 % jednotkových, 15 % integračních a 5 % end-to-end testů. Většinu funkcionality totiž ověříte rychlými a spolehlivými testy na nižších vrstvách, a pomalé testy si necháte jen na nejdůležitější scénáře.<br><br>Začněte u jednotkových testů. Ty by měly pokrývat všechny klíčové výpočty, validace a rozhodovací logiku. Píšete je ve stejném jazyce jako aplikaci, nejlépe přímo u třídy nebo funkce. Snažte se, aby každý test ověřoval jednu konkrétní věc a nezávisel na databázi, souborech ani síti. Typická chyba je testovat přes HTTP endpoint, když stačí zavolat metodu přímo. Tím testy zpomalíte a znejistíte – pak vám stačí, že se změní jeden JSON klíč, a spadne vám deset testů, které přitom ověřují úplně jinou logiku.<br><br>Jakmile máte repozitář připravený, začněte s tzv. commitováním. Každý commit je snímek vašeho kódu v určitém čase. Než provedete commit, musíte změny nejdříve označit. K tomu slouží příkaz, který přidá soubory do tzv. staging area. Teprve poté můžete vytvořit commit s výstižnou zprávou. Vyhněte se obecným popiskům jako „oprava chyby" nebo „update". Místo toho pište konkrétně: „Oprava responzivního menu na mobilu" nebo „Přidání formuláře do sekce kontakty". Taková zpráva vám za měsíc řekne přesně, co se změnilo, a usnadní orientaci v historii.<br><br>Pokud si netroufáte na kód, začněte s dokumentací. Přidávání příkladů, opravování překlepů nebo doplnění chybějících sekcí je stejně hodnotné jako oprava bugů. Zkuste si nasadit projekt lokálně a projít dokumentaci krok za krokem – určitě narazíte na místa, která nejsou jasná. Takové poznatky pak můžete přetavit v konkrétní návrh na zlepšení. U dokumentace je důležité držet se stručnosti a přesnosti, vyhýbat se zbytečnému balastu.<br><br>Jakmile je jednotková vrstva pevná, přejděte na integrační testy. Ty ověřují, že vaše komponenty spolupracují správně – typicky s databází, externími službami nebo frontendem. Zde platí pravidlo: testujte jen to, co jednotkově nejde pokrýt. Například mapování ORM, SQL dotazy nebo synchronizaci mezi moduly. U integračních testů si dejte pozor na stav prostředí. Vždy používejte izolovanou testovací databázi a po každém běhu ji vracejte do původního stavu. Jinak se vám testy navzájem ovlivňují a vy strávíte hodiny hledáním chyby, která je jen artefaktem pořadí testů.<br><br>Základem je pochopit rozdíl mezi kolekcí a prostředím (environment). Kolekce slouží k seskupení souvisejících požadavků, zatímco prostředí uchovává proměnné, jako jsou adresy serverů, přihlašovací tokeny nebo identifikátory. Vytvořte si alespoň dvě prostředí – jedno pro testovací a druhé pro produkční prostředí. Díky tomu přepnete mezi nimi jedním kliknutím, aniž byste museli ručně měnit každou adresu. Pro proměnné používejte klíče ve formátu promenna, které Postman automaticky dosadí do URL, hlaviček i těla požadavku.<br><br>Před odesláním pull requestu si ověřte, že váš kód prochází všemi testy. Pokud projekt žádné testy nemá, zkuste alespoň spustit sestavení. Typickou chybou je poslat změny, které fungují jen u vás, ale rozbijí něco jiného. Po odeslání pull requestu se může stát, že vám správci napíšou připomínky. Nebuďte z toho frustrovaní – je to běžná součást spolupráce. Reagujte na komentáře věcně, vysvětlujte své rozhodnutí a případně upravte kód.<br><br>Praktické tipy pro každodenní práci Častým nešvarem začátečníků je verzovat až po dokončení celé funkce. Tím ale ztrácíte možnost vrátit se k dílčím krokům. Ideální je commitovat po každé logické části – třeba po úpravě hlavičky, po přidání nové sekce nebo po vyřešení bugu. Pokud pracujete na větší změně, využijte větve. Větev je kopie vašeho kódu, ve které můžete experimentovat, aniž byste ovlivnili hlavní verzi. Když je vše hotové, větev sloučíte zpět. Tento postup oceníte zejména při práci v týmu, ale i sólově vám ušetří spoustu starostí.<br><br>Praktické tipy pro psaní testů a automatizaci Postman nejen odesílá požadavky, ale umožňuje i psát automatizované testy v JavaScriptu. Po odeslání požadavku přejděte na kartu „Tests" a přidejte ověření, že odpověď má očekávaný stavový kód, obsahuje správnou strukturu JSON nebo že hodnota v odpovědi odpovídá zadané. Typickým příkladem je kontrola, že pm.response.to.have.status(200) nebo že pole data je pole a není prázdné. Tyto testy se ukládají do kolekce a lze je spouštět hromadně pomocí Collection Runneru, což je zásadní pro regresní testy.

Aktuelle Version vom 21. August 2026, 20:00 Uhr

Typická chyba, kterou v praxi vidím, je snaha pokrýt end-to-end testy úplně všechno. Pak se stane, že jeden test trvá dvě minuty a celá sada půl hodiny. Vývojáři čekají na výsledek, ztrácí kontext a testy se stávají spíše brzdou než pojistkou. Řešení je jednoduché: použijte pravidlo 80/15/5 – 80 % jednotkových, 15 % integračních a 5 % end-to-end testů. Většinu funkcionality totiž ověříte rychlými a spolehlivými testy na nižších vrstvách, a pomalé testy si necháte jen na nejdůležitější scénáře.

Začněte u jednotkových testů. Ty by měly pokrývat všechny klíčové výpočty, validace a rozhodovací logiku. Píšete je ve stejném jazyce jako aplikaci, nejlépe přímo u třídy nebo funkce. Snažte se, aby každý test ověřoval jednu konkrétní věc a nezávisel na databázi, souborech ani síti. Typická chyba je testovat přes HTTP endpoint, když stačí zavolat metodu přímo. Tím testy zpomalíte a znejistíte – pak vám stačí, že se změní jeden JSON klíč, a spadne vám deset testů, které přitom ověřují úplně jinou logiku.

Jakmile máte repozitář připravený, začněte s tzv. commitováním. Každý commit je snímek vašeho kódu v určitém čase. Než provedete commit, musíte změny nejdříve označit. K tomu slouží příkaz, který přidá soubory do tzv. staging area. Teprve poté můžete vytvořit commit s výstižnou zprávou. Vyhněte se obecným popiskům jako „oprava chyby" nebo „update". Místo toho pište konkrétně: „Oprava responzivního menu na mobilu" nebo „Přidání formuláře do sekce kontakty". Taková zpráva vám za měsíc řekne přesně, co se změnilo, a usnadní orientaci v historii.

Pokud si netroufáte na kód, začněte s dokumentací. Přidávání příkladů, opravování překlepů nebo doplnění chybějících sekcí je stejně hodnotné jako oprava bugů. Zkuste si nasadit projekt lokálně a projít dokumentaci krok za krokem – určitě narazíte na místa, která nejsou jasná. Takové poznatky pak můžete přetavit v konkrétní návrh na zlepšení. U dokumentace je důležité držet se stručnosti a přesnosti, vyhýbat se zbytečnému balastu.

Jakmile je jednotková vrstva pevná, přejděte na integrační testy. Ty ověřují, že vaše komponenty spolupracují správně – typicky s databází, externími službami nebo frontendem. Zde platí pravidlo: testujte jen to, co jednotkově nejde pokrýt. Například mapování ORM, SQL dotazy nebo synchronizaci mezi moduly. U integračních testů si dejte pozor na stav prostředí. Vždy používejte izolovanou testovací databázi a po každém běhu ji vracejte do původního stavu. Jinak se vám testy navzájem ovlivňují a vy strávíte hodiny hledáním chyby, která je jen artefaktem pořadí testů.

Základem je pochopit rozdíl mezi kolekcí a prostředím (environment). Kolekce slouží k seskupení souvisejících požadavků, zatímco prostředí uchovává proměnné, jako jsou adresy serverů, přihlašovací tokeny nebo identifikátory. Vytvořte si alespoň dvě prostředí – jedno pro testovací a druhé pro produkční prostředí. Díky tomu přepnete mezi nimi jedním kliknutím, aniž byste museli ručně měnit každou adresu. Pro proměnné používejte klíče ve formátu promenna, které Postman automaticky dosadí do URL, hlaviček i těla požadavku.

Před odesláním pull requestu si ověřte, že váš kód prochází všemi testy. Pokud projekt žádné testy nemá, zkuste alespoň spustit sestavení. Typickou chybou je poslat změny, které fungují jen u vás, ale rozbijí něco jiného. Po odeslání pull requestu se může stát, že vám správci napíšou připomínky. Nebuďte z toho frustrovaní – je to běžná součást spolupráce. Reagujte na komentáře věcně, vysvětlujte své rozhodnutí a případně upravte kód.

Praktické tipy pro každodenní práci Častým nešvarem začátečníků je verzovat až po dokončení celé funkce. Tím ale ztrácíte možnost vrátit se k dílčím krokům. Ideální je commitovat po každé logické části – třeba po úpravě hlavičky, po přidání nové sekce nebo po vyřešení bugu. Pokud pracujete na větší změně, využijte větve. Větev je kopie vašeho kódu, ve které můžete experimentovat, aniž byste ovlivnili hlavní verzi. Když je vše hotové, větev sloučíte zpět. Tento postup oceníte zejména při práci v týmu, ale i sólově vám ušetří spoustu starostí.

Praktické tipy pro psaní testů a automatizaci Postman nejen odesílá požadavky, ale umožňuje i psát automatizované testy v JavaScriptu. Po odeslání požadavku přejděte na kartu „Tests" a přidejte ověření, že odpověď má očekávaný stavový kód, obsahuje správnou strukturu JSON nebo že hodnota v odpovědi odpovídá zadané. Typickým příkladem je kontrola, že pm.response.to.have.status(200) nebo že pole data je pole a není prázdné. Tyto testy se ukládají do kolekce a lze je spouštět hromadně pomocí Collection Runneru, což je zásadní pro regresní testy.

Abgerufen von „http://wiki.pannier-schulungen.de/index.php?title=Verzování_webu:_Průvodce_pro_začínající_kodéry&oldid=114259“