https://wiki.rettungsdienstblog.eu/api.php?action=feedcontributions&feedformat=atom&user=MilagrosBustard 2026-09-30T00:15:01Z Benutzerbeiträge MediaWiki 1.37.1 https://wiki.rettungsdienstblog.eu/index.php?title=Co_se_stane,_kdy%C5%BE_zkombinujete_Grid_a_Flexbox%3F&diff=205840 2026-08-29T05:45:21Z

<p>MilagrosBustard: Die Seite wurde neu angelegt: „Nakonec si zvykněte psát testy společně s kódem, ne až po něm. Když napíšete test před implementací, jasně definujete, co funkce musí dělat. Tento přístup vám ušetří čas, protože hned vidíte, jestli váš kód splňuje požadavky. Až budete mít první testy, spouštějte je pokaždé, když změníte kód. Díky tomu hned zjistíte, jestli jste něco nerozbili, a vaše aplikace zůstane stabilní.&lt;br&gt;&lt;br&gt;Jak často začleňovat a…“</p> <hr /> <div>Nakonec si zvykněte psát testy společně s kódem, ne až po něm. Když napíšete test před implementací, jasně definujete, co funkce musí dělat. Tento přístup vám ušetří čas, protože hned vidíte, jestli váš kód splňuje požadavky. Až budete mít první testy, spouštějte je pokaždé, když změníte kód. Díky tomu hned zjistíte, jestli jste něco nerozbili, a vaše aplikace zůstane stabilní.&lt;br&gt;&lt;br&gt;Jak často začleňovat a co dělat před odesláním Ideální je začleňovat změny do hlavní větve v malých dávkách, nejlépe po každém dokončeném úkolu. Dlouho otevřená větev se vzdaluje od aktuálního stavu a sloučení pak připomíná skládání puzzle, které už dávno nepasuje. Před odesláním změn do sdílené větve si ověřte, že vaše práce neobsahuje žádné debugovací výpisy, dočasné soubory nebo nevyžádané úpravy. Mnoho týmů používá pravidlo, že každá změna musí projít kontrolou jiného člena týmu. Tento postup sice zpomaluje vývoj, ale výrazně snižuje počet chyb, které se dostanou do produkce.&lt;br&gt;&lt;br&gt;Při slučování větví dochází nejčastěji ke konfliktům v souborech, které upravuje více lidí současně. Typickým příkladem je konfigurační soubor, do kterého každý přidává svoje řádky. Abyste konfliktům předcházeli, pravidelně si do své větve přetahujte změny z hlavní větve. Tím udržíte svoji větev aktuální a sloučení nakonec proběhne rychleji. Pokud už ke konfliktu dojde, řešte jej vždy v místní kopii a před odesláním změn si projděte celý výsledek. Nikdy nespoléhejte na automatické sloučení, které může tiše přepsat důležitou logiku.&lt;br&gt;&lt;br&gt;Co se stane, když testujete jen to, co znáte Mnoho začátečníků píše testy, které pokrývají jen šťastnou cestu – vstup je platný, funkce vrátí očekávaný výsledek. Jenže chyby se skrývají v krajních případech. Přidejte testy pro prázdný řetězec, nulovou hodnotu, záporné číslo nebo velmi velké číslo. Například funkce pro výpočet slevy by měla ošetřit, co se stane, když je sleva větší než 100 %. Tím odhalíte chyby, které by jinak zůstaly skryté až do produkce.&lt;br&gt;&lt;br&gt;Když začnete stavět responzivní rozvržení, často stojíte před volbou mezi CSS Grid a Flexboxem. Mnoho začátečníků si myslí, že jsou to konkurenční technologie, ale ve skutečnosti se skvěle doplňují. Grid je ideální pro celkovou strukturu stránky – definujete řádky a sloupce, které tvoří hlavní kostru. Flexbox zase vyniká v rozmisťování prvků uvnitř těchto oblastí, zejména když potřebujete zarovnat obsah na jedné ose. Nejlepší výsledky dosáhnete, když obě metody použijete společně: Grid pro hrubou strukturu, Flexbox pro jemné detaily.&lt;br&gt;&lt;br&gt;Než začnete psát test, napište si na papír tři věci: co funkce dělá, jaké vstupy přijímá a co očekáváte, že vrátí. Tento postup odhalí nejasnosti v zadání dřív, než napíšete první řádek kódu. Pokud zjistíte, že funkce dělá pět věcí najednou, rozdělte ji na menší části. Test pak bude jednodušší a lépe odhalí, kde je chyba, když něco nefunguje.&lt;br&gt;&lt;br&gt;Nakonec si naplánujte odstávku nebo běh na ostrých datech. Migrace by měla proběhnout v čase s nejmenším provozem, a pokud možno na kopii produkčních dat. Po přepnutí provozu sledujte logy a výkon. PostgreSQL má odlišný plánovač dotazů, takže některé dotazy, které byly v MySQL rychlé, mohou být pomalejší. Vytvořte si indexy podle skutečných dotazů a využijte ANALYZE pro aktualizaci statistik. Migrace není jednorázová akce, ale proces, který si zaslouží čas a důkladné testování.&lt;br&gt;&lt;br&gt;Základním kamenem týmové spolupráce je větev, která představuje aktuální stav aplikace. Do ní by měly putovat pouze dokončené a otestované změny. Pokud do ní posíláte každý rozpracovaný detail, ostatní nemají šanci poznat, co je hotové a co je jen experiment. Mnohem lepší je vytvořit si vlastní větev z aktuálního stavu hlavní větve a pracovat v ní. Tím získáte izolovaný prostor, kde můžete dělat chyby, aniž byste ohrozili práci ostatních. Po dokončení změny pak větev sloučíte a hlavní větev zůstane čistá.&lt;br&gt;&lt;br&gt;Typickým chybou je měřit pokrytí na projektu, který má hodně uživatelského rozhraní a málo jednotkových testů. Testy UI jsou pomalé a křehké, a pokud se je snažíte pokrýt měřením, zjistíte, že čísla jsou nízká, ale práce s nimi je neúměrně náročná. V takovém případě je lepší se zaměřit na kritické algoritmy a logiku, a UI testy nechat být, nebo je alespoň nesledovat v rámci stejné metriky. Stejně tak nemá smysl měřit pokrytí u prototypů a jednorázových skriptů, které se zahodí.&lt;br&gt;&lt;br&gt;Kdy měření pomáhá a kdy škodí? Měření pokrytí má smysl zejména v kritických částech kódu, jako je zpracování plateb, bezpečnostní logika nebo algoritmy, kde může být chyba drahá. Pomáhá také při refaktoringu – pokud změníte kód, pokrytí vám ukáže, zda jste nezapomněli na nějakou větev. Stejně tak je užitečné při přidávání nové funkcionality do staršího kódu, kdy chcete mít jistotu, že jste nezpůsobili regresi.</div>

MilagrosBustard https://wiki.rettungsdienstblog.eu/index.php?title=Benutzer:MilagrosBustard&diff=205839 2026-08-29T05:45:17Z

<p>MilagrosBustard: Die Seite wurde neu angelegt: „Váš průvodce světem interiérů se zabývá denně. Píšu o tom, jak zvládnout domácnost bez stresu. Nejraději hledat cesty, jak si usnadnit život.“</p> <hr /> <div>Váš průvodce světem interiérů se zabývá denně. Píšu o tom, jak zvládnout domácnost bez stresu. Nejraději hledat cesty, jak si usnadnit život.</div>

MilagrosBustard