Náš tým pracuje celkem na devíti mobilních aplikacích a několika knihovnách, které sdílíme i s dalšími týmy v Seznamu. Při takovém počtu projektů je důležité, aby jejich správa byla co nejjednotnější. To umožňuje jednak jednodušší úpravy společné pro všechny projekty, ale také významně usnadňuje vývojářům přechod mezi nimi. V tomto článku s vámi projdu základní technologie, které jsme se rozhodli využít a vysvětlím vám také, co nás k tomu vedlo.
XcodeGen
Xcode projekt je definován pomocí několika souborů, které společně tvoří balíček xcodeproj. Ten nese informace o rozmístění souborů v rámci projektu, definuje nastavení buildu, jeho jednotlivé fáze, podpisy a další nastavení. Tato nastavení jsou uchovávána ve formátu XML a vývojář si je přehledně zobrazí v prostředí Xcode.
Pokud už jste ale měli tu čest pracovat na projektech pro iOS ve skupině vývojářů, tak víte, že řešení merge konfliktů právě v projektovém souboru rozhodně není přímočaré. Možnosti jsou vlastně dvě: buďto vzít jednu z verzí souboru a následně řešit chybějící soubory, build fáze apod., nebo složitě procházet nekonečně dlouhý XML soubor a přitom doufat, že trefíte tu změnu, kterou chcete opravdu přidat.
My jsme se rozhodli tomuto předejít použitím nástroje XcodeGen. Ten na základě jednoduchého konzolového příkazu xcodegen vygeneruje celý Xcode projekt, workspace, Info.plist, entitlementy, stáhne závislosti a další. Všechna nastavení se definují přehledně v rámci jednoho YAML souboru. V tom stačí uvést pouze základní informace o projektu a jeho specifická nastavení, ostatní položky jsou vygenerovány automaticky ve výchozím stavu.
SwiftFormat a SwiftLint
Držíme se jednotného code-style. Máme definovaná pravidla pro psaní kódu a snažíme si je vzájemně připomínat a tím držet kurz směrem k čistému a přehlednému kódu. Občas se ale hodí, že po nás kód někdo projde, upozorní na problém a případně jej rovnou opraví. Díky těmto nástrojům se diskuze při code-review můžou soustředit primárně na opravdu důležitá témata.
SwiftLint má svou vlastní fázi při kompilaci, kde projde set vývojářem definovaných pravidel. Podle nastavení potom nalezené problémy vyhodnotí pomocí varování nebo chyby a kompilaci přeruší.
SwiftFormat se spouští pomocí konzolového příkazu. K tomu využíváme Git hooks, kde jej voláme v rámci fáze pre-commit.
Architektura MVVM-C
Téma architektury by samo o sobě vydalo na samostatný článek, na druhou stranu takových článků se již na internetu dá najít celá řada, takže se zde omezím jen na stručné shrnutí.
Jako na většině projektů, i na těch našich se v začátcích pracovalo s architekturou MVC (Model-View-Controller). Na některých starších projektech, u kterých jsme zatím nedostali možnost zaměřit se na jejich přepis je k vidění stále. Zhruba před čtyřmi lety, když jsme se s rozšiřujícím se týmem začali pomalu zaměřovat na psaní nových projektů, jsme se rozhodli dát šanci architektuře MVVM-C (Model-View-ViewModel-Coordinator) a na naše zpravodajské a mediální aplikace se to i dnes ukazuje jako dobrá volba.
Oproti MVC je u MVVM-C jasnější rozdělení logiky a UI. To nám přineslo větší přehlednost kódu a také významně zkrátilo délku jednotlivých souborů, co se počtu řádků týče.
Knihovny
Obecně se řídíme jednoduchým pravidlem, čím méně externích závislostí, tím lépe. Někdy můžete mít dojem, že si použitím nějaké komponenty třetí strany ušetříte práci, pak se ale může ukázat, že tomu bylo přesně naopak. To samozřejmě neplatí vždy a i v našich projektech využíváme řadu závislostí, nad kterými nemáme kontrolu, dobře si ale vybíráme, které to budou.
Při výběru se řídíme dvěma hlavními pravidly. Knihovna musí být pravidelně udržovaná, abychom měli jistotu nasazení důležitých úprav při vydání nové verze systému nebo jazyka. Druhá otázka je o zamyšlení nad náročností vlastního řešení. Když si totiž komponentu vyvineme sami, bude specifická pro naše potřeby a budeme nad ní mít plnou kontrolu.
V Seznamu si takto sami vyvíjíme například komponentu přehrávače, jak audio, tak video. Vlastní řešení nám dává volnost při nastavování analytiky a reklamy, umožňuje implementaci zcela vlastního UI v našich firemních barvách a řadu dalších vychytávek.
CI/CD
Když děláte nějakou činnost opakovaně, stojí za to se zamyslet jak ji automatizovat. Hezkým příkladem je CI, které na našich projektech používáme primárně pro spouštění Unit testů a vytváření buildů aplikací. Díky CI odpadá nutnost manuálního spouštění testů a následné kontroly jejich výstupů.
V posledním roce jsme se zaměřili na nahrazení CD části. Dříve jsme využívali vlastního řešení psaného v Pythonu a napojeného na Slack Bota. Z hlediska udržování a nutnosti větších technických úprav jsme se ale rozhodli zvážit nové řešení. Nakonec jsme se rozhodli jít cestou fastlane. Fastlane je open-source platforma s celou řadou nástrojů a pluginů, se kterou si můžete dovolit prakticky cokoli. My jsme si k tomu ještě přidali několik skriptů v Ruby a výsledek byl na světě.
Aktuálně se nám tedy CD část spouští na základě vytvoření tagu v repozitáři. Přičemž rozlišujeme možnosti App Store a Enterprise buildů. Ty se následně automaticky nahrávají do App Store Connect resp. Firebase App Distribute. Součástí procesu je samozřejmě i nahrání dsyms do Firebase Crashlytics.
Dlouhodobá udržitelnost
Jaké technologie využijete při stavbě svého projektu, je na vás. Pokud ale stavíte aplikaci nebo knihovnu, která má být dlouhodobě udržovatelná a očekává se, že na ní nebudete pracovat sami, měli byste se ještě předtím, než se pustíte do skládání UI komponent, zamyslet nad tím, jaký standard chcete v projektu nastavit a jakým způsobem se jej hodláte dále držet.
V tomto článku jsme si v rychlosti představili několik technologií užitečných při vývoji iOS projektů. U každé z nich by se dalo zajít dost do hloubky a zároveň najít i její alternativy. To si ale v případě zájmu necháme jako prostor pro příští článek.
