Modularność w rozwoju aplikacji mobilnych — istota, zasady i organizacja

Czym jest modularność w rozwoju aplikacji mobilnych

Modularność to sposób organizacji kodu, w którym aplikacja składa się z luźno powiązanych modułów, każdy zapewniający ściśle określoną funkcjonalność poprzez publiczny interfejs. W przeciwieństwie do architektury monolitycznej, gdzie wszystkie klasy znajdują się w jednym projekcie, podejście modułowe dzieli kod na fizycznie niezależne jednostki kompilacji.

Głównym celem modularności jest zarządzanie złożonością. Programista może skupić się na jednym module, nie mając w głowie całej bazy kodu. Każdy moduł ma swoją strefę odpowiedzialności i może być rozwijany, testowany i wdrażany niezależnie od pozostałych. Jest to szczególnie cenne w projektach z 10+ programistami, gdzie równoległa praca nad monolitem prowadzi do częstych konfliktów scalania.

Ważne jest odróżnienie modularności od architektury warstwowej. Warstwy (Presentation, Domain, Data) dzielą kod według kryterium technicznego, a moduły — według funkcjonalnego. Moduł „Profil użytkownika” może zawierać własne warstwy wewnątrz siebie. W praktyce podejście modułowe i architektura warstwowa są łączone: każdy moduł ma własną trójwarstwową strukturę.

Rodzaje modułów i ich przeznaczenie

Moduły feature — najpopularniejszy rodzaj modułów. Każdy ekran lub grupa powiązanych ekranów jest wydzielona w osobny moduł: Onboarding, Profile, Settings, Feed. Moduł feature zawiera wszystko, co jest potrzebne do działania funkcji: UI, logikę biznesową, warstwę danych. Granice modułu są chronione — inne funkcje nie mają dostępu do jego wewnętrznych klas.

Moduły core zawierają wspólną infrastrukturę: pracę z siecią, bazą danych, analityką, systemem projektowym. Nie zależą one od modułów feature, ale moduły feature zależą od nich. Taki podział gwarantuje, że zmiana SDK analitycznego nie wpłynie na warstwę sieciową i odwrotnie. Moduły core są współdzielone między funkcjami bez powielania kodu.

Moduły Shared dla wspólnej logiki

Moduły Shared zawierają kod używany przez kilka funkcji: modele danych, narzędzia, stałe, niestandardowe widoki. Głównym problemem modułów shared jest ryzyko przekształcenia się w wysypisko („misc module”), gdzie z czasem gromadzi się różnorodny kod. Zasada: moduł shared powinien mieć jasną tematykę, na przykład „shared-ui” lub „shared-models”.

W Androidzie moduły shared często wydziela się jako biblioteki z prefiksem lib: lib-network, lib-database, lib-ui-components. W iOS te same funkcje pełnią wewnętrzne pakiety Swift w obrębie Workspace. W praktyce zespoły ograniczają liczbę modułów shared do 3–5, aby nie tworzyć nadmiernej sieci zależności utrudniającej kompilację.

Moduły testowe i izolacja testowania

Oddzielne moduły testowe pozwalają uruchamiać testy tylko dla zmodyfikowanego modułu, bez przeprowadzania całej bazy testów. Skraca to czas pipeline’u CI/CD z godzin do minut. Moduły zapewniają separację na poziomie kompilacji: moduł warstwy sieciowej nie może przypadkowo zaimportować bibliotek UI w testach.

Każdy moduł powinien mieć jasno określone publiczne API. W Androidzie osiąga się to poprzez modyfikatory dostępu oraz api vs implementation w Gradle. W iOS — przez modyfikatory dostępu public/internal i zarządzanie zależnościami przez Package.swift. Ograniczenie widoczności do minimum niezbędnego to kluczowa praktyka projektowania modułowego.

Modularność w Androidzie: moduły Gradle

Gradle natywnie wspiera architekturę modułową: każdy moduł to oddzielna jednostka kompilacji z własnym plikiem build.gradle. Projekty Android wykorzystują kombinację modułu application (app) i kilku modułów library. Moduły biblioteczne nie mogą być uruchomione jako aplikacja, ale mogą być publikowane jako AAR w repozytorium.

Kluczową funkcją Gradle jest równoległa kompilacja niezależnych modułów. Jeśli moduły A, B i C nie zależą od siebie, Gradle kompiluje je jednocześnie, wykorzystując wszystkie rdzenie procesora. W projektach z 20+ modułami skraca to pełną kompilację z 15 do 3–5 minut. Przyrostowa kompilacja zmodyfikowanego modułu zajmuje sekundy.

Gradle zapewnia dwa rodzaje zależności między modułami: api (tranzytywne) i implementation (nietranzytywne). Różnica jest krytyczna dla modularności: implementation ukrywa zależności tranzytywne przed konsumentami modułu. Jeśli moduł :profile używa :networking przez implementation, konsumenci :profile nie wiedzą o :networking i nie mogą do niego sięgnąć.

// settings.gradle — deklaracja modułów
include ':app'
include ':feature:profile'
include ':feature:settings'
include ':core:network'
include ':core:database'

// build.gradle feature/profile — zależności modułu
dependencies {
    implementation project(':core:network')
    implementation project(':core:database')
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.8.0'
}

Kod pokazuje strukturę modułowego projektu Android. Settings.gradle wymienia wszystkie moduły, a build.gradle każdego modułu feature wskazuje tylko te moduły core, których potrzebuje. System kompilacji automatycznie rozwiązuje zależności tranzytywne i kompiluje moduły we właściwej kolejności.

Modularność w iOS: Swift Package Manager i CocoaPods

Swift Package Manager (SPM) — standardowe narzędzie modularności w iOS od 2019 roku. SPM pozwala dzielić aplikację na pakiety Swift, z których każdy może być biblioteką lub plikiem wykonywalnym. Package definiuje moduły (targets) i ich zależności poprzez Package.swift. SPM jest zintegrowany z Xcode i nie wymaga dodatkowych narzędzi.

CocoaPods pozostaje głównym menedżerem zależności dla bibliotek zewnętrznych. Podfile i Podspec określają strukturę modułową, a CocoaPods generuje workspace z oddzielnymi projektami pod. Dla własnej modularności projektu zespoły coraz częściej wybierają SPM, ponieważ jest wbudowany w Xcode i nie wymaga instalacji.

W modularności iOS ważną rolę odgrywa kontrola dostępu: public, package, internal, fileprivate i private. Moduł publikuje tylko te typy, które mają być dostępne dla innych modułów. Wewnętrzne szczegóły implementacji są ukryte za modyfikatorami internal i private. Zapobiega to powstawaniu ukrytych zależności między modułami.

// Package.swift — modułowa struktura projektu iOS
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 dwa produkty biblioteczne: ProfileFeature i NetworkCore. ProfileFeature zależy od NetworkCore, ale nie wie o istnieniu Alamofire — jest on ukryty wewnątrz NetworkCore. Taka izolacja to bezpośrednie zastosowanie separacji na poziomie modułów: zmiany w kliencie HTTP nie wymagają ponownej kompilacji ProfileFeature.

Zalety i wyzwania architektury modułowej

Główną zaletą modularności jest szybkość tworzenia oprogramowania. Zespoły pracują równolegle nad różnymi modułami bez konfliktów w kodzie. Pipeline CI/CD kompiluje tylko zmodyfikowane moduły i uruchamia tylko ich testy. Czas uzyskania informacji zwrotnej skraca się, a częstotliwość wydań rośnie. Spotify, Uber i Airbnb publikowały przypadki migracji do architektury modułowej z poprawą metryk 2–3 razy.

Drugą zaletą jest izolacja błędów. Błąd w module Profile nie wpływa na moduł Payments, jeśli nie ma między nimi bezpośrednich zależności. Jest to szczególnie ważne w aplikacjach z funkcjami wysokiego ryzyka (płatności, dane medyczne), gdzie błąd w niepowiązanym ekranie nie powinien blokować wydania krytycznej funkcjonalności.

Głównym wyzwaniem jest zarządzanie zależnościami. Przy nieprawidłowym projektowaniu powstaje graf modułów, w którym zmiana jednego modułu kaskadowo przebudowuje dziesiątki innych. Rozwiązanie — przestrzeganie zasady acykliczności: graf zależności modułów powinien być skierowanym grafem acyklicznym (DAG). Narzędzia takie jak Gradle Module Graph Assert pomagają wykrywać cykle na etapie kompilacji.

Drugim wyzwaniem jest wydłużenie czasu początkowej konfiguracji. Tworzenie architektury modułowej wymaga więcej czasu na etapie inicjalizacji projektu. Małe projekty z 1–3 programistami mogą nie odnieść korzyści z modularności, tracąc czas na utrzymywanie granic modułów bez rzeczywistej potrzeby parallelizacji. Rozwiązanie — zaczynać od monolitu i wydzielać moduły w miarę wzrostu zespołu.

Podejścia Feature-first vs layer-first

Feature-first grupuje moduły według funkcjonalności: każdy ekran lub grupa ekranów staje się osobnym modułem. Podejście layer-first dzieli kod według kryterium technicznego: osobne moduły dla UI, logiki biznesowej i danych. W praktyce większość zespołów wybiera feature-first z modułami core — daje to lepszą izolację i przejrzystą nawigację po projekcie.

Wybór między podejściami zależy od wielkości zespołu i przewidywalności funkcjonalności. Jeśli dokładnie wiesz, jakie ekrany będą w projekcie, feature-first pozwala każdemu programiście odpowiadać za swój moduł. Jeśli funkcjonalność często się zmienia i przenika między ekranami, layer-first daje większą elastyczność przy ponownym wykorzystaniu kodu między różnymi funkcjami.