Odhad času bez skrytých činností: proč realita neodpovídá plánu

Důležité je také myslet na budoucnost. Komentáře píšete pro sebe za šest měsíců, ne pro váš aktuální mozek. Proto se vyplatí investovat čas do vět, které vysvětlují rozhodnutí, jež na první pohled nedávají smysl. Pokud jste například změnili algoritmus kvůli výkonu, napište, proč to bylo nutné a jaké měření vás k tomu vedlo. Tím se vyhnete situaci, kdy později někdo (nebo vy sami) změnu vrátí, protože nevidí důvod, proč byla provedena.

Každý vývojář zná okamžik, kdy listuje historií repozitáře a narazí na zápis typu „oprava bugu" nebo „update". Místo jasné odpovědi, co se v daném commitu stalo, přichází jen mlhavé tušení a nutnost procházet diff řádek po řádku. Smysluplné commit zprávy nejsou formalita, ale nástroj, který vám ušetří hodiny práce při hledání příčiny problému. Zpětná dohledatelnost změn totiž nestojí na dokonalém nástroji, ale na tom, jak s historií pracujete.

Další dovednost, kterou budete potřebovat, je práce s větvemi. Větve umožňují oddělit experimentální práci od stabilní verze. Když začínáte novou funkci, vytvořte větev s výstižným názvem, třeba podle čísla úkolu. Když je práce hotová, sloučíte ji zpět. Tento postup vás ochrání před tím, abyste zanesli chyby do produkčního kódu. Nezapomínejte ale na pravidlo: před sloučením si vždy prohlédněte rozdíly mezi větvemi. Někdy se stane, že soubor upravíte a v něm je jiná verze, než čekáte. Porovnání vám ukáže přesně, co se změní, a zabrání konfliktům.

Prvním krokem není psát kód, ale sjednotit si představu o tom, co chcete vytvořit. Než otevřete vývojové prostředí, rozhodněte se, zda cílíte na telefon, tablet, nebo obojí. Android pokrývá obrovské množství zařízení s různými velikostmi obrazovky a výkonem. Pokud začínáte, zaměřte se na jeden typ zařízení a jeden úzký účel aplikace. Sepište si tři hlavní funkce, bez kterých se aplikace neobejde, a vše ostatní nechte na později. Tím se vyhnete typickému začátečnickému problému – snaze postavit všechno najednou a výsledné aplikaci, která nefunguje spolehlivě.

Jaké chyby vás nejčastěji zdrží? Největší pastí pro začátečníky je práce s emulátorem. Emulátor je pomalý a často nereprezentuje skutečné chování zařízení. Pokud máte možnost, zapojte do počítače fyzický telefon a povolte v něm ladění. Na reálném přístroji hned uvidíte, jak aplikace reaguje na dotyk, jak rychle se spouští a kolik paměti zabírá. Pokud používáte emulátor, nastavte mu dostatek paměti a procesorových jader, jinak bude každý běh frustrující a neefektivní.

Prvním krokem je výběr nástroje. Většina týmů dnes používá distribuovaný systém, který umožňuje pracovat offline a nemá centrální server. Nejrozšířenější je ten, který znáte pod příkazem git. Než začnete, ověřte si, že máte nainstalovanou aktuální verzi. Pak si v terminálu otevřete složku svého projektu a spustíte inicializaci. Tím vytvoříte skrytou složku, která bude sledovat všechny změny souborů. Od této chvíle každé uložení do historie vyžaduje dvě operace: přidání změn do indexu a samotný záznam s popisem.

Pojďme si ukázat konkrétní případ. Máte funkci, která čte konfiguraci z globální proměnné. Napíšete test, který tuto proměnnou nastaví, a hned záhy test, který ji čte. První test projde, druhý selže, protože první test proměnnou nevrátil do původního stavu. Řešení? Použijte fixture s rozsahem function, která před každým testem nastaví výchozí hodnotu. A hlavně – nikdy neměňte globální stav napřímo v testovací funkci. Vždy to udělejte přes fixture, která se postará o úklid.

První commit a každodenní práce Jakmile máte připravený projekt, udělejte první záznam. Ten by měl obsahovat celou aktuální funkční verzi kódu, ne jen prázdnou složku. Popisek prvního commitu ať je stručný, ale výstižný – například „Inicializace projektu". Následně se vyhněte dvěma extrémům: neukládejte změny po každém jednom řádku s popiskem „oprava", ale ani nevydržte celý den bez jediného záznamu. Ideální je udělat commit vždy, když máte hotový logický celek – novou funkci, opravený bug nebo přeformátovaný kód. Každý záznam by měl být samostatný a v ideálním případě by se k němu dalo vrátit bez obav, že rozbijete jinou část projektu.

Na závěr si zvykněte číst logy a výjimky. Když aplikace spadne, logcat vám přesně řekne, na kterém řádku a proč se to stalo. Místo hledání řešení na internetu se nejdřív pokuste chybu přečíst a pochopit. Často jde o drobnost, jako je nulová hodnota nebo špatný název souboru. Pravidelným čtením logů získáte dovednost, která vám ušetří desítky hodin hledání. Postupně se propracujete od jednoduchých aplikací ke složitějším a zjistíte, že vývoj pro Android je logičtější, než se zdá.