Quel est le nom de l'anti-modèle opposé à "réinventer la roue"?
L'antipattern " Réinventer la roue " est assez courant - au lieu d'utiliser une solution prête, écrivez la vôtre à partir de zéro. La base de code se développe inutilement, des interfaces légèrement différentes qui font la même chose mais légèrement abondent différemment, du temps est perdu pour écrire (et déboguer!) Des fonctions qui sont facilement disponibles. Nous le savons tous.
Mais il y a quelque chose à l'opposé du spectre. Lorsque, au lieu d'écrire votre propre fonction, c'est-à-dire deux lignes de code, vous importez un framework/API/bibliothèque, l'instanciez, configurez, convertissez le contexte en type de données acceptable par le framework, puis appelez cette fonction unique qui fait exactement ce dont vous avez besoin, deux lignes de logique métier sous un gigaoctet de couches d'abstraction. Et puis vous devez maintenir la bibliothèque à jour, gérer les dépendances de construction, synchroniser les licences, et 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: une direction s'opposant strictement à la "réinvention de la roue" quel qu'en soit le coût, quelqu'un poussant sa technologie privilégiée malgré un chevauchement marginal avec les exigences, un rôle décroissant d'un ancien module majeur du système, ou l'attente d'une expansion et plus large utilisation du cadre, qui n'arrive tout simplement jamais, ou tout simplement mal comprendre le "poids" qu'un couple d'instructions d'importation/inclusion/chargement portent "dans les coulisses".
Existe-t-il un nom commun pour ce type d'antipattern?
(Je n'essaie pas de lancer une discussion quand elle est bonne ou mauvaise, ou si c'est un vrai contre-modèle ou quoi que ce soit basé sur l'opinion, c'est une question de nomenclature simple et objective.)
Edit: le "doublon" suggéré parle de suringénierie de son propre code pour le rendre "prêt à tout", complètement à part des systèmes externes. Cette chose peut en découler dans certains cas, mais elle provient généralement de "l'aversion pour réinventer la roue" - réutilisation du code à tout prix; s'il existe une solution "toute faite" à notre problème, nous le ferons l'utilisons, peu importe à quel point elle convient et à quel prix. Favoriser de manière dogmatique la création de nouvelles dépendances plutôt que la duplication de code, avec un mépris total pour les coûts d'intégration et de maintenance de ces dépendances par rapport au coût 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 pour sa fantaisie. Il n'est ni rentable ni efficace pour effectuer 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 la roue sémantiquement, mais elle convient à 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-modèle. Comme je ne pense pas qu'il y ait 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 créer son propre code lorsque des fonctionnalités équivalentes peuvent être trouvées.
Je dirais cependant que le nom est un peu trompeur. Fait sens lorsque mis en contexte avec son contraire Not Invented Here qui à mon humble avis est à peu près synonyme de réinventer la roue.
J'ai entendu " Acheter Versus Build " et " Invented Here " comme des noms anti-modèle pour un parti pris contre le développement de choses en interne, même quand cela peut être logique de faites-le. (Et même si l'expression "acheter contre construire" est censée indiquer un choix entre des alternatives viables, je trouve que c'est généralement mentionné quand quelqu'un croit "acheter" "est le bon choix.)
N'utilisez pas de canon pour tuer un moustique
Confucius
AKA Overkill
Ballonnement est un terme large, mais il peut inclure ce que vous décrivez. Notre logiciel devient trop complexe (gonflé) en raison de toutes les transformations et abstractions supplémentaires requises, et la complexité et les dépendances elles-mêmes contribuent à des performances inférieures/moins d'efficacité et à une consommation de ressources plus élevée (disque, bande passante).
Si nous le souhaitons, nous pourrions clarifier avec un terme comme dépendances gonflées.
Je ne pense pas qu'il existe un analogue exact, mais je dirais que la conception ou la suringé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.
tiliser une bibliothèque au lieu d'écrire votre propre code pour implémenter la même fonctionnalité n'est presque jamais nuisible.
Même dans votre exemple hypothétique, l'utilisation d'une bibliothèque pour remplacer "deux lignes de code" peut ne pas être nécessaire, mais il est peu probable que cela vous cause beaucoup de peine - s'il s'agit vraiment d'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 cela vous donne les maux de tête que votre question implique.
tiliser une bibliothèque compliquée pour faire quelque chose de simple implique probablement que vous essayez de faire plus que d'implémenter les fonctionnalités requises.
Tels que d'intégrer des fonctionnalités qui ne sont pas nécessaires, de préparer un avenir qui pourrait ne jamais arriver, etc.
Le problème ici n'est pas vraiment de ne pas réinventer la roue en soi .
Je pense tiliser un marteau pour casser un écro est assez proche. C'est quelque chose qui est possible, mais il faut beaucoup de travail pour casser une noix de cette façon, sans que de nombreux effets secondaires indésirables ne se produisent. (Et il y a tout un sac de noix à casser ...)
La phrase a également l'avantage de ne pas calculer le jargon, elle peut donc être très utile pour donner un indice à quelqu'un qui n'en a pas.
Au fait, il y a une distinction à faire avec enfer de dépendance. Si quelqu'un a déjà enveloppé toutes les complexités à l'intérieur d'une encapsulation qui crée des interfaces simples, claires et faciles à utiliser, et à condition que la pénalité en cycles CPU ou en utilisation de mémoire ne soit pas excessive, et à condition que la modification future du code encapsulé ne soit probablement pas nécessaire, alors un argument restant contre son utilisation est l'enfer de dépendance qu'il pourrait causer.
Si vous n'avez pas réinventé la roue, il est fort probable que l'on utilise un jeu de roues existant fourni par un fournisseur ou un tiers.
S'il s'agit d'un anti-modèle, il est généralement appelé verrouillage du fournisseur.
Sécurité d'emploi?
Vous mentionnez tous les efforts pour garder les choses synchronisées, etc. Certaines personnes préfèrent gérer le code d'autres personnes que d'écrire le leur. Les gestionnaires, en particulier.