Modularitás a mobilfejlesztésben — lényeg, elvek és szervezés

Mi a modularitás a mobilfejlesztésben

Modularitás a kód olyan szervezési módja, ahol az alkalmazás lazán kapcsolódó modulokból áll, amelyek mindegyike szigorúan meghatározott funkcionalitást nyújt egy nyilvános interfészen keresztül. Ellentétben a monolitikus architektúrával, ahol az összes osztály egyetlen projektben van, a moduláris megközelítés fizikailag független fordítási egységekre osztja a kódot.

A modularitás fő célja a bonyolultság kezelése. A fejlesztő egyetlen modulra összpontosíthat anélkül, hogy az egész kódbázist a fejében tartaná. Minden modulnak megvan a saját felelősségi köre, és a többitől függetlenül fejleszthető, tesztelhető és telepíthető. Ez különösen értékes a 10+ fejlesztős projektekben, ahol a monoliton végzett párhuzamos munka gyakori összeolvasztási ütközésekhez vezet.

Fontos megkülönböztetni a modularitást a rétegezett architektúrától. A rétegek (Presentation, Domain, Data) technikai szempont szerint osztják fel a kódot, míg a modulok funkcionális szempont szerint. A „Felhasználói profil” modul saját rétegeket tartalmazhat. A gyakorlatban a moduláris megközelítés és a rétegezett architektúra kombinálódik: minden modulnak saját háromrétegű szerkezete van.

A modulok típusai és rendeltetésük

Feature modulok — a legnépszerűbb modultípus. Minden képernyő vagy kapcsolódó képernyőcsoport külön modulba kerül: Onboarding, Profile, Settings, Feed. A Feature modul tartalmaz mindent, ami a funkció működéséhez szükséges: UI, üzleti logika, adatréteg. A modul határai védettek — más funkciók nem férhetnek hozzá a belső osztályaihoz.

Core modulok tartalmazzák a közös infrastruktúrát: hálózati munka, adatbázis, analitika, dizájnrendszer. Nem függenek a Feature moduloktól, de a Feature modulok függenek tőlük. Ez a felosztás garantálja, hogy az analitikai SDK módosítása nem befolyásolja a hálózati réteget és fordítva. A Core modulok kódismétlés nélkül használhatók újra a funkciók között.

Shared modulok közös logikához

Shared modulok több funkció által használt kódot tartalmaznak: adatmodellek, segédprogramok, állandók, egyedi nézetek. A shared modulok fő problémája, hogy szemétlerakóvá („misc module”) válhatnak, ahol idővel heterogén kód halmozódik fel. Szabály: a shared modulnak egyértelmű temája legyen, például „shared-ui” vagy „shared-models”.

Androidban a shared modulokat gyakran lib előtagú könyvtárakba különítik el: lib-network, lib-database, lib-ui-components. iOS-ben ugyanezeket a funkciókat a Workspace-en belüli belső Swift Packages látják el. A gyakorlatban a csapatok 3–5 shared modulra korlátozzák a számot, hogy ne hozzanak létre túlzott függőségi hálózatot, ami bonyolítja a build-et.

Tesztmodulok és a tesztelés elkülönítése

Különálló tesztmodulok lehetővé teszik a tesztek futtatását csak a módosított modulra, anélkül, hogy a teljes tesztbázist lefuttatnák. Ez órákról percekre csökkenti a CI/CD pipeline idejét. A modulok biztosítják a szétválasztást a build szintjén: a hálózati réteg modulja véletlenül sem importálhat UI könyvtárakat a tesztekben.

Minden modulnak világosan meghatározott nyilvános API-val kell rendelkeznie. Androidban ez a hozzáférés-módosítók és az api vs implementation a Gradle-ben érhető el. iOS-ben — a public/internal hozzáférés-módosítók és a Package.swift-en keresztül kezelt függőségek révén. A láthatóság minimálisan szükségesre csökkentése a moduláris tervezés kulcsfontosságú gyakorlata.

Modularitás Androidban: Gradle modulok

Gradle natívan támogatja a moduláris architektúrát: minden modul egy különálló fordítási egység a saját build.gradle fájljával. Az Android projektek az application modul (app) és több library modul kombinációját használják. A könyvtármodulok nem indíthatók alkalmazásként, de AAR-ként publikálhatók a repozitóriumban.

A Gradle legfontosabb jellemzője a független modulok párhuzamos fordítása. Ha az A, B és C modulok nem függenek egymástól, a Gradle egyszerre, a processzor összes magját használva fordítja őket. 20+ modulos projektekben ez 15-ről 3–5 percre csökkenti a teljes build időt. A módosított modul növekményes fordítása másodperceket vesz igénybe.

A Gradle két típusú függőséget kínál a modulok között: api (tranzitív) és implementation (nem tranzitív). A különbség kritikus a modularitás szempontjából: az implementation elrejti a tranzitív függőségeket a modul fogyasztói elől. Ha a :profile modul a :networking-et implementation-ön keresztül használja, a :profile fogyasztói nem tudnak a :networking-ről és nem hivatkozhatnak rá.

// settings.gradle — modulok deklarálása
include ':app'
include ':feature:profile'
include ':feature:settings'
include ':core:network'
include ':core:database'

// build.gradle feature/profile — modul függőségei
dependencies {
    implementation project(':core:network')
    implementation project(':core:database')
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.8.0'
}

A kód egy moduláris Android projekt szerkezetét mutatja. A Settings.gradle felsorolja az összes modult, és minden Feature modul build.gradle-je csak a számára szükséges Core modulokat adja meg. A build rendszer automatikusan feloldja a tranzitív függőségeket és a megfelelő sorrendben fordítja a modulokat.

Modularitás iOS-ben: Swift Package Manager és CocoaPods

Swift Package Manager (SPM) — a modularitás szabványos eszköze iOS-ben 2019 óta. Az SPM lehetővé teszi az alkalmazás Swift Package-ekre bontását, amelyek mindegyike lehet könyvtár vagy futtatható állomány. A Package a Package.swift-en keresztül határozza meg a modulokat (targets) és azok függőségeit. Az SPM integrálódik az Xcode-ba és nem igényel további eszközöket.

CocoaPods marad a fő függőségkezelő a harmadik féltől származó könyvtárak számára. A Podfile és a Podspec határozzák meg a moduláris szerkezetet, a CocoaPods pedig egy workspace-t generál különálló pod projektekkel. A projekt saját modularitásához a csapatok egyre gyakrabban választják az SPM-et, mivel az be van építve az Xcode-ba és nem igényel telepítést.

Az iOS modularitásban a hozzáférés-szabályozás fontos szerepet játszik: public, package, internal, fileprivate és private. A modul csak azokat a típusokat publikálja, amelyeknek elérhetőnek kell lenniük más modulok számára. A belső megvalósítási részletek az internal és private módosítók mögé rejtve maradnak. Ez megakadályozza a rejtett függőségek kialakulását a modulok között.

// Package.swift — iOS projekt moduláris szerkezete
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"]),
    ]
)

A Package.swift két könyvtár terméket deklarál: ProfileFeature és NetworkCore. A ProfileFeature függ a NetworkCore-tól, de nem tud az Alamofire létezéséről — az el van rejtve a NetworkCore-ban. Az ilyen elkülönítés a modul szintű szétválasztás közvetlen alkalmazása: a HTTP kliens változtatásai nem teszik szükségessé a ProfileFeature újrafordítását.

A moduláris architektúra előnyei és kihívásai

A modularitás fő előnye a fejlesztési sebesség. A csapatok párhuzamosan dolgoznak különböző modulokon kódütközések nélkül. A CI/CD pipeline csak a módosított modulokat építi és csak azok tesztjeit futtatja. A visszacsatolási idő csökken, és a kiadások gyakorisága nő. A Spotify, az Uber és az Airbnb közzétette a moduláris architektúrára való áttérés eseteit a metrikák 2–3-szoros javulásával.

A második előny — a hibák elkülönítése. A Profile modulban lévő hiba nem befolyásolja a Payments modult, ha nincs köztük közvetlen függőség. Ez különösen fontos a magas kockázatú funkciókkal (fizetések, orvosi adatok) rendelkező alkalmazásokban, ahol egy nem kapcsolódó képernyőn lévő hiba nem blokkolhatja a kritikus funkcionalitás kiadását.

A fő kihívás — a függőségek kezelése. Helytelen tervezésnél a modulok olyan gráfja jön létre, ahol az egyik modul változtatása lépcsőzetesen tíz másik modult épít újra. Megoldás — az aciklikusság szabályának betartása: a modul függőségi gráfjának irányított aciklikus gráfnak (DAG) kell lennie. Az olyan eszközök, mint a Gradle Module Graph Assert, segítenek a ciklusok felderítésében a build fázisban.

A második kihívás — a kezdeti beállítási idő növekedése. A moduláris architektúra létrehozása több időt igényel a projekt indítási szakaszaiban. A kis, 1–3 fejlesztős projektek nem biztos, hogy profitálnak a modularitásból, időt töltve a modulhatárok karbantartásával anélkül, hogy valóban szükség lenne a párhuzamosításra. Megoldás — kezdje monolittal, és vonja ki a modulokat a csapat növekedésével.

Feature-first vs layer-first megközelítések

A Feature-first megközelítés funkcionalitás szerint csoportosítja a modulokat: minden képernyő vagy képernyőcsoport külön modullá válik. A Layer-first megközelítés technikai szempont szerint osztja fel a kódot: külön modulok az UI, az üzleti logika és az adatok számára. A gyakorlatban a legtöbb csapat a feature-first-t választja Core modulokkal — ez jobb elkülönítést és egyértelmű navigációt biztosít a projektben.

A megközelítések közötti választás a csapat méretétől és a funkcionalitás előrejelezhetőségétől függ. Ha pontosan tudja, hogy milyen képernyők lesznek a projektben, a feature-first lehetővé teszi, hogy minden fejlesztő felelős legyen a saját moduljáért. Ha a funkcionalitás gyakran változik és átfed a képernyők között, a layer-first nagyobb rugalmasságot biztosít a kód újrafelhasználásában a különböző funkciók között.