Co potřebujete, než napíšete první řádek pro Android?

Největší chybou začátečníků je používat typ any. Označíte jím proměnnou a máte pocit, že je vyřešeno. Jenže any vypne kontrolu a smysl TypeScriptu mizí. Když narazíte na hodnotu, u které typ neznáte, použijte unknown a teprve po ověření ji zúžte na konkrétní typ. Další častý problém je záměna rozhraní a typových aliasů. Obojí vypadá podobně, ale rozhraní se dá rozšiřovat a sloučit, což se hodí u objektů a knihoven. Typový alias je vhodnější pro unie, průniky a složitější kombinace.

Prvním krokem je stanovit, co je hlavní větev. Obvykle to je stabilní linie, do které se integrují hotové funkce. Z ní vždy odbočujete a do ní se vracíte. Nikdy necommitujte přímo do hlavní větve, pokud na ní pracuje více lidí. Druhé pravidlo zní: než začnete novou větev, aktualizujte si lokální kopii hlavní větve. Tím zajistíte, že odbočujete z nejnovějšího stavu, a snížíte riziko, že budete muset řešit konflikty, které už dávno vyřešil někdo jiný.

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.

Nezapomínejte na verze systému. Zařízení v oběhu mají různé verze a ne každá nová funkce je dostupná všude. Nastavte si minimální podporovanou verzi a testujte na ní. Zároveň se vyhněte pevnému nastavení rozměrů a pozic; používejte rozvržení, která se přizpůsobí velikosti displeje. Jinak bude vaše aplikace vypadat dobře jen na vašem telefonu.

Nakonec si zvykněte pracovat se systémem správy verzí. I malý projekt si zaslouží historii změn. Když se něco rozbije, můžete se vrátit k funkčnímu stavu. Komentujte kód česky nebo anglicky, ale jednotně. A hlavně: dokončete první verzi, i kdyby nebyla dokonalá. Publikovatelná jednoduchá aplikace vás posune dál než měsíce plánování v hlavě.

Na co si dát pozor: nesnažte se rebasovat větev, která obsahuje merge commity z jiných větví. Výsledek je nepředvídatelný. Dále nikdy necommitujte konfigurační soubory, které se liší stroj od stroje. Používejte lokální konfiguraci, která není součástí repozitáře. A pokud pracujete na více funkcích současně, přepínejte větve jen s čistým pracovním stromem. Necommitnuté změny si před přepnutím buď commitněte, nebo odložte stranou. Jinak si je přenesete do špatné větve a budete je pracně hledat.

Třetí pravidlo se týká velikosti změn. Integrujte často a po malých částech. Pokud je to možné, slučujte hotové dílčí části funkce do hlavní větve průběžně, ne až na konci. Velká větev s desítkami commitů je noční můra při řešení konfliktů. Menší, častější sloučení znamenají menší konflikty a snadnější identifikaci chyby. Pokud funkce není hotová, použijte feature flag a sloučte neaktivní kód. Aktivujete ho, až bude vše připraveno.

Další častou chybou je ignorování životního cyklu obrazovky. Aplikace není jen to, co vidíte na displeji. Když uživatel přijme hovor nebo otočí telefon, obrazovka se může znovu vytvořit a vaše data se ztratí. Učte se od začátku ukládat stav a reagovat na události, které systém posílá. Ověřujte chování při otočení, při přechodu na jinou obrazovku a při návratu zpět. Teprve pak začněte řešit vzhled.

Základem je nainstalovat si vývojové prostředí a pochopit, jak se projekt sestavuje. Většina začátečníků dnes používá některé z volně dostupných prostředí postavených na jazyce Kotlin, který je pro nové projekty doporučovaný. Nainstalujte ho, vytvořte prázdný projekt a spusťte ho na emulátoru. Teprve pak zkuste přidat tlačítko a textové pole. Pokud přeskočíte tento krok a rovnou se pustíte do složité aplikace, budete později tápat v tom, co která část kódu dělá.

Většina týmů se domluví na nějakém větvení, a pak se diví, proč se změny pořád ztrácejí. Nejčastější příčina není Git sám, ale práce přímo na hlavní větvi. Když všichni commitají do main, každý push se stává malou sázkou: buď projde, nebo přepíše něčí práci. Řešení je jednoduché a nezajímavé — main nech jen pro to, co je ověřené. Denní práce patří na krátce žijící větve, které vznikají z aktuálního main a do něj se také vracejí.

JavaScript se po roce 2015 výrazně proměnil. Šestá edice specifikace, známá jako ES6 nebo ES2015, přinesla sadu nástrojů, které dřív řešily knihovny nebo pracné obcházení jazyka. Dnes je většina z nich běžnou součástí prohlížečů i serverového prostředí. Přesto se vyplatí vědět, kde se chyby dělají nejčastěji a jak se jim vyhnout.