Modularitet i mobil utveckling — essens, principer och organisation

Vad \u00e4r modularitet i mobil utveckling

Modularitet \u00e4r ett s\u00e4tt att organisera kod d\u00e4r applikationen best\u00e5r av l\u00f6st kopplade moduler, var och en som tillhandah\u00e5ller strikt definierad funktionalitet genom ett offentligt gr\u00e4nssnitt. Till skillnad fr\u00e5n monolitisk arkitektur, d\u00e4r alla klasser finns i ett projekt, delar det modul\u00e4ra tillv\u00e4gag\u00e5ngss\u00e4ttet upp koden i fysiskt oberoende kompileringsenheter.

Huvudm\u00e5let med modularitet \u00e4r att hantera komplexitet. En utvecklare kan fokusera p\u00e5 en modul utan att ha hela kodbasen i huvudet. Varje modul har sitt eget ansvarsomr\u00e5de och kan utvecklas, testas och distribueras oberoende av de andra. Detta \u00e4r s\u00e4rskilt v\u00e4rdefullt i projekt med 10+ utvecklare, d\u00e4r parallellt arbete p\u00e5 en monolit leder till frekventa sammanslagningskonflikter.

Det \u00e4r viktigt att skilja modularitet fr\u00e5n skiktad arkitektur. Skikten (Presentation, Domain, Data) delar upp kod efter tekniskt kriterium, medan moduler delar upp efter funktionellt kriterium. Modulen \u201cAnv\u00e4ndarprofil\u201d kan inneh\u00e5lla egna skikt inuti sig. I praktiken kombineras modul\u00e4rt tillv\u00e4gag\u00e5ngss\u00e4tt och skiktad arkitektur: varje modul har sin egen treskiktsstruktur.

Typer av moduler och deras syfte

Feature-moduler \u2014 den mest popul\u00e4ra typen av moduler. Varje sk\u00e4rm eller grupp av relaterade sk\u00e4rmar l\u00e4ggs i en separat modul: Onboarding, Profile, Settings, Feed. En Feature-modul inneh\u00e5ller allt som beh\u00f6vs f\u00f6r funktionen: UI, aff\u00e4rslogik, dataskikt. Modulens gr\u00e4nser \u00e4r skyddade \u2014 andra funktioner kan inte komma \u00e5t dess interna klasser.

Core-moduler inneh\u00e5ller gemensam infrastruktur: n\u00e4tverksarbete, databas, analys, designsystem. De \u00e4r inte beroende av Feature-moduler, men Feature-moduler \u00e4r beroende av dem. Denna uppdelning garanterar att en \u00e4ndring av analys-SDK inte p\u00e5verkar n\u00e4tverksskiktet och vice versa. Core-moduler \u00e5teranv\u00e4nds mellan funktioner utan kodduplicering.

Shared-moduler f\u00f6r gemensam logik

Shared-moduler inneh\u00e5ller kod som anv\u00e4nds av flera funktioner: datamodeller, verktyg, konstanter, anpassade vyer. Huvudproblemet med shared-moduler \u00e4r risken att bli en soptipp (\u201cmisc module\u201d), d\u00e4r heterogen kod samlas \u00f6ver tid. Regel: en shared-modul ska ha ett tydligt tema, till exempel \u201cshared-ui\u201d eller \u201cshared-models\u201d.

I Android delas shared-moduler ofta upp i bibliotek med prefixet lib: lib-network, lib-database, lib-ui-components. I iOS utf\u00f6r interna Swift Packages inom Workspace samma funktioner. I praktiken begr\u00e4nsar team antalet shared-moduler till 3\u20135 f\u00f6r att inte skapa ett \u00f6verdrivet n\u00e4tverk av beroenden som komplicerar bygget.

Testmoduler och testisolering

Separata testmoduler g\u00f6r det m\u00f6jligt att k\u00f6ra tester endast f\u00f6r den \u00e4ndrade modulen, utan att k\u00f6ra hela testbasen. Detta f\u00f6rkortar CI/CD-pipelinen fr\u00e5n timmar till minuter. Moduler s\u00e4kerst\u00e4ller separation p\u00e5 byggniv\u00e5: modulen f\u00f6r n\u00e4tverksskiktet kan inte av misstag importera UI-bibliotek i tester.

Varje modul b\u00f6r ha ett tydligt definierat offentligt API. I Android uppn\u00e5s detta genom \u00e5tkomstmodifierare och api vs implementation i Gradle. I iOS \u2014 genom public/internal \u00e5tkomstmodifierare och hanterade beroenden via Package.swift. Att minska synligheten till minimum n\u00f6dv\u00e4ndigt \u00e4r en nyckelpraxis inom modul\u00e4r design.

Modularitet i Android: Gradle-moduler

Gradle st\u00f6der modul\u00e4r arkitektur inbyggt: varje modul \u00e4r en separat kompileringsenhet med sin egen build.gradle-fil. Android-projekt anv\u00e4nder en kombination av en application-modul (app) och flera library-moduler. Biblioteksmoduler kan inte k\u00f6ras som applikation men kan publiceras som AAR i f\u00f6rr\u00e5det.

Nyckelfunktionen i Gradle \u00e4r parallellbyggen av oberoende moduler. Om modulerna A, B och C inte \u00e4r beroende av varandra kompilerar Gradle dem samtidigt med alla processork\u00e4rnor. I projekt med 20+ moduler f\u00f6rkortar detta en fullst\u00e4ndig byggtid fr\u00e5n 15 till 3\u20135 minuter. Inkrementellt bygge av en \u00e4ndrad modul tar sekunder.

Gradle erbjuder tv\u00e5 typer av beroenden mellan moduler: api (transitiva) och implementation (icke-transitiva). Skillnaden \u00e4r kritisk f\u00f6r modularitet: implementation d\u00f6ljer transitiva beroenden fr\u00e5n modulens konsumenter. Om modulen :profile anv\u00e4nder :networking via implementation, vet konsumenterna av :profile inte om :networking och kan inte referera till det.

// settings.gradle — deklaration av moduler
include ':app'
include ':feature:profile'
include ':feature:settings'
include ':core:network'
include ':core:database'

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

Koden visar strukturen f\u00f6r ett modul\u00e4rt Android-projekt. Settings.gradle listar alla moduler, och build.gradle f\u00f6r varje Feature-modul anger endast de Core-moduler som beh\u00f6vs. Byggsystemet l\u00f6ser automatiskt transitiva beroenden och kompilerar modulerna i r\u00e4tt ordning.

Modularitet i iOS: Swift Package Manager och CocoaPods

Swift Package Manager (SPM) \u2014 standardverktyget f\u00f6r modularitet i iOS sedan 2019. SPM g\u00f6r det m\u00f6jligt att dela upp applikationen i Swift Packages, som var och en kan vara ett bibliotek eller en k\u00f6rbar fil. Package definierar moduler (targets) och deras beroenden via Package.swift. SPM \u00e4r integrerat i Xcode och kr\u00e4ver inga ytterligare verktyg.

CocoaPods f\u00f6rblir den huvudsakliga beroendehanteraren f\u00f6r tredjepartsbibliotek. Podfile och Podspec definierar den modul\u00e4ra strukturen, och CocoaPods genererar en workspace med separata pod-projekt. F\u00f6r projektets egen modularitet v\u00e4ljer team allt oftare SPM eftersom det \u00e4r inbyggt i Xcode och inte kr\u00e4ver installation.

I iOS-modularitet spelar \u00e5tkomstkontroll en viktig roll: public, package, internal, fileprivate och private. En modul publicerar endast de typer som m\u00e5ste vara tillg\u00e4ngliga f\u00f6r andra moduler. Interna implementeringsdetaljer d\u00f6ljs bakom internal och private-modifierare. Detta f\u00f6rhindrar uppkomsten av dolda beroenden mellan moduler.

// Package.swift — modulär struktur för iOS-projekt
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 deklarerar tv\u00e5 biblioteksprodukter: ProfileFeature och NetworkCore. ProfileFeature \u00e4r beroende av NetworkCore men vet inte om f\u00f6rekomsten av Alamofire \u2014 den \u00e4r dold inuti NetworkCore. S\u00e5dan isolering \u00e4r en direkt till\u00e4mpning av separation p\u00e5 modulniv\u00e5: \u00e4ndringar i HTTP-klienten kr\u00e4ver inte omkompilering av ProfileFeature.

F\u00f6rdelar och utmaningar med modul\u00e4r arkitektur

Den st\u00f6rsta f\u00f6rdelen med modularitet \u00e4r utvecklingshastighet. Team arbetar parallellt p\u00e5 olika moduler utan kodkonflikter. CI/CD-pipelinen bygger endast \u00e4ndrade moduler och k\u00f6r endast deras tester. \u00c5terkopplingstiden minskar och utgivningsfrekvensen \u00f6kar. Spotify, Uber och Airbnb har publicerat fall av migrering till modul\u00e4r arkitektur med 2\u20133 g\u00e5ngers f\u00f6rb\u00e4ttring av m\u00e5tt.

Den andra f\u00f6rdelen \u2014 felisolering. En bugg i Profile-modulen p\u00e5verkar inte Payments-modulen om det inte finns direkta beroenden mellan dem. Detta \u00e4r s\u00e4rskilt viktigt i applikationer med h\u00f6griskfunktioner (betalningar, medicinsk data), d\u00e4r ett fel p\u00e5 en orelaterad sk\u00e4rm inte ska blockera lanseringen av kritisk funktionalitet.

Den st\u00f6rsta utmaningen \u2014 hantering av beroenden. Vid felaktig design uppst\u00e5r en graf av moduler d\u00e4r en \u00e4ndring av en modul kaskadartat bygger om dussintals andra. L\u00f6sning \u2014 f\u00f6lj regeln om acyklicitet: modulernas beroendegraf m\u00e5ste vara en riktad acyklisk graf (DAG). Verktyg som Gradle Module Graph Assert hj\u00e4lper till att uppt\u00e4cka cykler i byggfasen.

Den andra utmaningen \u2014 \u00f6kad initial konfigurationstid. Att skapa en modul\u00e4r arkitektur kr\u00e4ver mer tid i projektets startfas. Sm\u00e5 projekt med 1\u20133 utvecklare kanske inte drar nytta av modularitet och l\u00e4gger tid p\u00e5 att underh\u00e5lla modulgr\u00e4nser utan verkligt behov av parallellisering. L\u00f6sning \u2014 b\u00f6rja med en monolit och extrahera moduler n\u00e4r teamet v\u00e4xer.

Feature-first vs layer-first-metoder

Feature-first-metoden grupperar moduler efter funktionalitet: varje sk\u00e4rm eller grupp av sk\u00e4rmar blir en separat modul. Layer-first-metoden delar upp kod efter tekniskt kriterium: separata moduler f\u00f6r UI, aff\u00e4rslogik och data. I praktiken v\u00e4ljer de flesta team feature-first med Core-moduler \u2014 detta ger b\u00e4ttre isolering och tydlig navigering i projektet.

Valet mellan metoder beror p\u00e5 teamstorlek och funktionalitetens f\u00f6ruts\u00e4gbarhet. Om du vet exakt vilka sk\u00e4rmar som kommer att finnas i projektet g\u00f6r feature-first det m\u00f6jligt f\u00f6r varje utvecklare att vara ansvarig f\u00f6r sin egen modul. Om funktionalitet ofta \u00e4ndras och \u00f6verlappar mellan sk\u00e4rmar ger layer-first st\u00f6rre flexibilitet vid \u00e5teranv\u00e4ndning av kod mellan olika funktioner.