https://wiki.rettungsdienstblog.eu/api.php?action=feedcontributions&feedformat=atom&user=CaryThigpen5 2026-09-23T17:23:31Z Benutzerbeiträge MediaWiki 1.37.1 https://wiki.rettungsdienstblog.eu/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=204780 2026-08-29T05:05:57Z

<p>CaryThigpen5: Die Seite wurde neu angelegt: „Pozor na běžné nástrahy. První z nich je psát zprávy v minulém čase – commit zpráva popisuje, co jste udělali, ale lépe působí rozkazovací způsob: „Přidej ošetření prázdného vstupu&quot; místo „Přidal jsem ošetření&quot;. Druhým častým problémem je míchání více nesouvisejících změn do jednoho commitu. Pokud opravujete bug a zároveň přejmenováváte proměnnou, měly by to být dva commity. Jinak se v historii ztrácít…“</p> <hr /> <div>Pozor na běžné nástrahy. První z nich je psát zprávy v minulém čase – commit zpráva popisuje, co jste udělali, ale lépe působí rozkazovací způsob: „Přidej ošetření prázdného vstupu&quot; místo „Přidal jsem ošetření&quot;. Druhým častým problémem je míchání více nesouvisejících změn do jednoho commitu. Pokud opravujete bug a zároveň přejmenováváte proměnnou, měly by to být dva commity. Jinak se v historii ztrácíte a nelze bezpečně vrátit jen jednu změnu.&lt;br&gt;&lt;br&gt;Jak strukturovat zprávu, aby byla čitelná i za rok Dobrá zpráva má dva oddíly: předmět a tělo. Předmět je věta, která shrnuje podstatu. Tělo pak rozvádí důvody, případně souvislosti – co bylo předtím, co teď a proč. Typickou chybou je psát jen předmět a tělo vynechat. Pokud je změna netriviální, tělo je nezbytné. Použijte třeba odrážky pro výčet důsledků, ale držte se věcného tónu. Vyhněte se emocím a obecným frázím – místo „zlepšeno&quot; napište konkrétně „snížena spotřeba paměti o 15 % díky cachování výsledků dotazu&quot;.&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;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;Když se rozhodneš začít s vývojem pro Android, první věc, kterou uděláš, je výběr vývojového prostředí. Nemusíš hned instalovat vše, co existuje. Stačí ti oficiální nástroj od Googlu, který obsahuje editor, emulátor i potřebné knihovny. Stáhneš si ho, nainstaluješ a vytvoříš nový projekt. Nezapomeň si zkontrolovat verzi Java Development Kitu, protože bez něj projekt ani nespustíš. Po prvním spuštění se ti ukáže předpřipravená šablona – nech ji tak, jak je, a projdi si strukturu složek.&lt;br&gt;&lt;br&gt;Jak sdělit odhad, aby zákazník pochopil riziko, ne jen termín Klíčové je přesunout pozornost od konkrétního data k povaze práce. Když předáváte odhad, rozdělte projekt na menší etapy a ke každé přiřaďte realistickou dobu trvání. U každé etapy rovnou řekněte, co by ji mohlo zpozdit – chybějící informace, dodatečné požadavky, čekání na schválení. Takový rozpad má dva efekty: zákazník vidí, že odhad není náhodné číslo z hlavy, a zároveň si uvědomí, kde může sám přispět k tomu, aby se věci neprotahovaly. Pokud si vyhradíte týden na kontrolní schůzky, řekněte to. Když to neřeknete, bude předpokládat, že všech čtrnáct dní je čistá práce.&lt;br&gt;&lt;br&gt;Třetí chybou je psát zprávy typu „WIP&quot; nebo „temp&quot;. Takové commity signalizují, že nevíte, co děláte, a připravují past pro budoucí hledání. Pokud potřebujete uložit rozpracovanou práci, použijte větvičku nebo stash, ale nikdy nezasílejte do sdílené historie commit bez smyslu. A pokud už takový commit omylem vytvoříte, opravte ho před push do sdílené větve – ideálně pomocí interaktivního rebase, ale to je téma na samostatný článek.&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;Psát commit zprávy je rutina, kterou většina vývojářů odbývá. Přitom právě ony rozhodují o tom, jak rychle se v historii projektu zorientujete vy i vaši kolegové. Špatně napsaná zpráva typu „oprava&quot; nebo „update&quot; je k ničemu, když se za tři měsíce snažíte zjistit, proč se změnilo chování nějaké funkce. Smysluplná commit zpráva není formalita, ale nástroj, který šetří hodiny hledání v logu.</div>

CaryThigpen5 https://wiki.rettungsdienstblog.eu/index.php?title=Benutzer:CaryThigpen5&diff=204779 2026-08-29T05:05:55Z

<p>CaryThigpen5: Die Seite wurde neu angelegt: „Váš průvodce dílnou i obývákem sází na osvědčené tipy. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejvíc mě baví popisovat postupy krok za krokem.“</p> <hr /> <div>Váš průvodce dílnou i obývákem sází na osvědčené tipy. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejvíc mě baví popisovat postupy krok za krokem.</div>

CaryThigpen5