Android Academy · leksjon

Hvorfor modularisere

Byggehastighet, eierskap og gjenbruk.

Leksjon 1 av 413 trinn

Hvorfor modularisere er en gratis leksjon i Android Academy på CoddyKit. Dette er leksjon 1 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Android Academy, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Android Academy inneholder totalt 4 leksjoner.

Monolittproblemet

Når en Android-app vokser, ligger all koden ofte i én enkelt app-modul. Dette er en monolitt. Til å begynne med er det praktisk, men over tid blir det tungvint: Alle endringer berører den samme modulen, byggingen blir treg, og teammedlemmer kommer stadig i veien for hverandre.

Modularisering betyr å dele den ene store modulen opp i mange mindre, fokuserte Gradle-moduler. I denne leksjonen lærer De hvorfor team gjør dette, og hvilke konkrete fordeler det gir.

Hva en modul faktisk er

I Gradle er en modul en kodeenhet som kan bygges uavhengig, med sin egen build.gradle.kts-fil. Appen har allerede minst én: :app-modulen. De deklarerer alle moduler i settings.gradle.kts.

Det er så enkelt som å inkludere en modul. Hver modul produserer sitt eget byggresultat og kan være avhengig av andre moduler.

// settings.gradle.kts
include(":app")
include(":core:designsystem")
include(":core:data")
include(":feature:home")
include(":feature:profile")

Fordel 1: Raskere bygg

Den største praktiske fordelen er byggehastighet. Gradle kan bygge moduler parallelt og, ikke minst, bufre og hoppe over moduler der inndataene ikke er endret.

Hvis De bare redigerer :feature:profile, gjenbruker Gradle de allerede bygde resultatene fra alle andre moduler. I en monolitt kan enhver endring tvinge frem en ny kompilering av hele appen.

Parallell kjøring på tvers av moduler
Inkrementelle bygg: Bygg bare det som er endret på nytt
Bedre treffrater for ekstern hurtigbuffer og byggbuffer

// gradle.properties
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=true

Fordel 2: Tydelige grenser

Moduler håndhever grenser. Kode i én modul kan bare se det en annen modul bevisst eksponerer. Dette hindrer et sammenfiltret kaos der hver klasse griper inn i alle andre klasser.

De styrer synligheten med Gradles konfigurasjoner api og implementation. implementation holder en avhengighet privat for modulen, slik at forbrukere ikke kan bruke den ved et uhell.

// feature/profile/build.gradle.kts
dependencies {
    // Exposed to whoever depends on :feature:profile
    api(project(":core:model"))

    // Private: hidden from consumers of this module
    implementation(project(":core:network"))
}

Fordel 3: Gjenbruk

Når logikk ligger i en fokusert modul, kan De gjenbruke den overalt. En :core:designsystem-modul med temaet, fargene og de gjenbrukbare composable-funksjonene Deres kan deles av alle funksjoner.

Den samme ideen kan skaleres til flere apper: Et selskap kan dele en :core:network-modul på tvers av flere produkter i stedet for å kopiere kode.

// Any feature can pull in shared building blocks
// feature/home/build.gradle.kts
dependencies {
    implementation(project(":core:designsystem"))
    implementation(project(":core:data"))
}

Fordel 4: Teamansvar

Moduler passer naturlig med teamansvar. Betalingsteamet eier :feature:payments, og profilteamet eier :feature:profile. De kan arbeide parallelt med færre konflikter ved sammenslåing, fordi koden deres ligger i separate mapper og byggfiler.

Verktøy som en CODEOWNERS-fil kan automatisk be riktig team om kodegjennomgang, basert på modulbanen.

# .github/CODEOWNERS
/feature/payments/   @org/payments-team
/feature/profile/    @org/profile-team
/core/designsystem/  @org/platform-team

Fordel 5: Innkapsling med synlighet

Inne i en modul blir Kotlin-modifikatoren internal svært nyttig. En internal-klasse eller -funksjon er synlig bare i sin egen modul. Andre moduler kan ikke referere til den.

Dette lar Dem eksponere en liten offentlig overflate og skjule implementasjonsdetaljene, noe som er umulig å håndheve i én stor modul.

// In :core:data
// Public API other modules may use
fun interface UserRepository {
    suspend fun loadUser(id: String): User
}

// Hidden from other modules
internal class DefaultUserRepository(
    private val api: UserApi
) : UserRepository {
    override suspend fun loadUser(id: String) = api.fetch(id).toUser()
}

Kostnaden: Litt ekstraarbeid

Modularisering er ikke gratis. Hver modul tilfører en build.gradle.kts-fil som må vedlikeholdes, og De må tenke gjennom hvilken modul som eier hver del av koden. Overdreven modularisering av en liten app skaper merarbeid uten gevinst.

En tommelfingerregel er å modularisere når byggetiden er et problem, når team kolliderer, eller når De har tydelige lag som kan gjenbrukes. En hobbyapp De lager i helgen, trenger sjelden 30 moduler.

En typisk modulstruktur

En vanlig, skalerbar struktur deler modulene inn i lagene app, feature og core. :app-modulen kobler alt sammen, funksjonsmodulene inneholder skjermer rettet mot brukeren, og core-modulene inneholder delt infrastruktur.

// Conceptual project tree
// app/                  <- single entry point, wires features
// feature/
//   home/
//   profile/
//   settings/
// core/
//   designsystem/       <- theme + reusable composables
//   data/               <- repositories
//   network/            <- Retrofit/Ktor
//   model/              <- shared data classes

Konvensjonsprogramtillegg holder orden

Med mange moduler er det en felle å kopiere og lime inn det samme Gradle-oppsettet overalt. Team trekker ut felles konfigurasjon til konvensjonsprogramtillegg (i en build-logic-modul). Hver faktiske modul bruker deretter ett programtillegg i stedet for å gjenta dusinvis av linjer.

De vil se dette mønsteret i store åpen kildekode-apper som Now in Android. Foreløpig er det nok å vite målet: Hold byggfilene små og konsistente.

// feature/home/build.gradle.kts
plugins {
    // One convention plugin sets up Android + Compose + Kotlin
    id("myapp.android.feature")
}

android { namespace = "com.myapp.feature.home" }

Tankesett: Tenk i lag

Den mest nyttige mentale modellen er at avhengigheter bør flyte nedover. Funksjoner er avhengige av core, mens core ikke er avhengig av funksjoner. :app-modulen ligger helt øverst og er avhengig av alt den trenger for å sette sammen appen.

Hvis De holder denne retningen konsekvent, forblir modulgrafen ryddig, og De unngår sykluser, som De skal utforske i en senere leksjon.

// Allowed:  app -> feature -> core
// Forbidden: core -> feature (upward) or feature -> feature (sideways)
// app/build.gradle.kts
dependencies {
    implementation(project(":feature:home"))
    implementation(project(":feature:profile"))
}

Rask kontroll

Hvilken av følgende er den mest konkrete, dagligdagse fordelen team får ved å modularisere en Android-app som vokser?

Besvar den i den interaktive leksjonen

Oppsummering: Hvorfor modularisere

De har lært hvorfor team deler opp en monolitt i moduler:

Raskere bygg gjennom parallell kjøring og inkrementell bufring
Tydelige grenser ved hjelp av api/implementation og internal
Gjenbruk av core-lag som designsystem og nettverk
Teamansvar med færre konflikter ved sammenslåing

De har også sett kostnaden (flere byggfiler) og hovedregelen: Avhengigheter flyter nedover, app -> feature -> core. Deretter skal De tegne de faktiske grensene mellom feature- og core-moduler.

Gratis å komme i gang

Lær deg Kotlin med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 36
Leksjoner: 152

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Hvorfor modularisere» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Android Academy, inkludert «Hvorfor modularisere», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Android Academy inneholder totalt 4 leksjoner.

Hva lærer jeg i «Hvorfor modularisere»?

Byggehastighet, eierskap og gjenbruk. Du øver på Android Academy med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Android Academy?

Ingen tidligere erfaring er nødvendig. Android Academy på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 1 av 4.

Hvor lang tid tar leksjonen «Hvorfor modularisere»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Android Academy-leksjonen?

Ja. Alle Android Academy-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

← Tilbake til Android Academy