Když začínáte s vývojem pro iOS, první věc, kterou oceníte, je rychlá zpětná vazba od simulátoru. Ale pozor: simulátor není cílové zařízení. Na skutečném iPhonu se chování liší v paměti, výkonu i v chování senzorů. Proto si hned na začátku nastavte fyzické zařízení pro testování. Propojení přes kabel je spolehlivé, ale bezdrátové ladění vám ušetří čas, pokud měníte kód často. Nezapomeňte, že pro testování na zařízení potřebujete platný vývojářský profil a podepsaný kód. Jinak se aplikace nespustí.<br>
<br>
<br>
<br>
Druhý klíčový bod je správa závislostí. Swift Package Manager je dnes standardem, ale pokud dědíte starší projekt, můžete narazit na CocoaPods. Než přidáte knihovnu, zkuste si odpovědět, jestli ji opravdu potřebujete. Každá závislost zvyšuje riziko konfliktů verzí a prodlužuje sestavování. Pokud knihovnu přidáte, vždy ji uzamkněte na konkrétní verzi a pravidelně aktualizujte. Typická chyba začátečníků je používání nejnovější verze bez čtení changelogu, což může přinést nečekané změny rozhraní.<br>
<br>
<br>
<br>
Hlídání paměti a životního cyklu Automatické počítání referencí v Swiftu vás zbaví ruční správy paměti, ale nepozornost se může vymstít. Silné cykly mezi třídami vedou k únikům paměti. Používejte slabé nebo neovládané reference tam, kde vzniká cyklus – typicky u delegátů a uzávěrů. V Xcode si zapněte nástroj pro detekci úniků a sledujte graf alokací. Pokud aplikace po opuštění obrazovky drží paměť, hledejte skryté retain cykly. Častou pastí jsou úniky v blokách, které zachycují self silně, i když stačí slabá reference.<br>
<br>
<br>
<br>
Po odeslání buďte trpěliví. Správci mají často hodně práce a odpověď nemusí přijít hned. Pokud do dvou týdnů nikdo nereaguje, můžete jemně připomenout v komentáři, ale nevyžadujte odpověď okamžitě. Běžná chyba je, že přispěvatel vezme kritiku osobně. Recenze není útok, ale snaha o kvalitu. Pokud vám někdo navrhne změny, poděkujte, zapracujte je a jasně napište, co jste upravili. Tím ukážete, že umíte spolupracovat.<br>
<br>
<br>
<br>
Častou chybou je plánovat úkoly těsně za sebou bez rezervy na přepínání kontextu. Když programátor přechází mezi dvěma úkoly, mozek potřebuje čas na obnovení souvislostí. Stejně tak schůzka uprostřed dne rozdělí práci na dva kratší bloky, které jsou méně efektivní než jeden souvislý celek. Pokud víte, že vás čeká porada, naplánujte si práci na menší celky, které lze dokončit mezi schůzkami. Do odhadu pak zahrňte také čas na zápis poznámek nebo předání informací kolegům.<br>
<br>
<br>
<br>
Začni tím, že si vybereš jednu technologii, ve které se staneš skutečně dobrým. Nejhorší, co můžeš udělat, je skákat mezi pěti jazyky a frameworky. Vyber si něco, co má poptávku na trhu a co tě baví – a v tom se zdokonaluj. Typická chyba začátečníků je učit se všechno najednou, ale výsledkem je povrchní znalost, kterou u pohovoru hned poznají. Místo toho si vytvoř malý projekt, který používá jednu technologii a který dokončíš do konce – takový projekt je tvým nejlepším argumentem.<br>
<br>
<br>
<br>
End-to-end testy by měly být jen špičkou pyramidy — obvykle 5–10 % všech testů. Testují kritické uživatelské cesty, jako je registrace, přihlášení, vytvoření objednávky apod. Spouští se v reálném prohlížeči nebo přes API, takže jejich běh trvá minuty až desítky minut. Proto je důležité, aby se nespouštěly při každé změně kódu, ale až po úspěšném průchodu nižších vrstev. To lze zařídit pomocí fází v CI: po commitu běží jen jednotkové a rychlé integrační testy, end-to-end se spouští jednou denně nebo před vydáním. Pokud byste je spouštěli po každém commitu, vývoj se zpomalí a lidé je začnou ignorovat.<br>
<br>
<br>
<br>
První příspěvek: začněte dokumentací a nenápadnými opravami Ideální první příspěvek není kód, ale dokumentace. Oprava překlepu, doplnění chybějícího kroku v návodu nebo upřesnění nejasného popisu funkce jsou neocenitelné. Méně riskujete a naučíte se pracovní postup. Najdete-li chybu v textu, zkuste ji opravit a poslat jako malou změnu. Většina projektů má pro takové případy označení "good first issue" nebo "help wanted". Ale pozor: ne každá taková issue je skutečně vhodná pro začátečníka. Přečtěte si diskuzi, podívejte se, jestli už někdo nepožádal o přiřazení, a pokud je to delší dobu bez odezvy, zeptejte se.<br>
<br>
<br>
<br>
Základním krokem je začít u jednotkových testů. Každá třída nebo funkce by měla být pokryta testy, které ověřují logiku izolovaně od okolí. To znamená používat falešné objekty (mocks, stubs) pro databáze, soubory nebo síťové služby. Dbejte na to, aby testy nebyly závislé na pořadí spuštění, na čase ani na náhodných hodnotách. Pokud jednotkový test občas selže bez změny kódu, je to varovný signál — test není deterministický a v pyramidě se chová jako časovaná bomba. Většina testů (60–70 %) by měla patřit právě sem.
