Antipattern

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.

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

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.

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 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 ».

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.

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.

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.

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 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 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.

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.

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.

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

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.

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].

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.