Modularita v mobilním vývoji — podstata, principy a organizace

Co je modularita v mobiln\u00edm v\u00fdvoji

Modularita je zp\u016fsob organizace k\u00f3du, p\u0159i kter\u00e9m se aplikace skl\u00e1d\u00e1 z voln\u011b propojen\u00fdch modul\u016f, z nich\u017e ka\u017ed\u00fd poskytuje p\u0159\u00edsn\u011b definovanou funkcionalitu prost\u0159ednictv\u00edm ve\u0159ejn\u00e9ho rozhran\u00ed. Na rozd\u00edl od monolitick\u00e9 architektury, kde jsou v\u0161echny t\u0159\u00eddy v jednom projektu, modul\u00e1rn\u00ed p\u0159\u00edstup rozd\u011bluje k\u00f3d na fyzicky nez\u00e1visl\u00e9 jednotky kompilace.

Hlavn\u00edm c\u00edlem modularity je \u0159\u00edzen\u00ed slo\u017eitosti. V\u00fdvoj\u00e1\u0159 se m\u016f\u017ee soust\u0159edit na jeden modul, ani\u017e by musel m\u00edt v hlav\u011b celou k\u00f3dovou z\u00e1kladnu. Ka\u017ed\u00fd modul m\u00e1 svou vlastn\u00ed oblast odpov\u011bdnosti a m\u016f\u017ee b\u00fdt vyv\u00edjen, testov\u00e1n a nasazov\u00e1n nez\u00e1visle na ostatn\u00edch. To je obzvl\u00e1\u0161t\u011b cenn\u00e9 u projekt\u016f s 10+ v\u00fdvoj\u00e1\u0159i, kde paraleln\u00ed pr\u00e1ce na monolitu vede k \u010dast\u00fdm konflikt\u016fm p\u0159i slu\u010dov\u00e1n\u00ed.

Je d\u016fle\u017eit\u00e9 odli\u0161it modularitu od vrstven\u00e9 architektury. Vrstvy (Presentation, Domain, Data) d\u011bl\u00ed k\u00f3d podle technick\u00e9ho krit\u00e9ria, zat\u00edmco moduly podle funkcion\u00e1ln\u00edho. Modul \u201eU\u017eivatelsk\u00fd profil\u201c m\u016f\u017ee obsahovat vlastn\u00ed vrstvy uvnit\u0159 sebe. V praxi se modul\u00e1rn\u00ed p\u0159\u00edstup a vrstven\u00e1 architektura kombinuj\u00ed: ka\u017ed\u00fd modul m\u00e1 svou vlastn\u00ed t\u0159\u00edvrstvou strukturu.

Typy modul\u016f a jejich \u00fa\u010del

Feature moduly \u2014 nejpopul\u00e1rn\u011bj\u0161\u00ed typ modul\u016f. Ka\u017ed\u00e1 obrazovka nebo skupina souvisej\u00edc\u00edch obrazovek je vy\u010dlen\u011bna do samostatn\u00e9ho modulu: Onboarding, Profile, Settings, Feed. Feature modul obsahuje v\u0161echno pot\u0159ebn\u00e9 pro fungov\u00e1n\u00ed funkce: UI, obchodn\u00ed logiku, datovou vrstvu. Hranice modulu jsou chr\u00e1n\u011bny \u2014 ostatn\u00ed funkce nemohou p\u0159istupovat k jeho vnit\u0159n\u00edm t\u0159\u00edd\u00e1m.

Core moduly obsahuj\u00ed spole\u010dnou infrastrukturu: pr\u00e1ci se s\u00edt\u00ed, datab\u00e1z\u00ed, analytikou, designov\u00fdm syst\u00e9mem. Nez\u00e1vis\u00ed na feature modulech, ale feature moduly z\u00e1vis\u00ed na nich. Toto rozd\u011blen\u00ed zaru\u010duje, \u017ee zm\u011bna analytick\u00e9ho SDK neovlivn\u00ed s\u00ed\u0165ovou vrstvu a naopak. Core moduly jsou znovu pou\u017e\u00edv\u00e1ny mezi funkcemi bez duplicity k\u00f3du.

Shared moduly pro spole\u010dnou logiku

Shared moduly obsahuj\u00ed k\u00f3d pou\u017e\u00edvan\u00fd n\u011bkolika funkcemi: datov\u00e9 modely, n\u00e1stroje, konstanty, vlastn\u00ed pohledy. Hlavn\u00edm probl\u00e9mem shared modul\u016f je riziko prom\u011bny ve smeti\u0161t\u011b (\u201emisc module\u201c), kde se \u010dasem hromad\u00ed r\u016fznorod\u00fd k\u00f3d. Pravidlo: shared modul by m\u011bl m\u00edt jasn\u00e9 t\u00e9ma, nap\u0159\u00edklad \u201eshared-ui\u201c nebo \u201eshared-models\u201c.

V Androidu jsou shared moduly \u010dasto vy\u010dlen\u011bny do knihoven s p\u0159edponou lib: lib-network, lib-database, lib-ui-components. V iOS stejn\u00e9 funkce pln\u00ed intern\u00ed Swift Packages v r\u00e1mci Workspace. V praxi t\u00fdmy omezuj\u00ed po\u010det shared modul\u016f na 3\u20135, aby nevytv\u00e1\u0159ely nadm\u011brnou s\u00ed\u0165 z\u00e1vislost\u00ed, kter\u00e1 komplikuje build.

Testovac\u00ed moduly a izolace testov\u00e1n\u00ed

Samostatn\u00e9 testovac\u00ed moduly umo\u017e\u0148uj\u00ed spou\u0161t\u011bt testy pouze pro zm\u011bn\u011bn\u00fd modul, bez spou\u0161t\u011bn\u00ed cel\u00e9 testovac\u00ed z\u00e1kladny. To zkracuje \u010das CI/CD pipeline z hodin na minuty. Moduly zaji\u0161\u0165uj\u00ed odd\u011blen\u00ed na \u00farovni buildu: modul s\u00ed\u0165ov\u00e9 vrstvy nem\u016f\u017ee n\u00e1hodn\u011b importovat UI knihovny v testech.

Ka\u017ed\u00fd modul by m\u011bl m\u00edt jasn\u011b definovan\u00e9 ve\u0159ejn\u00e9 API. V Androidu je toho dosa\u017eeno pomoc\u00ed p\u0159\u00edstupov\u00fdch modifik\u00e1tor\u016f a api vs implementation v Gradle. V iOS \u2014 pomoc\u00ed public/internal p\u0159\u00edstupov\u00fdch modifik\u00e1tor\u016f a spravovan\u00fdch z\u00e1vislost\u00ed prost\u0159ednictv\u00edm Package.swift. Sn\u00ed\u017een\u00ed viditelnosti na minimum nezbytn\u00e9 je kl\u00ed\u010dovou prax\u00ed modul\u00e1rn\u00edho designu.

Modularita v Androidu: moduly Gradle

Gradle podporuje modul\u00e1rn\u00ed architekturu nativn\u011b: ka\u017ed\u00fd modul je samostatn\u00e1 jednotka kompilace s vlastn\u00edm build.gradle souborem. Android projekty pou\u017e\u00edvaj\u00ed kombinaci application modulu (app) a n\u011bkolika library modul\u016f. Knihovn\u00ed moduly nelze spustit jako aplikaci, ale lze je publikovat jako AAR v repozit\u00e1\u0159i.

Kl\u00ed\u010dovou funkc\u00ed Gradle je paraleln\u00ed build nez\u00e1visl\u00fdch modul\u016f. Pokud moduly A, B a C na sob\u011b nez\u00e1vis\u00ed, Gradle je kompiluje sou\u010dasn\u011b s vyu\u017eit\u00edm v\u0161ech jader procesoru. U projekt\u016f s 20+ moduly to zkracuje \u00fapln\u00fd build z 15 na 3\u20135 minut. Inkrement\u00e1ln\u00ed build zm\u011bn\u011bn\u00e9ho modulu trv\u00e1 sekundy.

Gradle poskytuje dva typy z\u00e1vislost\u00ed mezi moduly: api (tranzitivn\u00ed) a implementation (netranzitivn\u00ed). Rozd\u00edl je kritick\u00fd pro modularitu: implementation skr\u00fdv\u00e1 tranzitivn\u00ed z\u00e1vislosti p\u0159ed spot\u0159ebiteli modulu. Pokud modul :profile pou\u017e\u00edv\u00e1 :networking p\u0159es implementation, spot\u0159ebitel\u00e9 :profile nev\u011bd\u00ed o :networking a nemohou se na n\u011bj odkazovat.

// settings.gradle — deklarace modulů
include ':app'
include ':feature:profile'
include ':feature:settings'
include ':core:network'
include ':core:database'

// build.gradle feature/profile — závislosti modulu
dependencies {
    implementation project(':core:network')
    implementation project(':core:database')
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.8.0'
}

K\u00f3d ukazuje strukturu modul\u00e1rn\u00edho Android projektu. Settings.gradle vypisuje v\u0161echny moduly a build.gradle ka\u017ed\u00e9ho feature modulu uv\u00e1d\u00ed pouze ty core moduly, kter\u00e9 pot\u0159ebuje. Build syst\u00e9m automaticky \u0159e\u0161\u00ed tranzitivn\u00ed z\u00e1vislosti a kompiluje moduly ve spr\u00e1vn\u00e9m po\u0159ad\u00ed.

Modularita v iOS: Swift Package Manager a CocoaPods

Swift Package Manager (SPM) \u2014 standardn\u00ed n\u00e1stroj modularity v iOS od roku 2019. SPM umo\u017e\u0148uje rozd\u011blit aplikaci na Swift Packages, z nich\u017e ka\u017ed\u00fd m\u016f\u017ee b\u00fdt knihovna nebo spustiteln\u00fd soubor. Package definuje moduly (targets) a jejich z\u00e1vislosti prost\u0159ednictv\u00edm Package.swift. SPM je integrov\u00e1n do Xcode a nevy\u017eaduje dal\u0161\u00ed n\u00e1stroje.

CocoaPods z\u016fst\u00e1v\u00e1 hlavn\u00edm spr\u00e1vcem z\u00e1vislost\u00ed pro knihovny t\u0159et\u00edch stran. Podfile a Podspec definuj\u00ed modul\u00e1rn\u00ed strukturu a CocoaPods generuje workspace s odd\u011blen\u00fdmi pod projekty. Pro vlastn\u00ed modularitu projektu t\u00fdmy st\u00e1le \u010dast\u011bji vol\u00ed SPM, proto\u017ee je vestav\u011bn\u00fd v Xcode a nevy\u017eaduje instalaci.

V modularit\u011b iOS hraje d\u016fle\u017eitou roli \u0159\u00edzen\u00ed p\u0159\u00edstupu: public, package, internal, fileprivate a private. Modul publikuje pouze ty typy, kter\u00e9 maj\u00ed b\u00fdt p\u0159\u00edstupn\u00e9 jin\u00fdm modul\u016fm. Intern\u00ed detaily implementace jsou skryty za internal a private modifik\u00e1tory. To br\u00e1n\u00ed vzniku skryt\u00fdch z\u00e1vislost\u00ed mezi moduly.

// Package.swift — modulární struktura iOS projektu
let package = Package(
    name: "MyApp",
    platforms: [.iOS(SupportedPlatform.iOSVersion.v17)],
    products: [
        .library(name: "ProfileFeature", targets: ["ProfileFeature"]),
        .library(name: "NetworkCore", targets: ["NetworkCore"]),
    ],
    dependencies: [
        .package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.9.0")
    ],
    targets: [
        .target(name: "ProfileFeature", dependencies: ["NetworkCore"]),
        .target(name: "NetworkCore", dependencies: ["Alamofire"]),
    ]
)

Package.swift deklaruje dva knihovn\u00ed produkty: ProfileFeature a NetworkCore. ProfileFeature z\u00e1vis\u00ed na NetworkCore, ale nev\u00ed o existenci Alamofire \u2014 ten je skryt uvnit\u0159 NetworkCore. Takov\u00e1 izolace je p\u0159\u00edmou aplikac\u00ed odd\u011blen\u00ed na \u00farovni modul\u016f: zm\u011bny v HTTP klientovi nevy\u017eaduj\u00ed p\u0159ekompilov\u00e1n\u00ed ProfileFeature.

V\u00fdhody a v\u00fdzvy modul\u00e1rn\u00ed architektury

Hlavn\u00ed v\u00fdhodou modularity je rychlost v\u00fdvoje. T\u00fdmy pracuj\u00ed paraleln\u011b na r\u016fzn\u00fdch modulech bez konflikt\u016f v k\u00f3du. CI/CD pipeline build\u00ed pouze zm\u011bn\u011bn\u00e9 moduly a spou\u0161t\u00ed pouze jejich testy. Doba zp\u011btn\u00e9 vazby se zkracuje a frekvence vyd\u00e1n\u00ed roste. Spotify, Uber a Airbnb publikovaly p\u0159\u00edpady migrace na modul\u00e1rn\u00ed architekturu se zlep\u0161en\u00edm metrik 2\u20133kr\u00e1t.

Druhou v\u00fdhodou \u2014 izolace chyb. Chyba v modulu Profile neovliv\u0148uje modul Payments, pokud mezi nimi nejsou p\u0159\u00edm\u00e9 z\u00e1vislosti. To je obzvl\u00e1\u0161t\u011b d\u016fle\u017eit\u00e9 v aplikac\u00edch s vysoce rizikov\u00fdmi funkcemi (platby, zdravotn\u00ed \u00fadaje), kde chyba na nesouvisej\u00edc\u00ed obrazovce by nem\u011bla blokovat vyd\u00e1n\u00ed kritick\u00e9 funkcionality.

Hlavn\u00ed v\u00fdzvou \u2014 \u0159\u00edzen\u00ed z\u00e1vislost\u00ed. P\u0159i nespr\u00e1vn\u00e9m n\u00e1vrhu vznik\u00e1 graf modul\u016f, kde zm\u011bna jednoho modulu kask\u00e1dovit\u011b p\u0159estavuje des\u00edtky dal\u0161\u00edch. \u0158e\u0161en\u00ed \u2014 dodr\u017eov\u00e1n\u00ed pravidla acykli\u010dnosti: graf z\u00e1vislost\u00ed modul\u016f mus\u00ed b\u00fdt orientovan\u00fd acyklick\u00fd graf (DAG). N\u00e1stroje jako Gradle Module Graph Assert pom\u00e1haj\u00ed odhalovat cykly ve f\u00e1zi buildu.

Druhou v\u00fdzvou \u2014 zv\u00fd\u0161en\u00ed \u010dasu po\u010d\u00e1te\u010dn\u00edho nastaven\u00ed. Vytvo\u0159en\u00ed modul\u00e1rn\u00ed architektury vy\u017eaduje v\u00edce \u010dasu ve f\u00e1zi zah\u00e1jen\u00ed projektu. Mal\u00e9 projekty s 1\u20133 v\u00fdvoj\u00e1\u0159i nemus\u00ed z modularity profitovat, tr\u00e1v\u00ed \u010das \u00fadr\u017ebou hranic modul\u016f bez skute\u010dn\u00e9 pot\u0159eby paralelizace. \u0158e\u0161en\u00ed \u2014 za\u010dn\u011bte s monolitem a extrahujte moduly s r\u016fstem t\u00fdmu.

Feature-first vs layer-first p\u0159\u00edstupy

Feature-first p\u0159\u00edstup seskupuje moduly podle funkcionality: ka\u017ed\u00e1 obrazovka nebo skupina obrazovek se st\u00e1v\u00e1 samostatn\u00fdm modulem. Layer-first p\u0159\u00edstup d\u011bl\u00ed k\u00f3d podle technick\u00e9ho krit\u00e9ria: samostatn\u00e9 moduly pro UI, obchodn\u00ed logiku a data. V praxi v\u011bt\u0161ina t\u00fdm\u016f vol\u00ed feature-first s core moduly \u2014 to poskytuje lep\u0161\u00ed izolaci a jasnou navigaci v projektu.

V\u00fdb\u011br mezi p\u0159\u00edstupy z\u00e1vis\u00ed na velikosti t\u00fdmu a p\u0159edv\u00eddatelnosti funkcionality. Pokud p\u0159esn\u011b v\u00edte, jak\u00e9 obrazovky budou v projektu, feature-first umo\u017e\u0148uje ka\u017ed\u00e9mu v\u00fdvoj\u00e1\u0159i b\u00fdt zodpov\u011bdn\u00fd za sv\u016fj vlastn\u00ed modul. Pokud se funkcionalita \u010dasto m\u011bn\u00ed a p\u0159ekr\u00fdv\u00e1 mezi obrazovkami, layer-first poskytuje v\u011bt\u0161\u00ed flexibilitu p\u0159i op\u011btovn\u00e9m pou\u017eit\u00ed k\u00f3du mezi r\u016fzn\u00fdmi funkcemi.