L' antipattern " Réinventer la roue " est assez courant - au lieu d'utiliser une solution prête à l'emploi, écrivez la vôtre à partir de zéro. La base de code s'agrandit inutilement, des interfaces légèrement différentes qui font la même chose mais qui sont légèrement différentes l'abondent, le temps perdu pour écrire (et déboguer!) Des fonctions immédiatement disponibles. Nous savons tous cela.
Mais il y a quelque chose à l'opposé du spectre. Lorsque, au lieu d’écrire votre propre fonction composée de deux lignes de code, vous importez un framework / API / bibliothèque, instanciez-le, configurez, convertissez le contexte en type de données jugé acceptable par le framework, puis appelez cette fonction unique qui répond exactement à vos besoins, deux lignes de la logique métier sous un gigaoctet de couches d’abstraction. Ensuite, vous devez maintenir la bibliothèque à jour, gérer les dépendances de construction, synchroniser les licences. Votre code d'instanciation est dix fois plus long et plus complexe que si vous veniez de "réinventer la roue".
Les raisons peuvent être variées: la direction s’oppose strictement à la "réinvention de la roue", quel que soit le coût, une personne qui exploite sa technologie préférée malgré un chevauchement marginal avec les exigences, le rôle décroissant d’un module auparavant important du système, ou une attente de développement et plus large. utilisation du cadre, qui n'arrive jamais, ou qui comprend mal le "poids" que quelques instructions d'importation / inclusion / chargement portent "dans les coulisses".
Existe-t-il un nom commun pour ce type d'anti-modèle?
(Je n'essaie pas d'entamer une discussion lorsque c'est vrai ou faux, ou s'il s'agit d'un véritable anti-modèle ou d'une quelconque opinion , c'est une simple question de nomenclature simple et objective.)
Edit: le "duplicata" suggéré parle de la super-ingénierie de son propre code pour le rendre "prêt à tout", indépendamment des systèmes externes. Cette chose pourrait dans certains cas en découler, mais elle provient généralement de "l'aversion pour réinventer la roue" - la réutilisation du code à tout prix; S'il existe une solution "prête à l'emploi" à notre problème, nous l' utilisons, peu importe à quel point cela convient et à quel prix. Privilégier la création de nouvelles dépendances par rapport à la duplication de code, sans tenir compte des coûts d'intégration et de maintenance de ces dépendances par rapport aux coûts de création et de maintenance du nouveau code.