Nikdy neslibujte termín, který jste si neověřili. Typická chyba je říct „to bude hotové do týdne" hned na prvním callu. Lepší je říct: „Odhaduji to na týden, ale potřebuji si projít zadání a do zítra vám potvrdím, jestli to platí." Tím získáte čas a zákazník ocení, že nejste unáhlený. Pokud termín potvrdíte až po analýze, máte větší šanci ho dodržet.

Než změnu sloučíš, projdi si, že větev je postavená na aktuálním main, testy procházejí a historie je čitelná. Sloučení proveď tak, aby hlavní větev zůstala funkční v každém kroku. Po sloučení větev smaž; zapomenuté větve se hromadí a za půl roku nikdo neví, které ještě něco znamenají. Ať je pravidlo stejné pro všechny, včetně vedení: kdo obchází recenzi, ať to dělá vědomě a nahlas. Právě tato výjimka, ne Git, je ta věc, která týmovou spolupráci rozbíjí nejčastěji.

Odhady času jsou nejčastější zdroj konfliktů se zákazníky. Ne proto, že bychom neuměli pracovat, ale protože slibujeme termíny, které nedokážeme dodržet. Zákazník pak ztrácí důvěru a vy ztrácíte zakázku. Řešení není v lepším plánování, ale v lepší komunikaci. Tady je postup, jak mluvit o čase tak, aby to fungovalo.

Než nainstaluješ cokoli dalšího, rozhodni se, na čem budeš pracovat. Pro Android je oficiální cestou Android Studio, které obsahuje potřebné nástroje pro kompilaci, ladění i testování. Stačí jej stáhnout, nainstalovat a nechat doběhnout prvotní konfiguraci. Během ní si nainstaluj SDK pro alespoň jednu starší a jednu novější verzi systému. Emulátor si nastav tak, aby odpovídal zařízení, na kterém chceš aplikaci reálně testovat – ideálně telefon s běžným rozlišením a rozumnou pamětí.

Styl kódu nemá být předmětem debat. Odsazení, středníky, uvozovky — zvol jednu variantu a drž se jí v celém projektu. Pomůže nástroj na formátování, který se spouští při uložení souboru, a linter, který upozorní na podezřelé konstrukce. Neznamená to slepě poslouchat každé varování. Znamená to, že běžné věci neřešíš ručně a máš kapacitu na skutečné problémy.

Pojmenování je druhá věc, která rozhoduje o čitelnosti. Funkce by měla dělat to, co říká její název, a název by měl být sloveso: spocitejCenu, nactiUzivatele, zvalidujEmail. Vyhněte se zkratkám jako tmp, data2 nebo obj. Čím konkrétnější název, tím méně komentářů potřebujete. Naopak zbytečné komentáře, které popisují, co kód dělá, jen zvyšují šum. Komentář má vysvětlovat proč, ne co – třeba proč je někde zvláštní podmínka kvůli chování prohlížeče.

Ptejte se na priority, ne na datum Místo otázky „Kdy to potřebujete?" se ptejte „Co je pro vás nejdůležitější?" Zákazník často řekne, že to musí být do pátku, ale po chvíli zjistíte, že jde o jednu konkrétní funkci. Pak můžete dodat zbytek později a termín dodržíte. Pokud se ptáte na datum, dostanete datum. Pokud se ptáte na hodnotu, dostanete informaci, se kterou se dá pracovat.

U vstupů mysli na hraniční případy. Prázdný seznam, nula, záporné číslo, příliš dlouhý řetězec, hodnota na přesné hranici. Právě tam se chyby schovávají nejčastěji. Není potřeba pokrýt vše hned. Stačí jeden běžný případ a jeden hraniční. Tím získá první test reálnou hodnotu a ty zjistíš, jestli tvá funkce zvládá i to, co sis při psaní nepředstavoval.

Druhá častá chyba je příliš mnoho tvrzení v jednom testu. Když jich dáš do jednoho bloku pět, při selhání nevíš, které z nich selhalo a proč. Drž se pravidla, že jeden test ověřuje jednu věc. Název testu pak piš tak, aby popisoval očekávané chování, ne název funkce. Místo „testFunkce" použij „vrací nulu pro prázdný vstup". Za měsíc si budeš vděčný.

Až test napíšeš, spusť ho vícekrát za sebou. Pokud výsledek kolísá, test závisí na něčem vnějším, nejčastěji na čase, náhodě nebo sdíleném stavu. To se musí odstranit, jinak bude testovat spíš infrastrukturu než logiku. Dobrý první unit test je rychlý, opakovatelný a pochopitelný i pro někoho, kdo kód vidí poprvé. Když tyto tři vlastnosti splní, můžeš ho bez obav rozšiřovat o další případy.

Test, který nepadne, když kód rozbiješ, nic netestuje Nejčastější chyba prvního testu je, že projde vždy. Zkus to ověřit jednoduše: rozbij záměrně kód, který test pokrývá, a spusť test znovu. Pokud stále prochází, test neověřuje to, co si myslíš. Může to být tím, že porovnává nesprávné hodnoty, že používá příliš slabou podmínku, nebo že testuje jinou funkci, než zamýšlíš. Teprve když test po rozbití kódu selže, má smysl ho považovat za funkční.

Když se termín posouvá, řekněte to co nejdřív. Nečekejte, až bude pozdě. Zákazník nesnáší překvapení na poslední chvíli. Napište krátkou zprávu: „Narazili jsme na X, zpoždění bude Y dní, navrhuji Z." Vždy nabídněte řešení, ne jen problém. Můžete zkrátit rozsah, dodat část a zbytek později, nebo přidat zdroje. Zákazník pak vidí, že situaci řešíte, ne že se vymlouváte.