Antipattern

En génie logiciel, les anti-patrons ou antipatterns sont des erreurs courantes de conception des logiciels. Leur nom vient du fait que ces erreurs sont apparues dès les phases de conception du logiciel, notamment par l'absence ou la mauvaise utilisation de patrons de conception, appelés design pattern en anglais.

Les anti-patrons se caractérisent souvent par une lenteur excessive du logiciel, des coûts de réalisation ou de maintenance élevés, des comportements anormaux et la présence de bugs.

Il existe également les GreyPatterns (dont le bénéfice ou les inconvénients ne sont pas clairement établis).

Anti-patrons de développement

Abstraction inverse

L'abstraction inverse se produit lorsque l'on construit un objet logiciel avec une interface qui n'offre pas des fonctions dont les développeurs qui l'utilisent ont besoin, alors qu'il pourrait les offrir. L'interface n'offre que des fonctions plus complexes. Le résultat est que l'utilisateur de l'objet doit se servir des fonctions complexes fournies par l'objet pour programmer un comportement simple.

Exemple : avoir un objet qui ne fait que des calculs en virgule flottante, et être obligé d'utiliser cet objet pour faire du calcul avec des entiers.

Action à distance

L'action à distance se caractérise par l'emploi immodéré de variables globales ou des interdépendances accrues entre objets.

Ancre de bateau

L'ancre de bateau est un composant inutilisé mais qui est gardé dans le logiciel pour des raisons politiques, en pensant que ce code servira plus tard.

Attente active

L'attente active désigne une boucle qui ne contient qu'une instruction : tester une condition, jusqu'à ce qu'elle soit enfin vérifiée, et que le morceau de code puisse poursuivre son déroulement. Cet anti-pattern est courant en programmation concurrente, car c'est un autre processus qui doit modifier des variables pour pouvoir « libérer » la boucle d'attente active. L'attente est active puisque le processus qui attend consomme du temps machine, ce qui constitue un gaspillage. On peut s'affranchir de cette mauvaise technique grâce à la programmation événementielle, ou bien par l'utilisation de signaux. Dans certains cas (Spinlock), cette technique est utilisée délibérément pour éviter un de-scheduling du thread qui vérifie la condition, car le programmeur attend que cette condition soit vérifiée d'ici peu.

Interblocages et famine

Interblocages et famine sont des erreurs courantes dues à une mauvaise conception des parties concurrentes du logiciel (par exemple lors de l'utilisation de threads). Elles se manifestent lorsque plusieurs morceaux de code veulent utiliser une ou plusieurs ressources en même temps, et que la stratégie d'allocation des ressources est viciée ou inexistante. Cela se traduit par des performances altérées, voire des « plantages ».

Erreur de copier/coller

La duplication de code sans vérification entraîne des incohérences. La meilleure solution étant encore de factoriser les parties communes au lieu de les dupliquer.

Programmation spaghetti

Ceci fait référence à l'image d'un plat de spaghetti, dans lequel il serait impossible de modifier une petite partie du logiciel sans altérer le fonctionnement de tous les autres composants.

Réinventer la roue (carrée)

Par analogie à l'inutile réinvention de la roue, la roue carrée fait référence au fait de mal réinventer une solution existante ou bien de réinventer une mauvaise solution, non existante de ce fait.

Surcharge des interfaces

La surcharge des interfaces fait référence à des pratiques courantes en conception d'interfaces utilisateurs Web, où plusieurs boutons ont le même effet.

L'objet divin

L'objet divin est un composant du logiciel assurant trop de fonctions essentielles. C'est le contraire de la méthode diviser pour régner.

Le panier de données

Le panier de données consiste à créer une structure de données complexe qui sera ensuite passée à des fonctions qui vont puiser à l’intérieur pour n'en utiliser que quelques-unes. Pour illustrer cet anti-pattern, imaginons une fonction qui n'a besoin comme arguments que d'un nom et d'un prénom, mais pour laquelle nous lui passons directement un objet contact possédant le nom et le prénom mais aussi l'adresse, le téléphone et l'email. Le développeur ne peut donc pas distinguer facilement les données réellement attendues par cette fonction ce qui rendra plus difficile la compréhension, la maintenance, la testabilité et la refactorisation de cette fonction.

Vous n'en aurez pas besoin

Ne pas respecter le concept YAGNI (de l'anglais You Aren't Gonna Need It)^[1] est un anti-pattern. Le concept YAGNI dit qu'il ne faut pas implémenter maintenant quelque chose dont on pense qu'il sera utile plus tard.

Le respecter excessivement est également un anti-patron. En effet, l'anticipation des besoins est essentielle à la mise en œuvre d'un noyau logiciel solide, c'est-à-dire d'un noyau dont la modification (complexe par nature) n'est que rarement nécessaire. Cette erreur fait partie de celles pouvant conduire au plat de spaghetti.

Anti-patrons architecturaux

ArchitectureAsRequirements

Ceci consiste à spécifier une architecture par simple préférence ou parce qu'elle est nouvelle, alors qu'il n'y en a pas besoin et que le client n'en a pas exprimé le désir.

ArchitectureByImplication

Ceci consiste à ne pas documenter l'architecture utilisée par un projet et à ne pas la spécifier.

Coulée de lave

La coulée de lave se produit lorsqu'une partie de code encore immature est mise en production, forçant la lave à se solidifier en empêchant sa modification.

Syndrome du Deuxième Système

Problème de refactoring, lors de la réécriture d'un système avec trop de confiance il est possible d'aboutir à une architecture en sur-design qui se retrouve être lourde et inadaptée^[2].

Marteau doré

Quand on n'a qu'un marteau, tous les problèmes ressemblent à des clous. Cette conception consiste à réutiliser une technologie familière de manière obsessionnelle appliquée à beaucoup de problèmes.

Singleton

Le pattern Singleton est largement considéré comme un antipattern en génie logiciel en raison de ses implications négatives sur la modularité, la testabilité et l'évolutivité des applications. Le Singleton vise à garantir qu'une classe ne possède qu'une seule instance dans tout le système, ce qui peut sembler bénéfique pour le partage d'état global. Cependant, il introduit des dépendances cachées et rend les classes dépendantes fortement couplées au Singleton, rendant ainsi le code difficile à maintenir et à tester. Les singletons ont tendance à créer un état global implicite, ce qui rend le comportement de l'application difficile à prévoir et à comprendre. De plus, lorsqu'il est mal implémenté, le Singleton peut entraîner des problèmes de concurrence dans les environnements multithread, introduisant des bugs difficiles à détecter. Dans l'ensemble, en raison de ces effets négatifs sur la qualité du code et la flexibilité du système, le pattern Singleton est généralement évité au profit d'approches telles que l'injection de dépendances pour gérer les instances uniques de manière plus contrôlée et modulaire.

Voir aussi

• Grande boule de boue
• Détection d'anti-patrons de conception dans les architectures orientées services
• Code smell

Notes et références

• Portail de la programmation informatique