Opdel delt kode i moduler

Et enkelt, enormt delt modul gør builds langsommere og udvisker ejerskabet. Ved at opdele det i fokuserede Gradle-moduler holder du kodebasen hurtig og nem at forstå.

Hvert modul kompileres separat og kan caches. Når du ændrer én funktion, bygger Gradle kun det pågældende modul igen, ikke hele den delte kodebase.

To almindelige opdelinger er efter lag (core, data, domain) eller efter funktion (orders, profile). Vælg den grænse, der passer til den måde, dit team faktisk arbejder på.

Delte hjælpefunktioner og basistyper ligger i et core-modul, som alt kan afhænge af. Det afhænger næsten ikke af noget og ligger nederst i grafen.

Et modul bruger et andet ved at erklære det i build.gradle.kts. Funktionsmodulet afhænger af core og domain, aldrig omvendt.

Moduler skal danne en ensrettet graf. Hvis A afhænger af B, og B afhænger af A, nægter Gradle at bygge. Ved at undgå cyklusser bevarer du en ærlig struktur.

Brug implementation til at holde en afhængighed privat i dit modul. Brug kun api, når forbrugerne reelt har brug for at se disse transitive typer.

Hvert KMP-modul får sit eget commonMain, androidMain og iosMain. Opdelingen er strukturel, så platformspecifik kode forbliver organiseret i hvert modul.

Uafhængige moduler lader Gradle kompilere i parallel og genbruge caches på tværs af builds. Flere moduler, der er opdelt fornuftigt, betyder ofte mærkbart hurtigere feedback.

Modulgrænser fungerer også som linjer for ejerskab. Et team ejer sit funktionsmodul, bestemmer dets offentlige overflade og ændrer det uden at komme i vejen for andre.

Et modul pr. fil er kaos. Begynd groft, og opdel, når en del vokser, eller mange teams arbejder på den. Lad reelle problemer, ikke teori, afgøre den næste opdeling. 🙂

Du opdelte den delte kode i fokuserede moduler, holdt afhængighedsgrafen ensrettet, valgte implementation frem for api og lod reelle behov styre hver ny opdeling. 🎉