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.
Testování mobilních aplikací se často omezuje na jedno zařízení a jednu verzi systému. Výsledkem je aplikace, která funguje na vývojářově telefonu, ale u části uživatelů padá při startu nebo zobrazuje rozbité rozvržení. Chyba nebývá v kódu jako takovém, ale v tom, že se testuje příliš úzký vzorek prostředí. Prvním krokem proto je sestavit matici zařízení podle skutečných dat o uživatelích, ne podle toho, co je po ruce.
Obrázky patří mezi největší soubory, ale jejich vliv se dá snadno omezit. Používejte moderní formáty, které při stejné kvalitě váží méně než starší typy. Nastavte jim pevné rozměry, aby se stránka při načítání neposouvala. U obrázků, které nejsou hned vidět, zvažte odložené načtení — prohlížeč je stáhne, až když se k nim uživatel posune. Pozor na kompresi: příliš agresivní nastavení sice zmenší soubor, ale kvalita může být znatelně horší, což si lidé všimnou.
Délka funkcí je druhý častý problém. Funkce přesahující obrazovku obvykle řeší víc úkolů najednou. Rozděl ji podle toho, co dělá: jedna načte data, druhá je upraví, třetí vykreslí výsledek. Nemusí to být dokonalé, ale každá část musí jít pochopit samostatně. Vyhni se hlubokému vnořování podmínek. Místo pěti úrovní if použij návraty před cyklem nebo pomocnou funkci.
Vývoj v Swiftu je řemeslo. Nejde o to naučit se všechny konstrukce jazyka, ale o to vědět, kdy kterou použít. Když budete dbát na správu paměti, jasný tok stavu a testování na reálném zařízení, předejdete většině problémů, které jinak řešíte až ve chvíli, kdy si na ně stěžují uživatelé.
Verzovací systém není nástroj, který si nastavíte jednou a pak na něj zapomenete. U webových projektů se do něj sahá několikrát denně, takže záleží hlavně na návycích. První krok nejsou příkazy, ale rozhodnutí, co vlastně chcete sledovat. Do repozitáře patří zdrojové soubory, konfigurace šablon, skripty sestavení a dokumentace. Naopak závislosti stažené správcem balíčků, výstupní složky sestavení, lokální konfigurace s hesly a nahrané soubory od uživatelů tam nepatří.
Rychlost načítání webu nezávisí jen na velikosti obrázků. Mnohem častěji ji sráží něco, co na první pohled není vidět: synchronní skripty v hlavičce, příliš mnoho požadavků na externí soubory nebo špatně nastavené cachování. Než začnete zmenšovat fotky, podívejte se do nástrojů pro měření výkonu, které jsou součástí moderních prohlížečů. Ukážou vám přesný čas, kdy se co na stránce vykresluje, a odhalí, který prvek blokuje zobrazení.
Stav aplikace a životní cyklus obrazovky Dalším častým zdrojem chyb je práce se stavem. V moderním Swiftu se používá kombinace struktur a pozorovatelných objektů. Pokud si nejste jistí, kde má data žít, držte se jednoduchého pravidla: stav, který se týká jedné obrazovky, patří do dané obrazovky. Stav, který sdílí více obrazovek, patří výš do hierarchie. Když to porušíte, vzniknou nekonzistence, kdy jedna část aplikace zobrazuje stará data a druhá nová. Pomůže vám také pochopit, kdy se obrazovka znovu vytváří a kdy jen aktualizuje. Právě tady se nejčastěji ztrácejí data nebo se naopak zbytečně načítají znovu.
Nezapomínejte ani na to, co se děje po odeslání požadavku. Příliš mnoho přesměrování mezi doménami nebo mezi verzemi s www a bez www zdržuje každého návštěvníka. Stejně tak zbytečně velké soubory stylů, které obsahují pravidla pro celý web, i když se na stránce použije jen zlomek. Pravidelně procházejte výsledky měření a porovnávejte je v čase. Rychlost není jednorázový úkol, ale vlastnost, která se po každé úpravě může zhoršit. Sledujte tedy reálné chování uživatelů, ne jen laboratorní podmínky.
Kde začít, když chcete vidět výsledky hned Nejprve zkontrolujte, kolik souborů se na stránce načítá. Každý požadavek znamená nové spojení se serverem. Sloučení několika stylů do jednoho souboru a stejně tak skriptů často zkrátí načítání o desítky procent. Dále se zaměřte na to, co brzdí první vykreslení: skripty vložené v hlavičce bez atributu pro odložené načtení. Pokud je to jen možné, přesuňte je na konec stránky nebo použijte odložené načtení. Prohlížeč pak může začít zobrazovat obsah, aniž by čekal na jejich stažení a spuštění.