Proč vaše rozhraní mate i zkušené uživatele - Revision history

172.69.194.110 at 01:47, 2 October 2026

2026-10-02T01:47:43Z

← Older revision		Revision as of 01:47, 2 October 2026
Line 1:		Line 1:
	~~Práce ve větvi je bezpečná jen tehdy, když víš, kde jsi. git branch vypíše větve, git switch -c nova-vetev vytvoří a přepne. Častá chyba: upravovat soubory~~, ~~pak přepnout větev a divit~~ se, ~~že změny „zmizely"~~. ~~Git~~ je ~~nemaže~~, ~~jen je nechá v pracovním adresáři a přepnutí buď zablokuje~~, ~~nebo je přenese jinam~~. ~~Před přepnutím buď změny commitni~~, ~~nebo je odlož pomocí git stash~~. ~~Sloučení (git merge) přináší konflikty — nejsou porucha, jsou normální stav~~. ~~Otevři označené soubory~~, ~~vyber správnou verzi~~, ~~odstraň značky >>>>>>, pak soubor přidej~~ a ~~commit dokonči~~.<br><br>~~Typické chyby se opakují.~~ Testovací ~~data se zapisují natvrdo do kódu~~, ~~takže testy padají při změně prostředí~~. ~~Testy závisí na sobě navzájem~~ a ~~jejich pořadí rozhoduje o výsledku~~. ~~Čekání se řeší pevnými prodlevami místo čekání na konkrétní stav~~, ~~což vede k náhodným selháním~~. ~~Automatizované testy~~ se ~~spouštějí jen na emulátoru~~ a ~~nikdy na skutečném zařízení. A často chybí testy pro obnovení stavu po přerušení – třeba když uživatel přijme hovor uprostřed nahrávání~~.<br><br>~~Nakonec platí~~, ~~že sjednocení není jednorázový úkol, ale dohoda, kterou je potřeba udržovat~~. ~~Vyberte variantu, která odpovídá velikosti týmu~~ a ~~počtu projektů~~, a ~~nechte si prostor pro změnu~~, ~~až se podmínky vyvinou~~. ~~Jednotná konfigurace má smysl jen tehdy~~, když ~~zjednodušuje každodenní práci~~, ~~ne když přidává další vrstvu~~, ~~kterou je třeba hlídat~~.<br><br>~~Prvním krokem~~ je ~~rozdělit~~ testy ~~podle toho~~, ~~co skutečně ověřují~~, ~~ne podle názvu složky~~. ~~Jednotkový test volá jednu funkci~~ nebo ~~třídu, nepoužívá databázi, síť ani souborový systém a běží v milisekundách~~. ~~Integrační test naopak ověřuje spolupráci dvou~~ a ~~více komponent včetně reálného úložiště nebo HTTP vrstvy~~. ~~Pokud~~ test ~~potřebuje nastartovat aplikaci~~, ~~není to jednotkový test~~, ~~i když~~ je ~~v souboru s názvem unit~~.<br><br>~~Vývojář obvykle řeší~~, ~~jestli kód funguje~~. ~~Uživatel řeší~~, ~~jestli chápe~~, co ~~má udělat. Mezi tím vzniká propast~~, ~~do které padá většina jinak technicky správných aplikací. UI~~ a ~~UX nejde dodatečně „přilepit"~~ na ~~hotový produkt~~. ~~Rozhodnutí~~ o ~~rozložení~~, ~~hierarchii~~ a ~~zpětné vazbě se dělají průběžně, nejlépe ještě před psaním první komponenty~~.<br><br>~~Praktický postup~~ je ~~postupný. Vyberte jednu oblast, například formátování kódu,~~ a ~~sjednoťte ji jako první~~. ~~Zaveďte ji~~ tak, ~~aby fungovala i bez ručního zásahu,~~ a ~~teprve po ověření přidejte další~~. ~~U každé změny si předem řekněte~~, ~~jak poznáte~~, ~~že funguje: sníží se počet konfliktů při slučování~~, ~~zmizí opakované opravy stejné chyby~~, ~~nový člen týmu spustí projekt bez dodatečného vysvětlování. Bez těchto měřítek se sjednocení zvrhne v debatu o preferencích~~.<br><br>~~Základní volba stojí mezi jedním sdíleným repozitářem a více repozitáři s centrální konfigurací~~. ~~Sdílený repozitář znamená~~, ~~že všechny části projektu leží pohromadě~~ a ~~konfigurační soubory~~ jsou ~~na jednom místě. Výhodou je okamžitá viditelnost změn~~ a ~~jednodušší zavádění nových členů týmu~~. ~~Nevýhodou~~ je ~~horší izolace: změna~~ v ~~jedné části může nechtěně ovlivnit jinou a nástroje musejí zvládat větší objem dat~~. ~~U více repozitářů je potřeba vyřešit, odkud se konfigurace bere a jak se synchronizuje~~.<br><br>~~Formuláře jsou místo, kde se ztrácí nejvíc konverzí~~. ~~Každé pole navíc snižuje ochotu dokončit akci. Ptejte se jen na to~~, ~~co skutečně potřebujete~~, a ~~zbytek zjistěte později~~. ~~Popisky patří nad pole~~, ~~ne dovnitř jako placeholder~~, ~~protože ten po napsání zmizí a uživatel zapomene~~, ~~co vyplňuje~~. ~~Validujte při odchodu z pole~~, ne ~~při každém stisku klávesy~~. ~~Chybová zpráva má~~ být u ~~konkrétního pole~~ a ~~konkrétní~~, ~~ne souhrnná dole pod formulářem~~.<br><br>~~Sjednocení konfigurace projektu pro tým není otázkou jediného nástroje~~. ~~Jde o rozhodnutí~~, kde ~~bude konfigurace žít~~, ~~kdo ji bude měnit a jak~~ se ~~změny dostanou ke všem~~. ~~Nejčastější chybou je začít výběrem technologie dřív~~, ~~než je jasné~~, ~~jaké problémy má sjednocení řešit. Sepište si~~, ~~co dnes~~ dělá ~~potíže: rozdílné verze závislostí~~, ~~odlišné formátování~~, ~~ruční nastavování prostředí, nebo kombinace všeho. Teprve pak má smysl porovnávat varianty~~.<br><br>~~Mezi časté chyby patří zavádění příliš mnoha pravidel najednou~~, ~~ponechání starých konfigurací naživu~~ a ~~chybějící dohoda o tom~~, ~~kdo změny schvaluje~~. ~~Pokud se konfigurace mění bez kontroly~~, ~~začne se dřív~~ nebo ~~později rozcházet s realitou. Pomáhá i to~~, ~~když~~ je ~~konfigurace součástí projektu a ne skrytá v nastavení jednotlivých strojů~~. ~~Když ji někdo potřebuje upravit, musí~~ být ~~jasné~~, kam sáhnout a koho se zeptat.<br><br>Kdy se vyplatí centrální konfigurace a kdy ne Centrální konfigurace dává smysl ve chvíli, kdy tým pravidelně řeší stejné nastavení: pravidla pro formátování, kontrolu typů, testovací skripty nebo nastavení editoru. Tyto věci patří do jednoho místa, odkud si je každý projekt vezme. ~~Naopak věci specifické pro konkrétní službu,~~ jako ~~jsou cesty k datům nebo parametry nasazení, mají zůstat lokálně. Pokud se snažíte centralizovat~~ i ~~něco, co se v každém projektu liší, vznikne z konfigurace nečitelný soubor plný výjimek~~. ~~To je typický důvod~~, ~~proč~~ se ~~sjednocení po čase rozpadne~~.		Než nainstaluješ cokoli dalšího, rozhodni se, na čem budeš pracovat. Pro Android je oficiální cestou Android Studio, které obsahuje potřebné nástroje pro kompilaci, ladění i testování. Stačí jej stáhnout, nainstalovat a nechat doběhnout prvotní konfiguraci. Během ní si nainstaluj SDK pro alespoň jednu starší a jednu novější verzi systému. Emulátor si nastav tak, aby odpovídal zařízení, na kterém chceš aplikaci reálně testovat – ideálně telefon s běžným rozlišením a rozumnou pamětí.<br><br>Testovací pyramida není dogma, ale nástroj, jak rozhodnout, kde má který test vzniknout. Vychází z jednoduché myšlenky: čím rychlejší a levnější test, tím častěji ho spouštíme. Na dně stojí jednotkové testy, uprostřed integrační a nahoře end-to-end. Pokud poměr obrátíte, sada se zpomalí, začne padat z nesouvisejících důvodů a lidé jí přestanou věřit.<br><br>Co napsat do Program.cs a proč to funguje Nejjednodušší funkční program vypadá takto: Console.WriteLine("Ahoj");. Řádek končí středníkem, na tom záleží. Text v uvozovkách se vypíše a odřádkuje. Pokud chcete vstup od uživatele, použijte Console.ReadLine() a výsledek uložte do proměnné, například string jmeno = Console.ReadLine();. Pozor na návratový typ: ReadLine vrací text, i když uživatel napíše číslo. Před počítáním je nutné převést hodnotu, třeba pomocí int.Parse nebo lépe int.TryParse, které nespadne při nesmyslném vstupu.<br><br>Praktický postup je zavést pyramidu do CI postupně. Nejprve zrychlete jednotkové testy tak, aby běžely do několika sekund. Pak přidejte integrační sadu, která se spouští při každém commitu. End-to-end testy nechte na noční běh nebo před vydáním. Sledujte dobu běhu a flakiness. Každý test, který občas padá bez změny kódu, buď opravte, nebo smažte. Nespolehlivá sada je horší než žádná.<br><br>Nakonec si hlídejte poměr, ale ne slepě. U malé služby může stačit pár jednotkových a jeden integrační test. U složitého systému s mnoha rozhraními bude integrační vrstva silnější. Pyramida je vodítko pro rozhodování, ne soutěž o počty. Když každý test ví, co ověřuje, a běží na správné vrstvě, sada zůstane rychlá, srozumitelná a užitečná i po letech.<br><br>Při odhadu analytiky se ptejte na konkrétní věci: Kolik lidí musíme vyslechnout? Existuje už nějaká dokumentace? Jak moc se liší stávající systémy? Kolik variant scénářů musíme pokrýt? Kdo bude schvalovat výstup? Každá z těchto otázek může odhad posunout o dny. Typická chyba je odhadnout analytiku jako „půl dne na schůzku", i když schůzka je jen začátek a skutečná práce přichází po ní.<br><br>Kde pyramida v praxi selhává Nejčastější chyba je nahrazení pyramidy zmrzlinovou kornoutkem: mnoho pomalých end-to-end testů a skoro žádné jednotkové. Vzniká to tak, že se testy píší až po nasazení a přes uživatelské rozhraní. Řešení není psát víc testů, ale přesunout odpovědnost níž. Když test selže, má být jasné, která vrstva to způsobila. Pokud k opravě potřebujete spustit celou aplikaci, test je příliš vysoko.<br><br>Když program nefunguje, začněte u chybové zprávy. Kompilátor v C# hlásí přesný soubor, řádek i sloupec. Nejdřív hledejte chybějící středník, nepárovou závorku nebo překlep v názvu proměnné. Rozlišujte malé a velké písmeno: console a Console jsou dvě různé věci a kompilátor druhou z nich nezná. Další častá past je uložení souboru v jiném kódování, které rozbije diakritiku ve výpisu. Uložte zdroják v UTF-8.<br><br>Vytvoř si vlastní testovací projekt. Vyber si veřejně dostupnou aplikaci nebo web, který můžeš legálně testovat, a sepisuj testovací případy. Zaznamenej chyby, které najdeš, včetně přesného postupu. Výsledek dej na jedno místo, které můžeš poslat. Personalista a technický vedoucí tak uvidí tvůj způsob myšlení, ne jen tvrzení, že tě testování baví. Důležité je být konkrétní: u každé chyby uveď, proč ji považuješ za závažnou a co by se stalo, kdyby zůstala v produkci.<br><br>Než začnete ladit detaily, otestujte tok s pěti lidmi. Sledujte, kde se zaseknou, ne co říkají, že se jim líbí. Opravte jedno místo, otestujte znovu. Design není fáze projektu, ale průběžná kontrola toho, jestli rozhraní dělá to, co jste zamýšleli. Nejčastější chyba není nedostatek talentu, ale přeskočení tohoto kroku.<br><br>Kontrast, velikost písma a dotykové plochy nejsou estetika, ale přístupnost. Text, který nejde přečíst na slunci nebo na malém displeji, je nefunkční. Klikací oblast má být větší než samotná ikona, jinak ji lidé netrefí. Nepoužívejte barvu jako jediný nositel významu — stav musí být čitelný i bez rozlišení odstínu. Stejná pravidla držte napříč celou aplikací, protože nekonzistence nutí uživatele učit se totéž dvakrát.

104.23.223.155: Created page with "Práce ve větvi je bezpečná jen tehdy, když víš, kde jsi. git branch vypíše větve, git switch -c nova-vetev vytvoří a přepne. Častá chyba: upravovat soubory, pak přepnout větev a divit se, že změny „zmizely". Git je nemaže, jen je nechá v pracovním adresáři a přepnutí buď zablokuje, nebo je přenese jinam. Před přepnutím buď změny commitni, nebo je odlož pomocí git stash. Sloučení (git merge) přináší konflikty — nejsou porucha,..."

2026-10-02T01:00:16Z

Created page with "Práce ve větvi je bezpečná jen tehdy, když víš, kde jsi. git branch vypíše větve, git switch -c nova-vetev vytvoří a přepne. Častá chyba: upravovat soubory, pak přepnout větev a divit se, že změny „zmizely". Git je nemaže, jen je nechá v pracovním adresáři a přepnutí buď zablokuje, nebo je přenese jinam. Před přepnutím buď změny commitni, nebo je odlož pomocí git stash. Sloučení (git merge) přináší konflikty — nejsou porucha,..."

New page

Práce ve větvi je bezpečná jen tehdy, když víš, kde jsi. git branch vypíše větve, git switch -c nova-vetev vytvoří a přepne. Častá chyba: upravovat soubory, pak přepnout větev a divit se, že změny „zmizely". Git je nemaže, jen je nechá v pracovním adresáři a přepnutí buď zablokuje, nebo je přenese jinam. Před přepnutím buď změny commitni, nebo je odlož pomocí git stash. Sloučení (git merge) přináší konflikty — nejsou porucha, jsou normální stav. Otevři označené soubory, vyber správnou verzi, odstraň značky >>>>>>, pak soubor přidej a commit dokonči. Typické chyby se opakují. Testovací data se zapisují natvrdo do kódu, takže testy padají při změně prostředí. Testy závisí na sobě navzájem a jejich pořadí rozhoduje o výsledku. Čekání se řeší pevnými prodlevami místo čekání na konkrétní stav, což vede k náhodným selháním. Automatizované testy se spouštějí jen na emulátoru a nikdy na skutečném zařízení. A často chybí testy pro obnovení stavu po přerušení – třeba když uživatel přijme hovor uprostřed nahrávání. Nakonec platí, že sjednocení není jednorázový úkol, ale dohoda, kterou je potřeba udržovat. Vyberte variantu, která odpovídá velikosti týmu a počtu projektů, a nechte si prostor pro změnu, až se podmínky vyvinou. Jednotná konfigurace má smysl jen tehdy, když zjednodušuje každodenní práci, ne když přidává další vrstvu, kterou je třeba hlídat. Prvním krokem je rozdělit testy podle toho, co skutečně ověřují, ne podle názvu složky. Jednotkový test volá jednu funkci nebo třídu, nepoužívá databázi, síť ani souborový systém a běží v milisekundách. Integrační test naopak ověřuje spolupráci dvou a více komponent včetně reálného úložiště nebo HTTP vrstvy. Pokud test potřebuje nastartovat aplikaci, není to jednotkový test, i když je v souboru s názvem unit. Vývojář obvykle řeší, jestli kód funguje. Uživatel řeší, jestli chápe, co má udělat. Mezi tím vzniká propast, do které padá většina jinak technicky správných aplikací. UI a UX nejde dodatečně „přilepit" na hotový produkt. Rozhodnutí o rozložení, hierarchii a zpětné vazbě se dělají průběžně, nejlépe ještě před psaním první komponenty. Praktický postup je postupný. Vyberte jednu oblast, například formátování kódu, a sjednoťte ji jako první. Zaveďte ji tak, aby fungovala i bez ručního zásahu, a teprve po ověření přidejte další. U každé změny si předem řekněte, jak poznáte, že funguje: sníží se počet konfliktů při slučování, zmizí opakované opravy stejné chyby, nový člen týmu spustí projekt bez dodatečného vysvětlování. Bez těchto měřítek se sjednocení zvrhne v debatu o preferencích. Základní volba stojí mezi jedním sdíleným repozitářem a více repozitáři s centrální konfigurací. Sdílený repozitář znamená, že všechny části projektu leží pohromadě a konfigurační soubory jsou na jednom místě. Výhodou je okamžitá viditelnost změn a jednodušší zavádění nových členů týmu. Nevýhodou je horší izolace: změna v jedné části může nechtěně ovlivnit jinou a nástroje musejí zvládat větší objem dat. U více repozitářů je potřeba vyřešit, odkud se konfigurace bere a jak se synchronizuje. Formuláře jsou místo, kde se ztrácí nejvíc konverzí. Každé pole navíc snižuje ochotu dokončit akci. Ptejte se jen na to, co skutečně potřebujete, a zbytek zjistěte později. Popisky patří nad pole, ne dovnitř jako placeholder, protože ten po napsání zmizí a uživatel zapomene, co vyplňuje. Validujte při odchodu z pole, ne při každém stisku klávesy. Chybová zpráva má být u konkrétního pole a konkrétní, ne souhrnná dole pod formulářem. Sjednocení konfigurace projektu pro tým není otázkou jediného nástroje. Jde o rozhodnutí, kde bude konfigurace žít, kdo ji bude měnit a jak se změny dostanou ke všem. Nejčastější chybou je začít výběrem technologie dřív, než je jasné, jaké problémy má sjednocení řešit. Sepište si, co dnes dělá potíže: rozdílné verze závislostí, odlišné formátování, ruční nastavování prostředí, nebo kombinace všeho. Teprve pak má smysl porovnávat varianty. Mezi časté chyby patří zavádění příliš mnoha pravidel najednou, ponechání starých konfigurací naživu a chybějící dohoda o tom, kdo změny schvaluje. Pokud se konfigurace mění bez kontroly, začne se dřív nebo později rozcházet s realitou. Pomáhá i to, když je konfigurace součástí projektu a ne skrytá v nastavení jednotlivých strojů. Když ji někdo potřebuje upravit, musí být jasné, kam sáhnout a koho se zeptat. Kdy se vyplatí centrální konfigurace a kdy ne Centrální konfigurace dává smysl ve chvíli, kdy tým pravidelně řeší stejné nastavení: pravidla pro formátování, kontrolu typů, testovací skripty nebo nastavení editoru. Tyto věci patří do jednoho místa, odkud si je každý projekt vezme. Naopak věci specifické pro konkrétní službu, jako jsou cesty k datům nebo parametry nasazení, mají zůstat lokálně. Pokud se snažíte centralizovat i něco, co se v každém projektu liší, vznikne z konfigurace nečitelný soubor plný výjimek. To je typický důvod, proč se sjednocení po čase rozpadne.