https://www.it-core.eu/wiki/api.php?action=feedcontributions&feedformat=atom&user=SaundraBoote62 2026-09-03T04:31:33Z User contributions MediaWiki 1.44.2 https://www.it-core.eu/wiki/index.php?title=Kdy_v%C3%A1m_vestav%C4%9Bn%C3%A9_n%C3%A1stroje_IDE_u%C5%A1et%C5%99%C3%AD_hodiny_pr%C3%A1ce%3F&diff=200974 2026-08-29T06:14:51Z

<p>SaundraBoote62: Created page with &quot;Další častý problém je práce s globálními proměnnými. V JavaScriptu snadno vytvoříte proměnnou bez deklarace, čímž se stane globální, a to i ve funkcích. Tím se pak chyby projevují na místech, která s původním kódem nesouvisí. Vždy používejte const pro hodnoty, které se nemění, a let pro ty, které se mění. Vyhněte se var, protože jeho chování s hoistingem a function scope je častým zdrojem zmatků. Pokud vytváříte modul, uzav...&quot;</p> <hr /> <div>Další častý problém je práce s globálními proměnnými. V JavaScriptu snadno vytvoříte proměnnou bez deklarace, čímž se stane globální, a to i ve funkcích. Tím se pak chyby projevují na místech, která s původním kódem nesouvisí. Vždy používejte const pro hodnoty, které se nemění, a let pro ty, které se mění. Vyhněte se var, protože jeho chování s hoistingem a function scope je častým zdrojem zmatků. Pokud vytváříte modul, uzavřete kód do bloku nebo funkce, aby proměnné neunikly ven.&lt;br&gt;&lt;br&gt;Vyplatí se také sledovat čas běhu testů. Když se jednotkové testy zpomalí nad pár sekund, podívejte se, jestli nepoužívají zbytečné závislosti. Integrační testy by měly běžet v řádu minut, e2e maximálně v desítkách minut. Pokud váš e2e běh trvá hodiny, je to známka toho, že máte v pyramidě příliš mnoho vrstev navrchu. Postupně přesouvejte část testů dolů – nahraďte e2e test integračním tam, kde to jde. Testovací pyramida není statická, je to živý proces, který se vyvíjí s projektem.&lt;br&gt;&lt;br&gt;U jednotkových testů si dejte pozor na testování implementace místo chování. Testujte, co funkce dělá, ne to, jak to dělá. Když test začnete plnit kontrolami vnitřních stavů, každá refaktorizace kódu test rozbije, i když chování zůstává stejné. U integračních testů zase hrozí, že budete testovat samotnou databázi, což je zbytečné. Zaměřte se na to, aby test prokázal, že vaše vrstvy spolu správně komunikují, ne že databáze funguje – to už ověřil její výrobce.&lt;br&gt;&lt;br&gt;Nezapomínejte ani na komentáře – ale jen tehdy, když vysvětlují proč, ne co. Komentář typu // increment counter je zbytečný, protože to vidíte z kódu. Užitečný je komentář, který vysvětluje netriviální obchodní logiku nebo upozorňuje na známý problém. Také se vyhněte komentářům, které popisují, co by kód měl dělat, ale neodpovídají skutečnosti – takové komentáře jsou horší než žádné, protože klamou.&lt;br&gt;&lt;br&gt;Typickým prohřeškem je, že se e2e testy snaží pokrýt vše. Pak jsou pomalé, nestabilní a jejich údržba vás stojí víc času než psaní nových funkcí. Místo toho je používejte střídmě a na kritické cesty. Když e2e test selže, chcete hned vědět, co se rozbilo. Proto v nich nepoužívejte dlouhé čekací časy na náhodné prvky, ale raději explicitní počkání na konkrétní stav aplikace. A hlavně – když test začne být křehký, neopravujte ho přidáváním čekání, ale zkuste přijít na to, proč je nestabilní. Často to odhalí skutečný problém v aplikaci.&lt;br&gt;&lt;br&gt;Praktické kroky, jak pyramidu postavit v reálném projektu Nejdřív si vyhraďte čas na analýzu kritických cest. Sedněte si s týmem a napište si tři až pět nejdůležitějších uživatelských scénářů, jako je registrace, přihlášení nebo vytvoření objednávky. Tyto cesty pokryjte end-to-end testy. Vše ostatní, co je vedlejší, řešte na nižších vrstvách. Když narazíte na funkci, která potřebuje ověřit logiku, napište pro ni jednotkový test. Když potřebujete ověřit, že data správně putují mezi vrstvami, přidejte integrační test. Tím zajistíte, že každá vrstva dělá to, k čemu je určena.&lt;br&gt;&lt;br&gt;Při testování responzivity si všímejte chování při zlomových bodech. Grid s grid-template-columns bez media queries se chová plynule, ale pokud potřebujete změnit pořadí prvků (například na mobilu zobrazit sidebar pod hlavním obsahem), využijte grid-template-areas a v media query přiřaďte jiné oblasti. U Flexboxu zase ověřte, že flex-wrap: wrap funguje tak, jak očekáváte – často se stane, že prvky se zalamují neočekávaně, protože zapomenete nastavit flex-basis. Vždy definujte minimální šířku nebo základ, aby se prvky chovaly předvídatelně.&lt;br&gt;&lt;br&gt;Začněte tím, že si definujete tři vrstvy. Nejnižší jsou jednotkové testy – testují jednu funkci nebo třídu bez závislostí. Střední vrstva patří integračním testům, které ověřují spolupráci dvou nebo více komponent, třeba databáze s repozitářem. Na vrcholu jsou end-to-end testy, které procházejí celou aplikací, jakoby ji používal skutečný uživatel. Typický poměr je sedmdesát procent jednotkových, dvacet procent integračních a deset procent end-to-end. Tento poměr není dogma, ale výchozí bod, od kterého se můžete odchýlit podle svého projektu.&lt;br&gt;&lt;br&gt;Druhým praktickým nástrojem je extrakce metody nebo proměnné. Když vidíte příliš dlouhou funkci, vyberte část kódu a použijte Extract Method (Ctrl+Alt+M). IDE vytvoří novou metodu s potřebnými parametry a nahradí vybraný blok voláním. To je bezpečnější než ruční kopírování, protože se předejde chybám v počtu nebo pořadí argumentů. Podobně funguje Extract Variable, která nahradí opakovaný výraz lokální proměnnou. Při použití těchto nástrojů dejte pozor na to, aby nově vytvořené metody měly smysluplné názvy a neobsahovaly příliš mnoho parametrů.</div>

SaundraBoote62 https://www.it-core.eu/wiki/index.php?title=User:SaundraBoote62&diff=200973 2026-08-29T06:14:48Z

<p>SaundraBoote62: Created page with &quot;Autor blogu praktickým bydlením sází na osvědčené tipy. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejraději popisovat postupy krok za krokem.&quot;</p> <hr /> <div>Autor blogu praktickým bydlením sází na osvědčené tipy. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejraději popisovat postupy krok za krokem.</div>

SaundraBoote62