Code poubelle et bordel dans les projets mobiles — signes et refactorisation

Qu’est-ce que le code poubelle en développement

Le code poubelle (aussi spaghetti code, bordel, big ball of mud) est une métaphore pour une base de code qui a perdu sa structure et s’est transformée en un enchevêtrement de dépendances. Dans ce code, toute modification à un endroit en casse un autre, et l’ajout de nouvelles fonctionnalités devient une aventure risquée.

Dans le développement mobile, le code poubelle est particulièrement critique : une application construite sur un « bordel » commence à ralentir, à planter sur les anciens appareils et a du mal à passer la revue de code. Un projet iOS sans architecture peut ne pas passer l’App Review en raison de l’instabilité.

Selon Stripe, les développeurs passent jusqu’à 42% de leur temps de travail à lire et comprendre le code existant. Dans les projets avec du code poubelle, ce chiffre dépasse 60%, rendant le développement extrêmement inefficace.

Origine des termes

Spaghetti code est le terme le plus ancien, datant des années 1970. Il décrit un code avec un flux de contrôle chaotique, rappelant des spaghettis emmêlés.

Big ball of mud est un terme introduit par Brian Foote et Joseph Yoder en 1997 pour décrire les systèmes sans architecture claire qui croissent de manière chaotique.

Pourquoi le code poubelle est dangereux pour les affaires

Le code poubelle ralentit la mise sur le marché de nouvelles fonctionnalités. L’équipe passe son temps non pas à créer de la valeur, mais à essayer de comprendre comment le code existant fonctionne et comment ne rien casser.

Selon McKinsey, les entreprises avec une faible qualité de code dépensent 20 à 40% de plus en maintenance du produit, et la vitesse de sortie des nouvelles fonctionnalités est 2 à 3 fois inférieure par rapport aux entreprises avec une haute qualité de code.

Signes de code poubelle et comment le reconnaître

Reconnaître le code poubelle peut se faire à travers un ensemble d’indicateurs objectifs, dont certains sont mesurés automatiquement. Plus les indicateurs concordent, plus le problème est grave.

Dans l’industrie, des métriques de qualité de code telles que la Complexité de Halstead, l’Indice de Maintenabilité et le Ratio de Dette Technique sont utilisées. Connaître ces métriques aide à évaluer objectivement l’état d’une base de code.

Copier-coller (duplication de code)

Le signe le plus courant de code poubelle est la répétition de blocs de code. Au lieu d’extraire une fonction commune, les développeurs copient le code d’un endroit à un autre avec des modifications minimales.

Un niveau de duplication allant jusqu’à 5% est considéré comme normal. Si la duplication dépasse 15%, c’est un signal sérieux. Des outils comme Simian et PMD Copy Paste Detector aident à identifier les copier-coller automatiquement.

Méthodes et classes longues

Une méthode de plus de 100 lignes est un signe évident de code poubelle. Une telle méthode en fait généralement trop et viole le Principe de Responsabilité Unique.

Les classes de plus de 1000 lignes de code sont également problématiques. Elles contiennent des fonctionnalités sans rapport, ce qui rend les tests, la compréhension et la modification du code difficiles.

Complexité cyclomatique élevée

La complexité cyclomatique de McCabe est une métrique qui montre le nombre de chemins indépendants dans le code. Une valeur supérieure à 15 est considérée comme problématique.

Les méthodes avec une complexité supérieure à 30 sont dans la « zone de désastre ». Elles contiennent trop de branchements, ce qui les rend impossibles à tester et comprendre sans une analyse approfondie.

Causes du code poubelle

Le code poubelle n’apparaît pas « tout seul » — il est toujours le résultat de certains processus et décisions au sein de l’équipe. Comprendre les causes aide à le prévenir à l’avenir.

Selon JetBrains Developer Ecosystem 2024, 67% des développeurs admettent écrire un code moins bon qu’ils ne le pourraient par manque de temps. C’est la principale raison de l’accumulation de dette technique.

Précipitation et délais

La cause la plus fréquente est les délais serrés. L’équipe écrit le code « comme il vient », juste pour respecter la date limite. La refactorisation, les tests et la revue de code sont remis « à plus tard ».

Le problème est que « plus tard » n’arrive jamais — de nouveaux délais apparaissent au sprint suivant, et la dette technique s’accumule comme une boule de neige.

Absence de revue de code

Sans revue de code, chaque développeur écrit dans son propre style, utilise ses propres motifs et laisse ses propres « marques ». Avec le temps, la base de code perd son uniformité.

Les équipes qui pratiquent la revue de code obligatoire pour chaque pull request ont 60% de défauts en moins en production, selon une étude SmartBear 2024.

Architecture faible dès le départ

Si un projet commence sans architecture claire, le code poubelle est inévitable. Les premières « solutions rapides » posent des fondations sur lesquelles il est difficile de construire quelque chose de qualité par la suite.

Dans le développement mobile, le choix de l’architecture (MVC, MVP, MVVM, Clean Architecture) doit être une décision consciente prise avant de commencer à écrire le code, pas un résultat de l’évolution.

Méthodes pour combattre le code poubelle

Combattre le code poubelle nécessite une approche systématique et de la discipline de toute l’équipe. Il n’existe pas un seul outil ou pratique qui résolve le problème — un ensemble de mesures est nécessaire.

Le principe principal est d’empêcher le code poubelle au stade de l’écriture, pas de le corriger après. La prévention est toujours moins chère que la refactorisation d’un « bordel » existant.

Normes de codage

Un style de code unifié est la base pour prévenir le code poubelle. Les normes de codage (Code Style) doivent être documentées et vérifiées automatiquement par des linters.

Pour iOS, on utilise SwiftLint, pour Android, Ktlint et Detekt. Configurer des règles dans un fichier de configuration permet de rejeter automatiquement les pull requests qui violent les normes.

Refactorisation régulière

La refactorisation n’est pas la correction de bugs, mais l’amélioration de la structure du code sans changer son comportement. Elle devrait faire partie intégrante du processus de développement, pas un projet séparé.

Il est recommandé de consacrer 20% du temps de chaque sprint à la refactorisation et au remboursement de la dette technique. Cela évite l’accumulation de « bordel » et maintient la vitesse de l’équipe à long terme.

Revue de code obligatoire

Chaque pull request doit être examinée par au moins un développeur. La revue de code identifie non seulement les bugs, mais aussi les violations d’architecture, les problèmes de style et les sources potentielles de code poubelle.

Une bonne pratique est une liste de vérification pour la revue de code qui inclut la vérification du copier-coller, de la longueur des méthodes, de la complexité cyclomatique et de la couverture de tests. Sans liste de vérification, les relecteurs manquent jusqu’à 50% des problèmes.

Outils pour nettoyer la base de code

Les outils modernes d’analyse de code permettent de détecter automatiquement le code poubelle, de mesurer la dette technique et de surveiller la qualité. Intégrer ces outils dans le pipeline CI/CD fournit une surveillance continue.

Il est recommandé d’utiliser au moins un analyseur statique et un outil de mesure de métriques. Supplémentairement, une plateforme d’agrégation des données de qualité de code peut être connectée.

Analyseurs statiques

• SonarQube — la plateforme leader d’analyse de qualité de code, supporte plus de 30 langages et fournit des métriques de Ratio de Dette Technique
• ESLint — le standard pour JavaScript et TypeScript, configurable via des fichiers de configuration et intégré dans les IDE
• SwiftLint — un outil obligatoire pour les projets iOS, vérifie la conformité au Guide de Style Swift

Selon SonarSource, les équipes utilisant l’analyse statique réduisent le nombre de bugs en production de 30% dès le premier trimestre après l’adoption.

Outils de mesure de métriques

CodeClimate et Codacy sont des plateformes qui agrègent les métriques de qualité de code, suivent les tendances et montrent les « points chauds » — les fichiers avec la plus grande dette technique.

Pour les projets Android, Detekt fournit plus de 100 règles d’analyse intégrées, incluant les vérifications de complexité cyclomatique, de longueur de méthodes et de duplication de code.