https://www.it-core.eu/wiki/api.php?action=feedcontributions&feedformat=atom&user=Shanon50E40 2026-09-04T18:17:55Z User contributions MediaWiki 1.44.2 https://www.it-core.eu/wiki/index.php?title=Verzov%C3%A1n%C3%AD_pro_webov%C3%A9_v%C3%BDvoj%C3%A1%C5%99e:_n%C3%A1stroje_a_p%C5%99%C3%ADstupy,_kter%C3%A9_v%C3%A1m_u%C5%A1et%C5%99%C3%AD_hodiny_pr%C3%A1ce&diff=200560 2026-08-29T05:56:15Z

<p>Shanon50E40: Created page with &quot;Další pastí je testování chybových stavů. Vždy testujte i scénář, kdy API volání selže. Vytvořte mock, který vyhodí chybu, a ověřte, že je dispatchnuta akce pro chybu. Také si dejte pozor na to, abyste nemuseli používat reálné časové prodlevy. Pokud používáte setTimeout, nahraďte ho falešnými hodinami, které test runner poskytuje. Tím se testy stanou deterministické a rychlé. Nezapomeňte také na to, že getState by mělo vracet vžd...&quot;</p> <hr /> <div>Další pastí je testování chybových stavů. Vždy testujte i scénář, kdy API volání selže. Vytvořte mock, který vyhodí chybu, a ověřte, že je dispatchnuta akce pro chybu. Také si dejte pozor na to, abyste nemuseli používat reálné časové prodlevy. Pokud používáte setTimeout, nahraďte ho falešnými hodinami, které test runner poskytuje. Tím se testy stanou deterministické a rychlé. Nezapomeňte také na to, že getState by mělo vracet vždy stejný stav, pokud ho v testu používáte, jinak se snadno stane, že testy začnou být náhodné.&lt;br&gt;&lt;br&gt;Další častou chybou je míchání více nesouvisejících změn do jednoho commitu. Například když opravíte překlep v dokumentaci a zároveň změníte logiku výpočtu ceny. Takový commit se špatně čte, špatně vrací zpět a komplikuje hledání chyb. Ideální commit mění jednu věc. Pokud potřebujete udělat dvě nesouvisející úpravy, rozdělte je do dvou commitů. I kdybyste měli poslat oba najednou, historie zůstane čistá.&lt;br&gt;&lt;br&gt;Pozor i na příliš vágní formulace. Slova jako „oprava&quot;, „úprava&quot;, „vylepšení&quot; nebo „refaktoring&quot; bez bližšího určení nenesou žádnou informaci. Místo „Refaktoring kódu&quot; napište „Odděl logiku pro výpočet slev od zpracování objednávky&quot;. Podobně se vyhněte hláškám typu „drobné úpravy&quot;, které neříkají, co bylo změněno a proč. Pokud je změna opravdu triviální, raději ji slučte s jinou smysluplnou.&lt;br&gt;&lt;br&gt;Další oblastí, kde se chybuje, je navigace mezi obrazovkami. Mnoho začátečníků plete přechody mezi view controllery s modálním zobrazením. Pro běžné přechody používejte NavigationStack (ve SwiftUI) nebo UINavigationController, a pro zobrazení detailu s možností návratu pak push. Modální prezentace je vhodná pro formuláře nebo potvrzení akcí. Při práci se SwiftUI si dejte pozor na to, že stavové proměnné by měly být private – pokud je použijete jako public, může dojít k nechtěným vedlejším efektům. Také se vyhněte přílišnému používání @ObservedObject tam, kde stačí @State nebo @Binding, abyste nezpomalovali aktualizace.&lt;br&gt;&lt;br&gt;Jak se rozhodnout podle týmu a životního cyklu projektu Pokud máte malý tým a krátký čas na dodání, REST je obvykle rychlejší a jednodušší na implementaci. Nástroje a knihovny pro REST jsou vyspělejší, dokumentace se píše snadněji a ladění je přímočařejší. GraphQL vyžaduje důkladné navržení schématu, což je investice, která se vyplatí až u větších projektů s dlouhou životností. Typická chyba: začít s GraphQL jen proto, že je „trendy&quot;, a pak zjistit, že tým neumí efektivně řešit N+1 dotazy nebo že každá změna schématu způsobí problémy s verzováním.&lt;br&gt;&lt;br&gt;Nakonec si osvojte zvyk psát zprávy s ohledem na budoucího čtenáře. Představte si, že za rok budete sami procházet historii a snažit se zjistit, proč se určitá funkce chová tak, jak se chová. Commit zprávy, které to umožní, nejsou zbytečná byrokracie, ale investice do budoucí efektivity. Dobré zprávy navíc usnadňují práci i kolegům, kteří na projektu pracují s vámi nebo po vás.&lt;br&gt;&lt;br&gt;Při návrhu API stojíte před zásadním rozhodnutím: zda použít REST, nebo GraphQL. Nejde o to, který přístup je modernější, ale který lépe sedí na váš konkrétní případ. REST je v praxi stále spolehlivou volbou pro jednoduché a dobře strukturované systémy, zatímco GraphQL přináší flexibilitu tam, kde klient potřebuje přesně to, co chce, a nic navíc. Než se rozhodnete, položte si tři otázky: Jaká je struktura vašich dat? Kdo bude API konzumovat? A jak moc se budou požadavky v čase měnit?&lt;br&gt;&lt;br&gt;Jaké informace do těla zprávy patří a jaké ne Do podrobné části patří kontext: jaký problém jste řešili, jaké alternativy jste zvažovali a proč jste vybrali právě toto řešení. Dále sem patří případné vedlejší efekty – co se může rozbít, jaké další části kódu změna ovlivňuje. Typickou chybou je opisování rozdílu v kódu. Pokud jste přidali podmínku, nepíšete „Přidal jsem if, který kontroluje věk&quot;, ale „Zabraň přístup uživatelům mladším 18 let&quot;.&lt;br&gt;&lt;br&gt;GraphQL se hodí, když máte složitá a propojená data, nebo když klienti (mobilní aplikace, frontendy) potřebují různou strukturu odpovědí. Místo mnoha URL definujete jedno schema a klient si v dotazu specifikuje, která pole chce. To eliminuje overfetching i underfetching. Typický případ: dashboard s mnoha widgety, kde každý potřebuje jinou podmnožinu dat. Bohužel, tato flexibilita má svou cenu: složitější cacheování, protože odpovědi se liší podle dotazu, a vyšší nároky na server, který musí vyhodnotit každý dotaz. Navíc se snadno dostanete do problémů s bezpečností, pokud nezavedete limity na hloubku a složitost dotazu.&lt;br&gt;&lt;br&gt;Základem je struktura zprávy. Většina projektů používá konvenci, kde první řádek nepřesahuje padesát znaků a shrnuje změnu v rozkazovacím způsobu. Například „Přidej validaci e-mailu při registraci&quot; místo „Přidána validace e-mailu&quot; nebo „Opravena chyba&quot;. Druhý řádek necháváte prázdný a od třetího řádku uvádíte podrobnosti. Toto členění není libovůle – nástroje pro správu verzí, které zobrazují historii, často zkracují první řádek na seznam změn. Pokud do něj nacpete celý příběh, nikdo ho nepřečte.</div>

Shanon50E40 https://www.it-core.eu/wiki/index.php?title=User:Shanon50E40&diff=200558 2026-08-29T05:56:10Z

<p>Shanon50E40: Created page with &quot;Někdo, kdo praktickým bydlením sází na osvědčené tipy. Píšu o tom, jak zvládnout domácnost bez stresu. Nejvíc mě baví hledat cesty, jak si usnadnit život.&quot;</p> <hr /> <div>Někdo, kdo praktickým bydlením sází na osvědčené tipy. Píšu o tom, jak zvládnout domácnost bez stresu. Nejvíc mě baví hledat cesty, jak si usnadnit život.</div>

Shanon50E40