Edytujesz Verzování, které vás zradí: nejčastější chyby v Gitu

Další zrádná věc je větvení. Nováčci často commitnou rovnou do hlavní větve, i když pracují na nové funkci. Pak zjistí, že v hlavní větvi je rozbitý kód, a nevědí, jak ho oddělit. Řešení je jednoduché: pro každou činnost si vytvořte novou větev příkazem git checkout -b nazev-vetve. Tím získáte izolované prostředí, kde můžete experimentovat. Když se něco nepovede, větev jednoduše smažete a hlavní větev zůstane čistá.<br><br>Měření pokrytí kódu testy je užitečný nástroj, ale často se z něj stává fetiš. Mít 100% pokrytí neznamená, že je aplikace bez chyb. Spíše to může znamenat, že testy kontrolují jen to, co se snadno testuje, a ignorují složitější scénáře. Klíčové je vědět, kdy měření dává smysl a kdy jen vytváří falešný pocit bezpečí.<br><br>Na závěr jedno doporučení: nezkoušejte si pamatovat všechny příkazy. Stačí jich znát pět – init, add, commit, status, log – a zbytek si vyhledáte, až budete potřebovat. Klíčové je pochopit, že Git je nástroj pro práci s časem a větvemi, ne kouzelná hůlka. Čím víc ho budete používat, tím méně chyb budete dělat. A když už chybu uděláte, vězte, že Git vám téměř vždy dá možnost se vrátit.<br><br>Další pastí je psát dlouhé funkce, které dělají deset věcí najednou. Funkce by měla mít jednu zodpovědnost a měla by být krátká – ideálně do dvaceti řádků. Pokud potřebujete rozdělit logiku, vytvořte pomocné funkce s výstižnými názvy. Například místo jedné funkce processOrder, která počítá cenu, ověřuje zásoby a aktualizuje uživatele, rozdělte ji na validateOrder, calculateTotal a updateInventory. Tím se kód nejen lépe čte, ale také snáze testuje a opravuje.<br><br>K nezanedbatelným návykům patří i psaní komentářů. Komentáře by neměly popisovat to, co je vidět z kódu, ale vysvětlovat proč. Například proč je potřeba zpoždění, jaká obchodní pravidla se uplatňují, nebo proč je použita neobvyklá implementace. Vyhněte se komentářům typu // přičteme 1 nad řádkem count += 1; – to jenom zašumuje. Lepší je napsat // Zahrneme i počáteční hodnotu nuly.<br><br>Nakonec si dejte záležet na tom, jak aplikaci otestujete. Unit testy jsou samozřejmost, ale důležitější je UI testování, které odhalí problémy s automatickým layoutem, různými velikostmi obrazovek a dynamickými fonty. Nespokojte se s tím, že aplikace funguje na vašem telefonu. Zkuste ji ovládat jednou rukou, používejte VoiceOver a zapněte si zvětšený text. Mnoho aplikací končí špatným hodnocením jen kvůli tomu, že vývojář ignoroval přístupnost a jednoduchou navigaci. Pokud se vám podaří tyto základy zvládnout, budete mít solidní základ pro to, abyste se mohli pouštět do složitějších projektů, aniž byste neustále bojovali s vlastním kódem.<br><br>Práce s Gitem je dnes standardem i pro sólové vývojáře. Přesto většina začátečníků narazí na stejné zbytečné komplikace: ztratí práci, commitnou do špatné větve nebo neví, jak se vrátit k předchozímu stavu. Nejde o nedostatek talentu, ale o to, že se učíte příkazy bez kontextu. Tento článek vás provede základy tak, abyste se vyhnuli nejčastějším pastem, které vás mohou stát hodiny práce.<br><br>Věnujte pozornost také selektorům. Místo toho, abyste veškerou logiku výběru dat nechávali v komponentách, vytvořte si selektory, které z celého stavu vyberou pouze to, co komponenta potřebuje. Díky tomu se vyhnete přepočítávání při každém renderu. Používejte memoizaci, aby se selektor nespouštěl zbytečně, když se stav nezměnil. Pokud selektor vrací nové pole pokaždé, když se stav změní, může to způsobit zbytečné překreslování i tam, kde se data nezměnila.<br><br>Když se pustíte do vývoje iOS aplikací ve Swiftu, první věc, kterou oceníte, je čitelnost kódu a rychlá zpětná vazba z Xcode. Než ale začnete psát první řádky, nastavte si minimální cílovou verzi systému. Pokud cílíte na starší zařízení, přicházíte o moderní frameworky jako SwiftUI nebo async/await. Naopak příliš čerstvá verze systému vám zbytečně zúží okruh uživatelů. Dobrý kompromis je podporovat dvě až tři poslední hlavní verze iOS a vždy testovat na fyzickém zařízení, nejen v simulátoru.<br><br>Psát čistý kód není o psaní méně řádků, ale o tom, aby se v něm druhý programátor (nebo vy za půl roku) dokázal rychle zorientovat. Základním pravidlem je, že kód by měl být čitelný bez dlouhého přemýšlení. To znamená dát přednost explicitnímu pojmenování proměnných a funkcí před zkratkami, které šetří pár znaků, ale komplikují pochopení. Typickým příkladem je použití názvů jako data, temp nebo x tam, kde by stačilo userList nebo formattedDate. Čitelnost se vždycky vyplatí víc než kratší zápis.