Co se stane, když začnete s Androidem bez plánu

Když pracujete na více feature větvích najednou, verzování se rychle změní v chaos, pokud nemáte jasná pravidla. Nejčastější chybou je spoléhat se na to, že si každý zapamatuje, co kde dělá. Místo toho si nastavte systém, který funguje i ve chvíli, kdy na projektu dělá více lidí a větve se začnou křížit.

Nejčastější chyby, které dělají historii nepřehlednou Mezi typické prohřešky patří vágní slovesa jako „oprava", „úprava", „vylepšení" bez bližšího určení. Další častý problém je míchání nesouvisejících změn do jednoho commitu – když v jednom commitu opravíte chybu, přidáte novou funkci a přejmenujete proměnnou, je to noční můra. Každá logická změna by měla být ve vlastním commitu, aby se dala v případě potřeby revertovat bez vedlejších škod. A pozor na hlášky typu „hotovo", „snad to funguje" nebo „nechápu, proč to nešlo". Tyto zprávy říkají o změně úplně všechno, jen ne to podstatné.

Jak sdělit odhad, aby zazněl jako závazek, ne jako věštba Když už odhad sdělujete, vždy ho orámujte jako rozsah, ne jako jediné datum. Například: „Předpokládám, že to bude hotové mezi desátým a patnáctým, ale pokud narazíme na něco neočekávaného, dám vám vědět okamžitě." Tím dáváte najevo, že termín není náhodné číslo, ale výsledek vaší úvahy. A hlavně – neslibujete přesný den, pokud si nejste jistí. Zákazník ocení víc upřímnost než falešný optimismus, který se stejně nevyplní.

Na závěr si nastavte pravidlo, že každou větev po mergu smažete. Udržování starých větví jen přidává zmatek a zvyšuje riziko, že někdo omylem naváže na zastaralý kód. Pokud potřebujete historii, git ji uchovává i po smazání větve. Klíčem k úspěchu je disciplína a pravidelný úklid. Když budete tyto zásady dodržovat, práce na více feature větvích bude přehledná a vy se vyhnete zbytečným konfliktům.

Základní pravidlo je jednoduché: commit zpráva má popisovat změnu, ne opsat diff. Pokud napíšete „oprava bugu", neřeknete nic. Pokud napíšete „oprava null pointeru při parsování prázdného JSONu v ReportService", řeknete přesně to, co potřebujete. Nikdo nechce číst commit „fix" ani „update". Takové zprávy jsou k ničemu, protože nedávají kontext. A kontext je to, co dělá historii použitelnou.

Volba mezi REST API a GraphQL není o tom, co je „modernější", ale o tom, co váš projekt skutečně potřebuje. Obě technologie řeší komunikaci mezi klientem a serverem, ale každá k tomu přistupuje jinak. Než se rozhodnete, položte si tři otázky: jaká je struktura vašich dat, kdo bude API používat a jak často se mění požadavky na data. Odpovědi vám napoví, kterým směrem se vydat.

Než otevřete vývojové prostředí, mějte jasno v tom, co vlastně chcete postavit. Bez cíle skončíte u nekonečného přepisování kódu a opouštění projektů. Začněte jednoduchou aplikací, která řeší jeden konkrétní problém – třeba evidenci výdajů nebo poznámky s tagy. Takový rozsah zvládnete za pár týdnů a naučíte se základy životního cyklu aktivity, layoutů a ukládání dat. Pokud cílíte na složitou aplikaci hned napoprvé, připravte se na frustraci a časté restarty.

Na co si dát pozor při výběru a implementaci GraphQL ale není bez nástrah. První z nich je kontrakt na straně serveru – pokud nebudete pečlivě definovat typy a resolvery, snadno vytvoříte nepřehledný chaos, který se obtížně udržuje. Druhým úskalím je ochrana proti příliš hlubokým nebo rozsáhlým dotazům. Jednoduchý útočník může poslat dotaz na tisíce vnořených položek a zahltit server. Musíte proto nastavit limity na hloubku dotazu a velikost odpovědi. REST je v tomto ohledu bezpečnější, protože endpointy mají pevnou strukturu a server kontroluje, co se vrací.

Důležité je také pojmenování větví. Používejte strukturu, která napoví, co se ve větvi řeší, a klidně přidejte i ID úkolu z vašeho trackeru. Například feature/oprava-prihlaseni-123 je mnohem lepší než test2. Srozumitelné názvy vám ušetří čas při hledání, která větev je která, a usnadní komunikaci v týmu. Vyhněte se obecným názvům jako bugfix nebo update.

Základní chybou je odpovídat okamžitě konkrétním datem. Zkuste místo toho říct: „Potřebuji si projít zadání a ověřit kapacitu, do dvou hodin vám pošlu odhad s tím, co může ovlivnit termín." Tím získáte čas na reálné zhodnocení a zároveň ukazujete, že k problému přistupujete zodpovědně. Pokud odpovíte hned, máte tendenci vycházet z prvního dojmu a podcenit skryté závislosti – a přesně tady vznikají pozdější problémy.

Typickou chybou je ale i opačný extrém – zbytečné podceňování z obavy, abyste neslíbili moc. Pak zákazník dostane práci dřív, než čekal, a začne pochybovat, jestli jste odvedli vše pořádně. Proto se držte reálného odhadu, který odpovídá vaší zkušenosti s podobnými projekty. Pokud si nejste jistí, přidejte rezervu, ale vysvětlete ji jako pojistku proti nepředvídatelným událostem, ne jako výmluvu předem.