Jak propojit design a kód: UI/UX základy pro vývojáře

Pozor také na přístupnost, kterou vývojáři často podceňují. Nejde jen o povinnost, ale o praktickou funkčnost. Uživatelé se zhoršeným zrakem, pohybovým postižením nebo jen s modrým filtrem na obrazovce ocení, když dodržíte kontrastní poměry, nastavíte správné alt texty u obrázků a umožníte ovládání klávesnicí. Typická chyba? Spoléháte na to, že stačí barevně odlišit tlačítko, ale ignorujete, že barevně slepý uživatel nerozpozná, že je aktivní. Přidejte ikonu nebo textovou změnu kromě barvy, a problém je vyřešen.

Základní princip pytestu je jednoduchý: píšete funkce, které začínají slovem test_, a uvnitř nich používáte příkazy assert. Pytest sám najde všechny soubory a funkce podle konvence pojmenování. Nemusíte nic registrovat ani dědit z nějaké třídy. Stačí mít soubor s názvem třeba test_math.py a v něm funkci test_add(). Když spustíte pytest v adresáři projektu, projde všechny soubory, které odpovídají vzoru test_*.py nebo *_test.py, a spustí všechny funkce test_*.

Při psaní testů se vyhněte závislosti na pořadí testů. Každý test musí být nezávislý. Pokud testy sdílejí stav, může jeden selhat kvůli vedlejšímu efektu jiného, což ztěžuje hledání příčiny. Místo toho používejte [SetUp] pro vytvoření nové instance testované třídy a [TearDown] pro uvolnění zdrojů. Typickou chybou je také testování více věcí najednou – jeden test by měl ověřovat jedno chování. Pokud testovací metoda obsahuje více assertů, rozdělte ji na více testů s jasnými názvy.

Jak psát testy, které dávají smysl Nejdůležitější je testovat chování, ne implementaci. Zaměřte se na to, co funkce dělá, ne na to, jak to dělá. Například místo testování, že funkce volá určitou metodu, ověřte, že vrací očekávaný výsledek pro daný vstup. Také je dobré testovat okrajové případy: prázdný seznam, nulu, záporná čísla, prázdný řetězec. Typická chyba začátečníků je testovat jen hlavní cestu, takže pak testy neodhalí chyby, které se objeví při neobvyklých vstupech.

Nakonec si s klientem ujasněte, co se stane, když se odhad nenaplní. Nabídněte mu pravidelné krátké reporty o průběhu práce, kdy mu řeknete, kde jste a co zbývá. Tím přebíráte odpovědnost za komunikaci, ale ne za nepředvídatelné události. Pokud se něco pokazí, řešte to věcně: popište důvod, nový odhad a konkrétní kroky, jak se vyhnout dalšímu zpoždění. Klient ocení, když místo omluv dostane plán.

Konzistence a hierarchie: dva pilíře, na kterých stojí dobrý design Konzistence znamená, že stejné prvky vypadají a chovají se stejně. Pokud jedno tlačítko potvrzuje akci zeleně, mělo by být zelené všude. Pokud kliknutí na kartu otevře detail, mělo by to fungovat u všech karet. V praxi to znamená, že si v projektu nastavíte designový systém – sdílené komponenty, proměnné pro barvy a typografii – a důsledně je používáte. Hierarchie pak říká, co je na obrazovce nejdůležitější. Větší písmo, výraznější barva a pozice nahoře signalizují důležitost. Typická chyba vývojářů? Všechno udělají stejně velké a stejně barevné, protože se bojí, aby něco nezvýraznili moc. Výsledkem je plochá, nepřehledná stránka, kde uživatel netuší, kam se dívat.

Jak sdělit odhad, aby vzbuzoval důvěru Při sdělování odhadu vždy uveďte, z čeho vycházíte. Klient ocení, když mu řeknete: „Na základě podobných projektů předpokládám, že to zvládneme do tří týdnů." Tím dáváte najevo, že nejde o náhodné číslo. Zároveň si ověřte, zda klient rozumí tomu, že odhad může kolísat. Navrhněte si společný postup pro případ, že se práce protáhne – klienta informujte předem, ne až ve chvíli, kdy je problém na světě. Pokud cítíte, že klient tlačí na nereálně krátký termín, nebojte se říct, že to nejde, a vysvětlit proč.

Pamatujte, že cílem není vyhnout se slibům za každou cenu, ale slibovat jen to, co můžete splnit. Když se naučíte komunikovat odhady jako pracovní nástroj, ne jako věštbu, získáte si respekt a klienti se k vám budou rádi vracet. A to je lepší než sto rychlých, ale nesplněných termínů.

Jak správně synchronizovat větve Když potřebujete do své feature větve dostat změny z hlavní větve, nepoužívejte merge, ale rebase. Rebase přehraje vaše commity na nový základ a vytvoří lineární historii. To usnadňuje pozdější code review a snižuje riziko konfliktů. Postup je jednoduchý: přepnete se na hlavní větev, pullnete změny, přepnete se zpět na svou větev a provedete rebase. Při rebase se mohou objevit konflikty, které je nutné vyřešit. To je normální, ale pokud je to časté, znamená to, že se vaše větve příliš odchýlily.

Dalším častým problémem je ignorování mezer a odstupů. Návrháři používají systém mezer (často v násobcích základní jednotky, třeba 4px), aby vytvořili rytmus a oddělili logické celky. Když mezery nahradíte univerzálním paddingem nebo marginem podle toho, co zrovna vypadá dobře, rozbijete celou vizuální rovnováhu. Naučte se číst designové specifikace – v nich najdete přesné hodnoty odsazení, velikostí a barev. Pokud taková specifikace chybí, zeptejte se designéra, jaký systém používá. Je to rychlejší, než hádat a poté předělávat polovinu komponent.