Quel est le nom de l'antagoniste opposé à «réinventer la roue»? [fermé]

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.

Non. Il n'y a pas de nom anti-modèle couramment utilisé qui couvre ce que vous décrivez.

Marteau d'or

Le marteau d'or est un outil choisi uniquement parce qu'il est sophistiqué. Il n’est ni rentable ni efficace d’accomplir la tâche prévue.

source: xkcd 801

(Malgré les votes négatifs, je maintiens cette réponse. Ce n'est peut-être pas exactement le contraire de réinventer sémantiquement la roue, mais cela correspond à tous les exemples mentionnés dans la question.)

Robert Martin utilise le terme " Framework Bound " pour désigner la conséquence négative la plus évidente de cet anti-pattern. Comme je ne pense pas qu'il existe un nom commun pour le motif lui-même, une référence à cette conséquence pourrait suffire dans la plupart des cas.

Cette page wikipedia sur " Invented Here " décrit une situation légèrement différente mais avec des résultats finaux très similaires. Décrit l'aversion d'une équipe pour la création de son propre code lorsque des fonctionnalités équivalentes peuvent être trouvées.

Je dirais que le nom est un peu trompeur cependant. Cela fait sens quand on le met en contexte avec son opposé Not Invented Here, qui à mon humble avis est à peu près synonyme de réinventer la roue.

J'ai entendu " Buy Versus Build " et " Invented Here " comme des noms anti-modèles qui invoquaient un parti pris contre le développement en interne, même s'il était logique de le faire. (Et même si l'expression "buy versus build" est censée indiquer un choix entre des alternatives viables, je trouve qu'il est généralement mentionné lorsque quelqu'un croit que "acheter" est le bon choix.)

Ne pas utiliser un canon pour tuer un moustique

Confucius

AKA Overkill

Gonfler est un terme large, mais il peut inclure ce que vous décrivez. Notre logiciel devient excessivement complexe (saturé) en raison de toutes les transformations et abstractions supplémentaires nécessaires. En outre, la complexité et les dépendances contribuent à réduire les performances / l'efficacité et à augmenter la consommation de ressources (disque, bande passante).

Si nous le souhaitons, nous pourrions clarifier avec un terme tel que des dépendances gonflées .

Je pense qu'utiliser un marteau pour casser une noix est assez proche. C'est quelque chose qui est possible, mais il faut une quantité de travail démesurée pour casser une noix de cette façon, sans qu'aucun des nombreux effets secondaires possibles ne se produise. (Et il y a tout un sac de noix à craquer ...)

La phrase présente également l’avantage de ne pas être du jargon informatique, elle peut donc être très utile pour donner un indice à une personne qui n’en a pas.

À propos, il y a une distinction à faire avec l' enfer de la dépendance . Si quelqu'un a déjà intégré toutes les complexités dans une encapsulation, ce qui crée des interfaces simples, claires et faciles à utiliser, et à condition que la pénalité en cycles de processeur ou en utilisation de la mémoire ne soit pas excessive et qu'il soit peu probable que le code encapsulé soit modifié à l'avenir. nécessaire, puis un dernier argument contre son utilisation est l’enfer de la dépendance que cela pourrait causer.

Je ne pense pas qu'il y ait d'analogue exact, mais je dirais que la sur- conception ou la sur-ingénierie sont les plus proches.

Au moins, je dirais que c'est ce qui se passait vraiment lorsque j'ai rencontré quelque chose de similaire à ce que vous décrivez.

Utiliser une bibliothèque au lieu d'écrire votre propre code pour implémenter les mêmes fonctionnalités n'est presque jamais dangereux.

Même dans votre exemple hypothétique, utiliser une bibliothèque pour remplacer "deux lignes de code" peut ne pas être nécessaire, mais cela ne vous causera probablement pas beaucoup de problèmes - si c'est vraiment une bibliothèque destinée à faire la même chose que vos deux lignes de code .

Une bibliothèque pour faire une chose simple sera également simple. Il est peu probable que vous vous donniez les maux de tête que votre question implique.

Utiliser une bibliothèque compliquée pour faire quelque chose de simple implique probablement que vous essayez de faire plus que mettre en œuvre les fonctionnalités requises.

Telles que des fonctionnalités intégrées qui ne sont pas nécessaires, préparez-vous à un avenir qui pourrait ne jamais venir, etc.

Le problème ici n’est pas vraiment l’échec de réinventer la roue en soi .

Si vous n'avez pas réinventé la roue, vous utilisez probablement un jeu de roues existant fourni par un fournisseur ou une tierce partie.

S'il s'agit d'un anti-modèle, il est généralement appelé verrouillage du fournisseur.

La sécurité d'emploi?
Vous parlez de tous les efforts pour synchroniser les choses, etc. Certaines personnes préfèrent gérer le code des autres que d’écrire le leur. Les gestionnaires, en particulier.