Pourquoi modulariser
Vitesse de compilation, responsabilité et réutilisation.
Pourquoi modulariser est une leçon Android Academy gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Android Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Android Academy comprend 4 leçons au total.
Le problème du monolithe
Lorsqu'une application Android prend de l'ampleur, tout son code se trouve souvent dans un seul module app. C'est un monolithe. Au début, c'est pratique, mais avec le temps, cela devient pénible : chaque modification touche le même module, les compilations ralentissent et les membres de l'équipe se gênent constamment.
La modularisation consiste à diviser ce grand module en de nombreux modules Gradle plus petits et spécialisés. Dans cette leçon, vous découvrirez pourquoi les équipes font cela et quels avantages concrets elles en tirent.
Ce qu'est réellement un module
Dans Gradle, un module est une unité de code qui peut être compilée indépendamment et qui possède son propre fichier build.gradle.kts. Votre application en possède déjà au moins un : le module :app. Vous déclarez chaque module dans settings.gradle.kts.
Ajouter un module est aussi simple que de l'inclure. Chaque module produit sa propre sortie de compilation et peut dépendre d'autres modules.
// settings.gradle.kts
include(":app")
include(":core:designsystem")
include(":core:data")
include(":feature:home")
include(":feature:profile")Avantage 1 : des compilations plus rapides
Le principal avantage pratique est la vitesse de compilation. Gradle peut compiler les modules en parallèle et, surtout, mettre en cache et ignorer les modules dont les entrées n'ont pas changé.
Si vous modifiez uniquement :feature:profile, Gradle réutilise les sorties déjà compilées de tous les autres modules. Dans un monolithe, toute modification peut forcer la recompilation de l'ensemble de l'application.
- Exécution en parallèle entre les modules
- Compilations incrémentielles : recompiler uniquement ce qui a changé
- Meilleurs taux d'utilisation du cache distant et du cache de compilation
// gradle.properties
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=trueAvantage 2 : des limites claires
Les modules imposent des limites. Le code d'un module ne peut voir que ce qu'un autre module expose délibérément. Cela évite le code spaghetti inextricable où chaque classe accède à toutes les autres.
Vous contrôlez la visibilité avec les configurations Gradle api et implementation. implementation garde une dépendance privée au module ; les consommateurs ne peuvent pas l'utiliser accidentellement.
// 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"))
}Avantage 3 : la réutilisation
Une fois qu'une logique réside dans un module spécialisé, vous pouvez la réutiliser partout. Un module :core:designsystem contenant votre thème, vos couleurs et vos composables réutilisables peut être partagé par chaque fonctionnalité.
La même idée s'applique à plusieurs applications : une entreprise peut partager un module :core:network entre plusieurs produits au lieu de copier le code.
// Any feature can pull in shared building blocks
// feature/home/build.gradle.kts
dependencies {
implementation(project(":core:designsystem"))
implementation(project(":core:data"))
}Avantage 4 : responsabilité des équipes
Les modules correspondent naturellement à la responsabilité des équipes. L'équipe chargée des paiements possède :feature:payments ; l'équipe chargée du profil possède :feature:profile. Elles peuvent travailler en parallèle avec moins de conflits de fusion, car leur code se trouve dans des dossiers et des fichiers de compilation distincts.
Des outils comme un fichier CODEOWNERS peuvent automatiquement demander des révisions à l'équipe appropriée en fonction du chemin du module.
# .github/CODEOWNERS
/feature/payments/ @org/payments-team
/feature/profile/ @org/profile-team
/core/designsystem/ @org/platform-teamAvantage 5 : encapsulation par visibilité
À l'intérieur d'un module, le modificateur internal de Kotlin devient très puissant. Une classe ou une fonction internal n'est visible qu'au sein de son propre module. Les autres modules ne peuvent littéralement pas y faire référence.
Vous pouvez ainsi exposer une petite interface publique et masquer les détails d'implémentation, ce qu'il est impossible d'imposer dans un unique module gigantesque.
// 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()
}Le coût : une certaine surcharge
La modularisation n'est pas gratuite. Chaque module ajoute un fichier build.gradle.kts à maintenir et vous devez réfléchir au module auquel appartient chaque partie du code. Une modularisation excessive d'une petite application crée du travail inutile sans réel bénéfice.
La règle générale : modularisez lorsque les temps de compilation deviennent problématiques, lorsque les équipes se gênent ou lorsque vous disposez de couches clairement réutilisables. Une application de loisir développée le week-end a rarement besoin de 30 modules.
Une organisation typique des modules
Une structure courante et évolutive répartit les modules en couches app, feature et core. Le module :app relie tous les éléments ; les fonctionnalités contiennent les écrans destinés aux utilisateurs ; les modules core contiennent l'infrastructure partagée.
// 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 classesLes plugins de convention simplifient la gestion
Avec de nombreux modules, copier-coller la même configuration Gradle partout est un piège. Les équipes extraient la configuration partagée dans des plugins de convention (au sein d'un module build-logic). Chaque module réel applique alors un seul plugin au lieu de répéter des dizaines de lignes.
Vous retrouverez ce modèle dans de grandes applications open source comme Now in Android. Pour le moment, retenez simplement l'objectif : garder des fichiers de compilation courts et cohérents.
// feature/home/build.gradle.kts
plugins {
// One convention plugin sets up Android + Compose + Kotlin
id("myapp.android.feature")
}
android { namespace = "com.myapp.feature.home" }État d'esprit : penser en couches
Le modèle mental le plus utile est le suivant : les dépendances doivent aller vers le bas. Les fonctionnalités dépendent du core ; le core ne dépend pas des fonctionnalités. Le module :app se trouve tout en haut et dépend de tout ce dont il a besoin pour assembler l'application.
Si vous conservez cette direction, le graphe de vos modules reste clair et vous évitez les cycles, que vous étudierez dans une leçon ultérieure.
// 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"))
}Vérification rapide
Lequel des éléments suivants constitue l'avantage concret et quotidien le plus important que les équipes retirent de la modularisation d'une application Android qui grandit ?
Récapitulatif : pourquoi modulariser
Vous avez appris pourquoi les équipes transforment un monolithe en modules :
- Des compilations plus rapides grâce à l'exécution en parallèle et à la mise en cache incrémentielle
- Des limites claires avec
api/implementationetinternal - La réutilisation des couches core comme le système de conception et le réseau
- La responsabilité des équipes avec moins de conflits de fusion
Vous avez également vu le coût (des fichiers de compilation supplémentaires) et la règle d'or : les dépendances vont vers le bas, app -> feature -> core. Ensuite, vous tracerez les limites concrètes entre les modules feature et core.
Apprends Kotlin avec un tuteur IA — gratuit
Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.
- Cours
- 36
- Leçons
- 152
Questions Fréquemment Posées
La leçon « Pourquoi modulariser » est-elle gratuite ?
Oui — le texte complet de « Pourquoi modulariser » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Android Academy, passe à CoddyKit PRO. Le cours Android Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Pourquoi modulariser » ?
Vitesse de compilation, responsabilité et réutilisation. Tu pratiques Android Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Android Academy ?
Aucune expérience préalable n'est requise. Android Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.
Combien de temps prend la leçon « Pourquoi modulariser » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Android Academy ?
Oui. Chaque leçon Android Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Pourquoi modulariser
- Modules de fonctionnalités et modules centraux
- Gérer les dépendances entre modules
- Navigation entre modules