Kdy open source licence omezí váš projekt a kdy ne

Akce navrhujte jako malé, konkrétní události, ne jako univerzální příkazy. Místo jedné akce UPDATE s obřím payloadem použijte itemAdded, itemRemoved a itemUpdated. Reducer pak zůstane čitelný a testovatelný. U složitějšího stavu se osvědčil vzor slice: jeden soubor obsahuje počáteční stav, akce i reducer pro jednu doménu. Nesnažte se ale vytvořit jeden slice pro celou aplikaci, jinak se vrátíte k monolitickému reduceru, kterému nikdo nerozumí.

Při každé změně požadavku projděte tři otázky: Co se změnilo na vstupu nebo výstupu? Která vrstva to dokáže ověřit nejrychleji? Který existující test tím ztrácí smysl? Odpovědi zapište k úloze, ne do hlavy. Testy, které už nic nechrání, mažte bez sentimentu. Nahromaděné zastaralé scénáře jsou častější příčina pomalých sad než samotný růst požadavků. Stejně tak neignorujte testovací data: pokud se mění formát nebo rozsah vstupů, musí se změnit i příprava dat, jinak začnou padat testy, které s danou změnou vůbec nesouvisí.

Začněte tím, že si projdete základy jazyka, ve kterém budete psát. Pro Android dnes existují dvě rozumné cesty. První je oficiální jazyk navržený přímo pro Android, druhá je jazyk běžící na virtuálním stroji, který je na Androidu zavedený dlouho. Obě mají smysl, ale nemíchejte je v jednom projektu. Vyberte jednu, naučte se syntaxi, práci s proměnnými, podmínkami, cykly a třídami. Teprve pak má smysl otevřít editor projektu, protože jinak budete bojovat s jazykem i s frameworkem zároveň a nepoznáte, co z toho vlastně selhalo.

Volba open source licence není formalita na konci vývoje. Licence určuje, co smíte s kódem dělat, jak ho můžete kombinovat s jinými komponentami a jaké povinnosti vzniknou tomu, kdo software dále šíří. Pokud se licence řeší až při vydání, často se ukáže, že část kódu nelze použít vůbec, nebo že by projekt musel změnit licenci celý. Kontrola licencí má proběhnout dřív, než do repozitáře přibude první závislost.

Začněte pojmenováním. Proměnná data neříká nic, seznamUzivatelu říká všechno. Funkce process() nutí čtenáře otevřít tělo funkce, vypocitejSlevu() ho pustí dál. Platí přitom jedno pravidlo: pokud název potřebuje komentář, je název špatný. Komentáře mají vysvětlovat proč, ne co. Když vidíte // zvyšujeme o jedna nad i++, komentář jen opakuje kód a za měsíc bude lhát.

Nakonec se naučte číst chybové výpisy. Nepanikařte, když jich je mnoho; hledejte první řádek, který odkazuje na váš kód, ne na systémové knihovny. Právě tam vznikla chyba. Dokumentaci k platformě čtěte po malých částech a vždy k tématu, které zrovna řešíte. Vývoj pro Android není o zapamatování všech tříd, ale o tom, že umíte najít, co potřebujete, a ověřit, že to funguje. Kdo zvládne tento přístup, tomu se první aplikace podaří spustit dřív, než ho přestane bavit.

Při testování sledujte, jak se limit chová při souběžných požadavcích. Typická chyba je testovat pouze jeden požadavek za sekundu a pak být překvapen, že ostrý provoz dostává 429. Použijte nástroj, který umí poslat stovky požadavků najednou, a ověřte, že se počítadla správně resetují. Do odpovědi přidejte hlavičku Retry-After, aby klient věděl, kdy může zkusit znovu. Pokud omezujete podle IP, pamatujte, že za proxy musíte nastavit trust proxy, jinak všechny požadavky vypadají jako z jedné adresy.

Druhá častá chyba je ignorování toho, že se aplikace může kdykoli přerušit. Uživatel přijme hovor, otočí telefon, zamkne obrazovku. Pokud s tím kód nepočítá, přijdete o rozpracovaná data nebo se aplikace znovu načte od začátku. Testujte proto nejen to, co vidíte, ale i to, co se stane po návratu do aplikace. Emulátor na to má nástroje, stačí je použít. Třetí chyba je ladění pouze na emulátoru. Skutečné zařízení se chová jinak v paměti, výkonu i oprávněních.

Typická chyba začátečníka je snaha udělat hned kompletní aplikaci s přihlášením, databází a stahováním dat. Výsledkem je projekt, který se rozbije na deseti místech současně a nedá se odladit. Držte se pravidla jedné nové věci na jeden krok. Nejprve jedna obrazovka, pak přechod mezi dvěma obrazovkami, pak uložení jedné hodnoty, pak načtení dat ze sítě. Po každém kroku aplikaci spusťte a ověřte, že se chová podle očekávání. Když něco přestane fungovat, víte, že problém vznikl v poslední změně.

Většina lidí začne s mobilním vývojem pro Android tak, že si nainstaluje vývojové prostředí a hned píše kód. To je spolehlivý způsob, jak po dvou týdnech skončit s projektem, který se nedá spustit a v hlavě zmatek. První krok není psaní, ale pochopení toho, jak aplikace na Androidu vůbec funguje. Aplikace není jen okno s tlačítky; je to sada komponent, které systém spouští podle potřeby, a životní cyklus těchto komponent ovlivňuje úplně všechno.