Définition
Code Smell
Un "code smell" est un indice qu'il y a un problème dans le code, ce n’est pas nécessairement une erreur, mais quelque chose qui mérite d’être amélioré.
Code Smell Complet (Comprehensive)
Lorsque des "odeurs" affectent l'ensemble du code, rendant son entretien difficile et complexe.
1. Complet (Comprehensive)
Les "code smells" complets touchent globalement le code, rendant le processus de maintenance ardu et complexe à gérer. Parmi ces "code smells", on retrouve :
Code dupliqué : Correspond à la présence de plusieurs morceaux de code similaires, souvent créés par une méthode de programmation "copier-coller". Ce code dupliqué pose des problèmes de maintenance, car une modification dans un segment nécessite d'être appliquée à toutes ses copies, augmentant ainsi le risque d'erreurs.
Commentaires inutiles : La présence excessive de commentaires peut souvent masquer de mauvais choix de noms de variables ou des sections de code qui devraient être réécrites pour être plus lisibles sans explications. Les commentaires superflus peuvent parfois cacher des problèmes sous-jacents dans la logique du code.
Code mort : Fait référence à des parties du code non exécutées qui persistent après des changements dans les spécifications. Ce code non utilisé complique la compréhension globale du projet et peut donner l'impression que les tests ne sont pas suffisamment rigoureux.
Définition
Surcharge (Overweighted)
Lorsqu'une partie du code devient trop grande, trop complexe ou trop lourde.
2. Surcharge (Overweighted)
La surcharge dans le code reflète les sections de code trop lourdes ou complexes. Les cas de surcharge incluent :
Classes volumineuses : Ces classes contiennent un trop grand nombre de lignes de code, regroupant potentiellement plusieurs responsabilités. Une classe volumineuse est difficile à comprendre, à tester, à maintenir et à réutiliser.
Méthodes longues : Des méthodes contenant un trop grand nombre de lignes de code deviennent difficiles à comprendre, à tester et à modifier. Elles impliquent souvent plusieurs chemins d’exécution, ce qui complique leur maintenance et débogage.
Classes "Dieu" : Aussi appelées classes omnipotentes, elles peuvent contrôler plusieurs autres classes et deviennent ainsi d'une complexité excessive. Les classes "Dieu" sont difficiles à tester, à réutiliser, et à maintenir.
Définition
Manque d'Abstraction (Lack of Abstraction)
Lorsqu'il y a un besoin d'abstraction ou de généralisation, mais que le code reste trop détaillé ou trop lié aux implémentations spécifiques.
3. Manque d'Abstraction (Lack of Abstraction)
Le manque d'abstraction se manifeste quand le code est trop spécifique et ne parvient pas à tirer parti des généralités. Les exemples incluent :
Obsession pour les types primitifs : Consiste à utiliser des types primitifs pour représenter des données complexes (comme de l’argent ou des numéros de sécurité sociale) au lieu de créer des classes spécialisées. Cela peut mener à des erreurs de types et à un manque de clarté.
Longues listes de paramètres : Les méthodes avec trop de paramètres révèlent souvent une carence en termes d'abstraction. Elles sont souvent difficiles à réutiliser et sujettes aux erreurs lorsqu'une mauvaise séquence d'arguments est utilisée.
Clumps de données : Quand des variables apparaissent fréquemment ensemble, cela suggère qu'elles devraient être regroupées dans une classe dédiée pour éviter la duplication et améliorer la clarté du code.
Surgical Shotgun : Une petite modification nécessite des changements dans plusieurs classes. Cela rend l’entretien difficile, introduit des erreurs, et provoque des confusions.
Définition
Gloutonnerie Objet (OO Gluttons)
Lorsqu'on utilise l'orienté objet de manière excessive, créant des structures ou des relations inutiles.
4. Gloutonnerie Objet (OO Gluttons)
Un excès de zèle dans l'application de la programmation orientée objet peut amener des structures trop complexes. Voici quelques exemples :
Trop de méthodes privées : Signale que la classe pourrait accomplir trop de rôles, rendant le code difficile à tester et à réutiliser.
Héritage parallèle : Oblige à créer une nouvelle sous-classe chaque fois qu'une autre sous-classe est créée. Cela pose des problèmes pour la maintenance et l'évolution du code.
Chaînes de messages : Des appels chaînés comme a().b().c() établissent des dépendances non explicites entre des objets, compliquant les tests et la maintenance.
Définition
Timidité Objet (OO Timidness)
Lorsqu'on ne tire pas suffisamment parti des principes de l'orienté objet pour résoudre un problème.
5. Timidité Objet (OO Timidness)
La timidité objet se rapporte à un manque d'application intégrale de la programmation orientée objet. Les cas pertinents sont :
Classes de données : Contiennent des attributs et des getters/setters sans aucun comportement supplémentaire, rompant ainsi l'encapsulation et augmentant le couplage.
Envie de fonctionnalités (Feature Envy) : Les méthodes qui utilisent davantage de fonctionnalités d’autres classes que de leur propre classe augmentent le couplage et rendent le code difficile à maintenir.
Attributs temporaires : Sont utilisés uniquement dans des méthodes spécifiques mais restent dans la classe, ce qui rend le code obscur et difficile à entretenir.
Définition
Nomination (Naming)
Lorsque les noms dans le code ne reflètent pas bien les rôles ou les intentions, rendant la compréhension difficile.
6. Nomination (Naming)
Les problèmes de nomination peuvent rendre le code difficile à comprendre et à maintenir. Parmi eux, on retrouve :
Type intégré dans le nom : Inclure le type d'une variable dans son nom peut compliquer la tâche si le type doit être modifié par la suite.
Nom peu communicatif : Si les noms ne décrivent pas précisément la fonction ou l'entité concernée, la lisibilité du code en souffre.
Noms inconsistants : L'utilisation incohérente de suffixes ou de termes à travers le projet peut induire en erreur ceux qui souhaitent maintenir ou développer le projet.
7. Conclusion
Les code smells ne constituent pas inévitablement des erreurs dans le code, mais signalent un code qui présente des possibilités considérables d'améliorations. Ils peuvent indiquer des faiblesses structurelles ou de l'organisation qui rendent la maintenance difficile, augmentent le risque d'erreurs ou réduisent la lisibilité du code.
A retenir :
Les "code smells" sont des indicateurs de problèmes potentiels dans le code, même s'ils ne sont pas des erreurs à proprement parler. Afin de maintenir un code clair et facile à entretenir, il est crucial de développer une sensibilité pour détecter et corriger ces "odeurs". Grâce à une identification précoce, les développeurs peuvent simplifier la maintenance et améliorer la qualité générale du code.
