Volba licence podle počtu uživatelů, ne podle kódu

Pozor na práci s testy, které jen zvyšují pokrytí. Často vznikají tak, že se testuje privátní metoda přes veřejné rozhraní, ale bez kontroly stavu. Takový test projde, i když logika vrátí špatný výsledek. Místo toho se zaměř na chování: co má funkce vrátit, jaké chyby má vyhodit, jak se změní stav. Pokud test neumí selhat při změně logiky, nemá cenu. Stejně tak nepomůže testovat gettery a settery jen proto, aby vyskočilo procento.

Pomáhá i to, když odhad rozložíte na části. Místo jednoho velkého data uveďte milníky: „do pátku bude hotová analýza, do dalšího týdne prototyp, finální verze pak podle toho, co vyplyne z prototypu." Zákazník vidí, že se něco děje, a vy máte přirozené kontrolní body, kde můžete odhad zpřesnit. Zároveň tím zabráníte tomu, aby se celý projekt hodnotil podle jednoho data na konci.

Swift je dnes jediná rozumná volba pro nové aplikace na platformách Applu. Objective-C sice stále funguje a v mnoha projektech zůstává, ale pokud začínáte od nuly, nemá smysl do něj investovat čas. Swift je bezpečnější díky silnému typovému systému, čitelnější a jeho kompilátor odhalí řadu chyb ještě před spuštěním aplikace. To se projeví hlavně ve větších projektech, kde se počet obrazovek a stavů rychle násobí.

Před pohovorem si zjistěte, na čem firma pracuje. Nejde o to znát všechny detaily, ale mít kontext. Připravte si dvě až tři otázky, které se týkají náplně práce, týmu nebo používaných technologií. Otázky na benefity a dovolenou nechte na později. Během rozhovoru mluvte konkrétně: „použil jsem relační databázi, protože data byla strukturovaná" místo „umím databáze". Pokud dostanete zpětnou vazbu, berte ji jako nástroj, ne jako útok. Odmítnutí není konec, ale informace, co zlepšit.

Testování není volitelná část. Napsat testy pro logiku, která nezávisí na rozhraní, je výrazně snazší než testovat celé obrazovky. Zaměřte se na výpočty, zpracování dat a převody stavů. Testy vám umožní měnit kód bez strachu, že něco rozbijete. Až budete chtít aplikaci vydat, projděte si přístupová oprávnění a chování na pozadí. Zbytečně široká oprávnění odrazují uživatele a zvyšují riziko odmítnutí v kontrole.

Konflikty nejsou katastrofa, ale způsob jejich řešení často bývá. Nikdy neřeš konflikt automaticky ani slepým přepsáním jedné strany. Otevři si oba konce, zjisti, co ta druhá změna sledovala, a výsledek spusť. Po každém řešení konfliktu udělej build a testy, protože právě tady vznikají tiché regrese. Pozor na rebase na sdílené větvi: přepisuje historii a kolegům rozbije jejich lokální kopie. Rebase používej na své vlastní, ještě nesdílené větvi; sdílenou větev slučuj běžným merge. Stejně tak nikdy nepushuj přes --force do větve, kterou používá někdo jiný, aniž bys ho předem varoval.

Deklarativní tvorba rozhraní mění způsob, jakým přemýšlíte o stavu. Místo ručního překreslování popíšete, jak má obrazovka vypadat pro daný stav, a systém se postará o zbytek. To je pohodlné, ale vede k jednomu častému omylu: vývojáři ukládají příliš mnoho stavu do mnoha míst najednou. Držte se pravidla, že každý stav má jediný zdroj pravdy. Jakmile začnete stejnou hodnotu udržovat na dvou místech, dřív nebo později se rozejdou a vznikne chyba, která se hledá velmi těžko.

Portfolio je důležitější než životopis. životopis řekne, kde jste studovali, ale kód ukáže, jak přemýšlíte. Věnujte pozornost čitelnosti: konzistentní názvy, krátké funkce, žádné zbytečné komentáře. Přidejte README, kde jednoduše popíšete, co projekt dělá a jak ho spustit. Pokud projekt obsahuje testy, máte výhodu. Testy nejsou formalita, ale signál, že berete kvalitu vážně. Na pohovoru se nebojte přiznat, že něčemu nerozumíte. Lhaní se rychle odhalí a je to horší než neznalost.

Asynchronní operace jsou dalším místem, kde se láme disciplína. Načítání dat ze sítě, práce se soubory nebo přístup k databázi nesmí blokovat hlavní vlákno, jinak aplikace zamrzne a uživatel odejde. Moderní jazyk nabízí nativní podporu pro asynchronní běh, která je přehlednější než dřívější vnořené bloky. Vždy ošetřete chybové stavy: výpadek připojení, prázdnou odpověď i neplatná data. Zapomenutá chybová větev je nejčastější příčina pádu aplikace v produkci.

Začněte s Xcode, ale ne slepě Vývoj probíhá v prostředí Xcode, které obsahuje editor, simulátor i nástroje pro ladění. První krok je založit projekt jako aplikaci pro jednu platformu a zvolit rozhraní postavené na deklarativním přístupu. Pokud sázíte na starší imperativní přístup, narazíte na horší udržovatelnost u dynamických obrazovek. Projekt si rozdělte na logické celky už od začátku: oddělte uživatelské rozhraní, datovou vrstvu a síťovou komunikaci. Když vše skončí v jednom souboru, po pár týdnech se v tom přestanete orientovat.