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


101

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.


52
Dépendance infernale . C'est le plus proche que je puisse penser.
Machado

5
@Machado: Bien, je dirais que l'enfer de dépendance est le résultat direct de l'abondance de cet anti-modèle; dans le cas de systèmes extrêmement complexes, cela peut résulter directement de la complexité.
SF.

27
Je l'appellerais "dépendance" analogique à Feature_creep ou Scope_creep où de plus en plus de fonctionnalités initialement non souhaitées sont ajoutées au produit.
k3b

21
Le fiasco du pad gauche est un exemple concret de ce syndrome en action.
SF.

13
Je recommande que nous commencions collectivement à parler de LeftPad.
RubberDuck

Réponses:


9

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


4
Il apparaît avec le nombre d’idées, de suggestions et de discussions qu’il a suscité, c’est tout à fait correct.
SF.

3
Je me sens sale en faisant cela.
SF.

Hein? "Il n'y a pas de XXX" est une déclaration très forte et très difficile à prouver, d'autant plus que plusieurs candidats ont été mentionnés dans les commentaires.
AnoE

1
@AnoE "Existe-t-il un nom commun pour ce type d'anti-modèle?" La preuve contenue dans les commentaires et les réponses susmentionnés implique fortement qu’il n’en existe pas. Certes, cela ne répond pas au titre, mais à la question elle-même.
Kroltan

@ ANE Vous ne pouvez pas prouver un négatif, chérie. Peut-être que le terme se cache quelque part sous un rocher à Bornéo et que nous ne sommes pas encore tombés dessus? Qu'il y ait 10 réponses au lieu de 1 avec un million de votes positifs est une preuve suffisante pour moi.

49

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


5
Un vote positif et vous pouvez également vous le procurer sur wikipedia: en.wikipedia.org/wiki/Anti-pattern , en.wikipedia.org/wiki/Law_of_the_instrument
Pierre.Sassoulas le

3
Je voudrais downvote cela si j'avais le représentant. Il ne répond pas à la question dans son ensemble, mais propose un terme (précis) qui répond à un seul des scénarios suggérés.
David

3
Le contraire a été demandé. Cela revient à insister sur le fait que "Becquerel" (rayonnement, unité est s ^ -1) peut être utilisé pour la musique à la place de Hertz (hz, unité est s ^ -1) car ils signifient tous les deux "par seconde".
Thorbjørn Ravn Andersen le

@ ThorbjørnRavnAndersen J'ai entendu de la musique assez dangereuse de mon temps.

34

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.


1
Des cadres existent pour accélérer le processus de développement. Ils sont comme une fusée de rappel: dépensés dès qu’ils sont utilisés. La solution est - la première version, où en étions nous? C'est vrai, développer un logiciel. Prochain! La maintenance est une préoccupation distincte, et je pense, ne devrait pas être importante de nos jours. Passez du cadre suivant à la solution suivante, postez-vous vite.

18

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.


13

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



8

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 .


5

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.


5

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 .


4

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.


6
Je ne pense pas vraiment que c'est la même chose. L’immobilisation du fournisseur est un résultat négatif particulier qui dépend de la solution du fournisseur, que l’utilisation du fournisseur soit rentable au moment du choix. Le PO s’interroge davantage sur un terme désignant une solution tierce lorsque le coût d’intégration est supérieur au coût de développement d’une nouvelle solution à partir de rien (et que le blocage du fournisseur n’est probablement même pas en train de se produire, dans les cas où cela développer une nouvelle solution au lieu de s’appuyer sur le fournisseur).
Ben

@Ben - Ok, j'aime mieux le framework bound, par opposition au verrouillage du fournisseur. Cette question est basée sur l’opinion et c’est la première chose qui m’est venue à l’esprit.
Jon Raynor le

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.