https://rikkiepedia.nl/api.php?action=feedcontributions&feedformat=atom&user=KarmaW223972877 2026-08-31T16:33:50Z User contributions MediaWiki 1.44.2 https://rikkiepedia.nl/index.php?title=Prvn%C3%AD_unit_test:_kde_za%C4%8D%C3%ADt_a_na_co_si_d%C3%A1t_pozor&diff=107260 2026-08-21T17:42:49Z

<p>KarmaW223972877: Created page with &quot;Pozor také na skluz k osobním výčitkám. Pokud se řeší konflikt mezi kolegy, převeďte ho do roviny procesu. Místo „Petr nedodává práci včas&quot; řekněte „Proces přiřazování úkolů neobsahuje kontrolní milníky&quot;. Tím chráníte vztahy a zaměřujete se na systém, který lze opravit. Strukturovaná zpětná vazba není o kritice lidí, ale o hledání systémových překážek. Až se to týmu podaří, retrospektiva se stane oblíbenou schůzkou, n...&quot;</p> <hr /> <div>Pozor také na skluz k osobním výčitkám. Pokud se řeší konflikt mezi kolegy, převeďte ho do roviny procesu. Místo „Petr nedodává práci včas&quot; řekněte „Proces přiřazování úkolů neobsahuje kontrolní milníky&quot;. Tím chráníte vztahy a zaměřujete se na systém, který lze opravit. Strukturovaná zpětná vazba není o kritice lidí, ale o hledání systémových překážek. Až se to týmu podaří, retrospektiva se stane oblíbenou schůzkou, na kterou se lidé těší – protože z ní odcházejí s jasnou představou, co se zlepší.&lt;br&gt;&lt;br&gt;Na závěr se vyhněte dvěma častým pastím. První je snaha napsat „dokonalý&quot; kód hned napoprvé – místo toho iterujte a postupně vylepšujte. Druhá je kopírování cizích řešení bez porozumění – vezměte si z nich jen inspiraci a napište vlastní verzi. Postupně rozšiřujte své portfolio automatizovaných úloh, ať už jde o zálohování, hromadné úpravy nebo monitorování systému. Python vás odmění tím, že rutinní práci převezme a vy budete mít čas na složitější problémy.&lt;br&gt;&lt;br&gt;Po diskusi je nezbytné vybrat maximálně dva akční kroky, které tým splní do příští retrospektivy. Každý krok musí mít jasného vlastníka, termín a ověřitelný výsledek. Bez tohoto kroku retrospektiva ztrácí smysl. Obvyklá chyba je přetížit tým deseti úkoly, které se pak nikdy neuskuteční. Lepší je zaměřit se na jednu malou změnu, která ihned přinese viditelný efekt. Zároveň si na konci vyhraďte pět minut na zhodnocení průběhu samotné retrospektivy – co se povedlo, co příště vynechat.&lt;br&gt;&lt;br&gt;Nakonec si zvykněte testy spouštět automaticky, ideálně při každém uložení nebo před odesláním změn do sdíleného repozitáře. Pokud testy běží až večer, je snadné je ignorovat. Rychlá zpětná vazba je klíčová. Nebojte se, že první testy budou pomalé nebo že jich bude málo. Každý test, který projde, vám dává jistotu. Až narazíte na chybu, kterou test odhalí, pochopíte, proč se vyplatí je psát.&lt;br&gt;&lt;br&gt;Nejčastější chyby při výběru licence Jednou z nejčastějších chyb je použití licence bez pochopení jejích podmínek. Například GPL je silný copyleft a pokud ji použijete v knihovně, může to odradit komerční vývojáře, kteří by jinak váš kód rádi využili. Naopak u API nebo malých utilit je permisivní licence často výhodnější. Dalším problémem je kombinování licencí – pokud do projektu přidáte kód pod GPL a váš hlavní kód je pod MIT, celý projekt může být ovlivněn. Vždy si ověřte kompatibilitu použitých knihoven.&lt;br&gt;&lt;br&gt;Psaní prvního unit testu často vypadá jako zbytečná komplikace. Dokud projekt roste a vše funguje, testy se odkládají na „až bude čas&quot;. Jenže ten čas nikdy nepřijde. Přitom stačí začít s jedním malým testem, který ověří chování jedné metody. Nemusíte pokrýt vše najednou. Cílem je vytvořit si návyk a postupně budovat bezpečnou síť, která vás ochrání před regresemi.&lt;br&gt;&lt;br&gt;První praktický krok je rozložit úkol na menší části. Neodhadujte celkovou dobu jako jeden blok, ale napište si seznam všech kroků, které vás napadnou. Může to vypadat takto: návrh datového modelu, implementace logiky, integrace s API, ošetření chybových stavů, testy, manuální kontrola a nasazení. Ke každému kroku si přidejte časový odhad. Uvidíte, že součet dílčích položek bude vyšší, než by byl vaše prvotní intuice – a to je přesně to, co potřebujete.&lt;br&gt;&lt;br&gt;Pro zpětnou vazbu používejte model „Situace – Dopad – Návrh&quot;. Každý bod musí obsahovat, kdy k situaci došlo, jaký měla dopad na tým a jaký konkrétní postup by situaci zlepšil. Například: „Když jsme v pondělí nasazovali novou verzi, musel jsem čekat na schválení od vedoucího, což zdrželo testování o hodinu. Navrhuji, aby schvalovací právo měl každý seniorní člen týmu.&quot; Tento formát nutí mluvit o faktech a řešeních, ne o emocích.&lt;br&gt;&lt;br&gt;Dalším typickým úkolem je zpracování textových souborů nebo tabulek. Python nabízí knihovny pro práci s daty, které zvládnou čtení, filtrování i zápis do nových souborů. Důležité je dávat pozor na kódování, zejména při práci s českými znaky – vždy specifikujte jako UTF-8, jinak riskujete chyby při čtení. Také se vyhněte pevnému kódování vstupních hodnot: pokud se cesta k souboru nebo filtr změní, měl by váš skript přijímat argumenty z příkazové řádky.&lt;br&gt;&lt;br&gt;Typická chyba začátečníků je testovat příliš mnoho v jednom testu. Jeden test by měl ověřovat jedno chování. Pokud testujete formátování data, neověřujte zároveň práci s časovými pásmy. Pokud test selže, mělo by být okamžitě jasné, která část kódu je rozbitá. Další častý problém je spoléhat se na konkrétní implementaci – test pak musíte měnit pokaždé, když upravíte vnitřek metody. Testujte rozhraní, ne to, jak metoda funguje uvnitř.</div>

KarmaW223972877 https://rikkiepedia.nl/index.php?title=User:KarmaW223972877&diff=107259 2026-08-21T17:42:48Z

<p>KarmaW223972877: Created page with &quot;Někdo, kdo dílnou i obývákem se zabývá denně. Sdílím zde, jak zvládnout domácnost bez stresu. Nejraději ukazovat chytrá řešení, která zvládne každý.&quot;</p> <hr /> <div>Někdo, kdo dílnou i obývákem se zabývá denně. Sdílím zde, jak zvládnout domácnost bez stresu. Nejraději ukazovat chytrá řešení, která zvládne každý.</div>

KarmaW223972877