Réinventer la roue est-il vraiment si mauvais?


103

Sa connaissance commune en programmation est que réinventer la roue est un mal ou un mal .

Mais pourquoi ça?

Je ne dis pas que c'est bon. Je crois que c'est faux. Cependant, j’ai un jour lu un article qui disait que si quelqu'un fait quelque chose de mal (en matière de programmation), expliquez-lui pourquoi c’est faux, si vous ne le pouvez pas, alors vous devriez peut-être vous demander si c’est vraiment faux.

Cela m'amène à cette question:

Si je vois quelqu'un réinvente clairement la roue en construisant sa propre méthode de quelque chose qui est déjà intégré dans le langage / cadre. Tout d'abord, supposons que leur méthode soit aussi efficace que la méthode intégrée. De plus, le développeur, conscient de la méthode intégrée, préfère sa propre méthode.

Pourquoi devrait-il utiliser le construit en un sur son propre?


16
c'est une excellente question. Je ne pense pas que les gens devraient réinventer la roue, mais il est important de remettre en question ces idées pour s'assurer qu'elles tiennent le coup.
Jon Hopkins

4
@Demian - C'est en fait une très bonne idée. Si vous pouvez l'expliquer, alors vous êtes probablement justifié de le faire.
Jon Hopkins

2
Dans toutes les décisions, il est bon de demander quel est votre objectif principal, puis de faire en sorte que les autres sous-éléments soutiennent cet objectif. Si votre objectif principal est de fournir un produit de qualité dans les délais impartis, la duplication de code déjà existant est probablement préjudiciable à cet objectif. Si votre objectif principal est de créer une bibliothèque mieux pensée, cela contribue peut-être à cet objectif. Si vous travaillez pour quelqu'un d'autre, vous devez alors poser la question de son point de vue , pas tellement le vôtre.
Gahooa

5
Réinventez si les roues existantes ne vous conviennent pas vraiment, ou ... si vous voulez savoir comment les roues fonctionnent! Un article intéressant sur ce sujet: codinghorror.com/blog/2009/02/…
lindes

4
Attribué à Douglas Crockford:The good thing about reinventing the wheel is that you can get a round one.
Joel Etherton

Réponses:


72

Comme je l'ai déjà signalé sur StackOverflow, réinventer la roue est souvent un très bon choix , contrairement à la croyance populaire. Le principal avantage est que vous avez le plein contrôle du logiciel, ce qui est souvent essentiel. Pour une discussion complète, voir mon post original .


14
+1 Le point le plus important est qu’il soit entièrement sous votre contrôle et que vous le sachiez à fond. Le débogage d'autres bibliothèques peut causer des problèmes majeurs, dans la mesure du possible, et dire que toutes les bibliothèques matures sont exemptes de bogues est pour le moins optimiste.
Orbling

6
L’équipe Excel est même allée jusqu’à écrire son propre compilateur car elle ne voulait aucune dépendance externe susceptible d’affecter le projet. C'est un point valable, mais à quel point ce contrôle est-il essentiel?
Jon Hopkins

6
+1 Une fois dans ma vie antérieure en tant que programmeur MFC / VC ++, nous avons utilisé une bibliothèque tierce pour divers composants d'interface graphique, ce qui s'est avéré être un cauchemar total à maintenir. Ces choses sont devenues profondément accrochées dans le logiciel et ne pouvaient pas être supprimées (sans dépenser des mois irréalistes d'hommes-mois-que-nous-n'avions pas d'effort). Je suis absolument persuadé que les économies de temps que nous avons réalisées au début pour ne pas avoir à déployer nos propres grilles et gestionnaires de disposition ont été balayées par des ordres de grandeur au fil des années et que nous devions maintenir cette monstruosité.
Bobby Tables

4
@Guzica, un choix malheureux ne suffit pas nécessairement pour généraliser, il existe d’autres bibliothèques bien entretenues et un bon choix. La question est de savoir si la décision initiale a été suffisamment bien documentée?

5
En revanche, si vous utilisez une roue préexistante, vous avez généralement beaucoup d'aide, souvent bien indexée par Google, pour vous aider à la déboguer.
Dan Ray

83

Dépend..

Comme pour tout, son contexte:

C'est bien quand:

  • La structure ou la bibliothèque est trop lourde et vous n’avez besoin que de fonctionnalités limitées. Rouler votre propre version extrêmement légère qui répond à vos besoins est une meilleure approche.
  • Lorsque vous voulez comprendre et apprendre quelque chose de complexe, rouler vous-même a du sens.
  • Vous avez quelque chose de différent à offrir, quelque chose que les implémentations des autres n'ont pas. Peut-être une nouvelle tournure, nouvelle fonctionnalité, etc.

C'est mal quand:

  • La fonctionnalité existe déjà et est connue pour être stable et bien connue (populaire).
  • Votre version n'ajoute rien de nouveau.
  • Votre version introduit des bugs ou des contraintes (par exemple, votre version n’est pas thread-safe).
  • Il manque des fonctionnalités à votre version.
  • Votre version a une documentation pire.
  • Votre version manque de tests unitaires par rapport à ce qu'elle remplace.

2
Parallèlement à votre premier point (et inversement au quatrième), si la roue est difficile à gérer ou, pire encore, inflexible, vous pouvez vraiment l’améliorer. Cela se produit fréquemment avec les composants de l'interface utilisateur dans certaines régions, où la roue s'avère être une roue de train et ne fonctionne que sur une voie.
Magus

1
Difficile à comprendre sonne vrai pour moi. Je ne faisais tout simplement pas une analyse de graphe dirigée, alors j'en sais une. Maintenant, je suis confiant d'utiliser un cadre
JasTonAChair

1
J'ajouterais un 4ème pour la colonne "Bien" (bien que cela s'applique rarement): si vous comprenez l'espace du problème mieux que la bibliothèque existante. La bibliothèque de temps standard de facto de Java, Joda, Joda a été écrite car elle était difficile à utiliser. Elle a été réécrite pour devenir la bibliothèque de temps standard de jure de Java 8 car ils comprenaient maintenant le problème beaucoup mieux que lorsqu’ils avaient écrit joda-time original.
Morgen

55

Je pense que le cas d'un développeur qui réinvente sciemment la roue "parce qu'il préfère sa propre méthode" est assez rare. La plupart du temps, c'est par ignorance et parfois par obstination.

Est-ce si mauvais? Oui. Pourquoi? Parce que la roue existante a probablement été conçue au fil du temps et a déjà été testée dans de nombreuses circonstances et sur de nombreux types de données. Les développeurs de la roue existante ont déjà rencontré des problèmes et des difficultés que le réinventeur ne peut même pas imaginer.


3
Ou encore la paresse - que l’on ne se donne pas la peine d’aller chercher les alternatives ou trouver moins intéressant d’aller faire pour écrire le code.
Jon Hopkins

9
J'ai vu de nombreux cas où la roue a été réinventée par arrogance, avec l'idée que la bibliothèque / framework xyz est réservée aux mauvais programmeurs qui ne savent pas comment s'y prendre de la "bonne façon". Zut, j'ai vu cet argument (d'une manière ou d'une autre) sur des sites SO.
Bill

2
... Ce qui crée une charge de maintenance récurrente (de la pire sorte) sur les développeurs actuels ou ultérieurs.
Gahooa

2
C'est ce que je faisais depuis des années. Je roulais ma propre fonctionnalité dans un langage parce que je ne savais pas que cette fonctionnalité était déjà intégrée.
Matchu

1
Depuis la rédaction de cet article (Geez) il y a presque trois ans, j'ai embauché et licencié un développeur que j'ai décrit dans la première phrase comme "assez rare". Il a duré un mois. Je lui dirais comment nous faisons les choses ici et il dirait "j'entends ce que tu dis". Cela m'a pris un mois pour entendre le non-dit "... mais c'est faux et je ferai tout secrètement mais tout" à la fin de la phrase.
Dan Ray

22

Les roues carrées doivent être réinventées. Les efforts qui aspirent doivent être dupliqués. Il y a peut-être un manque de documentation sur la méthode, et l'autre programmeur pense qu'il est plus facile d'écrire sa propre méthode plutôt que d'essayer de la comprendre. Peut-être que la façon dont la méthode est appelée est maladroite et ne correspond pas à l'idiome du langage de programmation.

Il suffit de lui demander quelle est la carence.


9
+1 bonne métaphore "il faut réinventer les roues carrées" .
Orbling

+1 pour "Les roues carrées doivent être réinventées"
Tintu C Raju

17

En général, j'évite de réinventer la roue si la fonctionnalité désirée, ou une approximation, existe dans la bibliothèque standard du langage que j'utilise.

Cependant, si je dois incorporer des bibliothèques tierces, c'est un jugement qui dépend de la popularité et de la popularité de la bibliothèque. Je veux dire, parlons-nous de Boost ou de Kick-ass String-Parsing Tools 1.0 de Bob?

Même si la bibliothèque est généralement bien connue et très estimée dans l’ensemble du secteur, elle reste une dépendance vis -à- vis de tiers . Les programmeurs accordent généralement une grande importance aux vertus de la réutilisation du code, tout en négligeant souvent le danger des dépendances. Un projet comportant trop de dépendances vis-à-vis de tiers risque de s’effondrer à long terme, dans la mesure où il évolue lentement vers un cauchemar de maintenance.

Il est donc bon d’ utiliser le code existant , mais les dépendances sont mauvaises . Malheureusement, ces deux affirmations s’opposant, l’essentiel est d’essayer de trouver le bon équilibre. C'est pourquoi vous devez identifier les dépendances acceptables . Comme je l'ai dit, tout ce qui se trouve dans la bibliothèque standard de la langue est très probablement une dépendance acceptable. Déplacement à partir de là, les bibliothèques qui sont très appréciés dans l'industrie sont aussi généralement acceptables (comme Boost C ++, ou jQuery pour Javascript) - mais ils sont encore moins souhaitable que la bibliothèque standard , car ils n'ont tendance à être moins stables que les bibliothèques normalisées .

En ce qui concerne les bibliothèques relativement inconnues (par exemple, le dernier téléchargement sur SourceForge), elles constituent des dépendances extrêmement risquées, et je recommande généralement de les éviter dans le code de production, à moins que vous ne connaissiez suffisamment le code source pour les maintenir vous-même.

Donc, c'est vraiment un exercice d'équilibre. Mais le fait est que juste dire aveuglément "Réutiliser le code bien! Réinventer la roue mal!" est une attitude dangereuse. Les avantages de l'utilisation de code tiers doivent être comparés aux inconvénients de l'introduction de dépendances.


3
+1 J'ai tendance à ressentir la même chose. Je suis beaucoup plus enclin à réinventer les petites roues si l'utilisation d'une roue existante créera un problème de dépendance plutôt que si la roue existante est déjà présente, configurée et attend d'être utilisée dans tout environnement où j'en aurais besoin.
dsimcha

14

Si les gens ne réinventaient pas les roues, le monde en serait rempli. entrez la description de l'image ici

Voici un dialogue de mon lieu de travail:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

Il y a deux options: réinventer la roue OU utiliser Colorama. Voici ce que chaque option aurait comme conséquence:

Utiliser Colorama

  • Peut-être un peu plus vite pour courir
  • Ajouter une dépendance à un tiers pour quelque chose de trivial
  • Vous continuez d'être aussi stupide qu'avant d'utiliser Colorama

Réinventer la roue

  • Vous comprenez comment certains programmes peuvent afficher des couleurs
  • Vous apprenez que les caractères spéciaux peuvent être utilisés pour colorer n'importe quel terminal
  • Vous êtes capable de colorier dans n'importe quel langage de programmation que vous pourriez utiliser à l'avenir
  • Votre projet est moins susceptible de casser

Comme vous le voyez, tout dépend du contexte. Réinventer la roue est une chose que je fais très souvent parce que je veux être capable de penser par moi-même et non pas compter sur d'autres personnes pensant pour moi. Cependant, si vous utilisez une échéance ou que ce que vous essayez de mettre en œuvre est énorme et existe déjà, vous feriez mieux d'utiliser ce qui est là.


2
+1 ne suis pas d'accord avec toi à 100% mais a aimé l'image utilisée pour véhiculer l'idée.
Tulains Córdova

Cette réponse évite quelque peu que votre employeur paie pour votre luxe de réinventer cette roue pour votre propre bénéfice éducatif. Peut-être devriez-vous le faire à votre rythme; si on vous le demande, votre employeur dira probablement qu'il / elle veut seulement que le travail soit fait le plus rapidement possible et si Colorama le fait, continuez.
Neil Haughton

2
@NeilHaughton tel que je le vois, mon "propre" avantage éducatif est également le bénéfice de mon employeur.
Pithikos

Hmmm ... votre employeur peut bien sûr ne pas le voir de cette façon et il / elle met le pain sur votre table.
Neil Haughton

La bibliothèque Colorama, elle-même, était une réinvention de la roue. Il existait déjà une interface permettant d'afficher les couleurs dans le terminal (par le biais de caractères spéciaux) et, avant la sortie, les gens le faisaient déjà. La bibliothèque Colorama réinvente l'interface pour atteindre l'objectif. La question ici est donc plus de savoir si vous allez utiliser une roue supposée améliorée, ou utilisez-vous une vieille roue dans votre projet? Réinventer la roue dans ce cas reviendrait à construire Colorama2 qui "améliore" encore plus que ce que Colorama avait à offrir.
Ski le

13

Une raison utile pour réinventer la roue est l’apprentissage, mais je vous conseillerais de le faire à votre rythme. À mesure que de plus en plus de solutions prédéfinies deviennent disponibles et que plus de niveaux d'abstraction sont fournis, nous devenons beaucoup plus productifs. Nous pouvons nous concentrer sur le problème commercial plutôt que sur les éléments génériques qui ont été modifiés à maintes reprises. MAIS, pour cette raison, vous pouvez affiner vos compétences et apprendre beaucoup en essayant de ré-implémenter une solution par vous-même. Pas nécessairement pour une utilisation en production.

Une autre chose - si l’un des problèmes est lié à la dépendance éventuelle d’une société tierce vis-à-vis d’une bibliothèque tierce, assurez-vous qu’il existe une option pour obtenir le code source, ou au moins deux autres options sur lesquelles vous pouvez compter.

En passant, si vous choisissez d'implémenter la vôtre, évitez de le faire pour la cryptographie ou d'autres fonctionnalités liées à la sécurité. Des outils établis (et entièrement testés) sont disponibles pour cela, et de nos jours, il est bien trop risqué de lancer le vôtre. Cela ne vaut jamais la peine, et il est effrayant d’entendre encore parler d’équipes faisant cela.


+1 Un très bon point sur la perspective d'apprentissage, pour pouvoir utiliser une bibliothèque efficacement, vous devez vraiment savoir intimement comment elle fonctionne. Je n'aime pas utiliser les outils de la boîte noire. C'est également un excellent point sur les bibliothèques de cryptographie, trop risqué pour faire valoir votre point de vue.
Orbling

J'ajouterais que si une bibliothèque tierce risque de disparaître, c'est une très bonne justification pour écrire une interface de programmation permettant à une bibliothèque d'être facilement remplacée par une autre.
user8865

Le bon point - nous utilisons le modèle d’adaptateur uniquement à cette fin, et cela nous a récemment évité de devoir échanger une bibliothèque FTP tierce.
Mark Freedman

9

Il existe deux types d’efficacité: la vitesse de traitement / la vitesse (c’est la rapidité avec laquelle elle s’exécute) qu’elle peut égaler et la vitesse de développement qui ne le fera presque certainement pas. C'est la première raison - pour tout problème de complexité raisonnable pour lequel des solutions existantes sont disponibles, il sera certainement plus rapide de rechercher et de mettre en œuvre une bibliothèque existante que de coder la vôtre .

La deuxième raison est que la bibliothèque existante (en supposant qu’elle est mature) a été testée et a fait ses preuves - probablement dans une gamme de scénarios beaucoup plus large qu’un développeur et une équipe de test sera en mesure de mettre en place une nouvelle routine écrite. zéro effort.

Troisièmement, il est beaucoup plus facile de soutenir. Non seulement quelqu'un d'autre la prend en charge et améliore-t-il (celui qui a écrit la bibliothèque / le composant), mais il est beaucoup plus probable que d'autres développeurs l'utiliseront et seront en mesure de comprendre et de gérer le code , ce qui minimisera les opérations en cours frais.

Et tout cela suppose l’équivalence fonctionnelle, ce qui n’est normalement pas le cas. Les bibliothèques offriront fréquemment des fonctionnalités que vous jugeriez utiles, mais que vous ne pourriez jamais justifier, mais qui sont soudainement disponibles gratuitement.

Il y a des raisons de faire votre propre choix - principalement lorsque vous voulez faire quelque chose que la fonction intégrée ne peut pas faire et où il existe un avantage réel à gagner en le faisant, ou lorsque les options facilement disponibles ne sont pas mûres - mais elles êtes moins commun que beaucoup de développeurs voudraient vous faire croire.

En outre, pourquoi voudriez-vous passer votre temps à résoudre des problèmes déjà résolus? Oui, c’est un excellent moyen d’apprendre, mais vous ne devriez pas le faire au détriment de la bonne solution de code de production, ce dont je suppose qu’il s’agit.


2
Sur votre dernière ligne: afin de savoir comment ils sont résolus. La programmation dépend de l'expérience après tout.
Orbling

@Orbling - assez, mais vous ne devriez pas le faire dans le code de production et je suppose que c'est à cela que se réfère la question. Doit modifier.
Jon Hopkins

@ Jon Hopkins: Bien, le code de production découle généralement de l'apprentissage, à moins que vous ne le fassiez à votre rythme.
Orbling

@Orbling - Je dirais qu'il ne faut jamais apprendre quelque chose pour apprendre, puis le mettre en production. Soit quelque chose est un code de production, auquel cas ce devrait être la meilleure solution, soit c'est pour l'apprentissage. Ils se chevauchent parfois, mais cela ne serait pas l'un d'entre eux, à moins que rouler soi-même soit vraiment la meilleure solution.
Jon Hopkins

@ Jon Hopkins: Idéalement oui, mais souvent personne au sein de l'équipe ne sait comment faire quoi que ce soit, au point que les bibliothèques disponibles risquent de ne plus être utilisables de manière fiable. Apprendre, ou "rechercher" comme l'appellent la plupart des gens, est donc une nécessité. Oui, ce n'est pas vraiment apprendre pour apprendre, mais c'est apprendre à éviter les risques futurs.
Orbling

9

Bien sûr, réinventer la roue par caprice, par ignorance et par arrogance peut être une mauvaise chose, mais à mon humble avis, le pendule est allé trop loin. Il y a un avantage énorme à avoir une roue qui fait exactement ce que vous voulez et rien de plus .

Souvent, lorsque je regarde une roue existante, celle-ci en fait bien plus que ce dont j'ai besoin, souffre de l' effet de plate-forme interne et est donc inutilement complexe, ou il manque un élément clé dont j'ai besoin et qu'il serait difficile de mettre en œuvre au-dessus de ce qui existe déjà.

De plus, utiliser des roues existantes ajoute souvent à mon projet des contraintes que je ne souhaite pas. Par exemple:

  • La roue existante nécessite un langage et / ou un style de programmation différents de ceux que je préférerais utiliser autrement.
  • La molette existante ne fonctionne qu'avec la version héritée d'un langage (par exemple, Python 2 au lieu de Python 3).
  • Là où il y a des compromis entre efficacité, flexibilité et simplicité, la roue existante fait des choix qui ne sont pas optimaux pour mon cas d'utilisation. (On m'a appris à réinventer même les fonctionnalités des bibliothèques que j'avais moi-même écrites à l'origine. Dans mon cas, c'est généralement parce que j'ai écrit la version de bibliothèque de la fonction générique et relativement efficace, alors que j'ai actuellement besoin de quelque chose de très rapide dans mon cas particulier. Cas.)
  • La roue existante contient des tonnes de fichiers hérités qui sont totalement inutiles dans le cas de nouveaux codes, mais rendent néanmoins la vie difficile (par exemple, une bibliothèque Java que j’utilise qui me force à utiliser ses classes de conteneurs pourris parce qu’elle a été écrite avant les génériques, etc.) .
  • La manière dont la roue existante modélise le problème est complètement différente de celle qui convient à mon cas d'utilisation. (Par exemple, il peut être pratique pour moi de disposer d’un graphe dirigé représenté par des objets nœud et des références, mais la roue existante utilise une matrice de contiguïté ou inversement. Il peut également être pratique de disposer mes données dans un ordre de colonne majeur, mais le paramètre la roue existante insiste sur la rangée principale ou vice-versa.)
  • La bibliothèque ajoute une dépendance massive et fragile qui serait un problème majeur pour être opérationnel partout où je veux déployer mon code, alors que tout ce dont j'ai besoin est un petit sous-ensemble de ses fonctionnalités. D’autre part, dans ce cas, j’extrais parfois simplement la fonctionnalité que je souhaite dans une nouvelle bibliothèque plus petite ou tout simplement copier / coller si la bibliothèque est open source et que la base de code le rend suffisamment simple. (Je l'ai même fait avec des bibliothèques relativement grandes que j'ai écrites moi-même, pas seulement celles des autres.)
  • La molette existante tente de respecter de manière pédagogique une norme peu pratique et non pertinente pour mon cas d'utilisation.

Je pense que tout se résume à ceci: si la roue vous convient, utilisez-la, sinon, créez-en une nouvelle. Juste ne soyez pas dogmatique à ce sujet d'une manière ou d'une autre.
Neil Haughton

5

J'utilise souvent le mien parce que je l'ai construit avant de découvrir celui qui existait déjà, et je suis trop paresseux pour aller chercher et remplacer chaque instance. De plus, je comprends parfaitement ma propre méthode alors que je ne comprendrais peut-être pas une méthode préexistante. Et enfin, parce que je ne comprends pas tout à fait celui qui existe déjà, je ne peux pas vérifier qu’il fait absolument tout ce que mon actuel fait.

Il y a beaucoup de choses à coder, et je n'ai pas beaucoup de temps pour recodifier quelque chose à moins que cela ne se répercute sur la production.

En fait, une application Web asp encore utilisée aujourd'hui possède un graphique entièrement fonctionnel qui affiche les données sous forme de tableau et permet le tri / édition, mais ce n'est pas une grille de données. Il a été construit il y a quelques années lorsque j'ai découvert asp.net et que je ne connaissais pas les datagrids. J'ai un peu peur du code car je ne sais pas ce que je faisais à l'époque, mais cela fonctionne, il est précis, facile à modifier, ne plante pas et les utilisateurs l'adorent


2
C'est une raison de ne pas le remplacer, de ne pas le faire en premier lieu. Je suppose que vous ne feriez pas la même chose maintenant, sachant que l'alternative existe?
Jon Hopkins

@Jon lol certainement pas! Et à l'origine, j'avais lu la question: pourquoi un développeur préfère-t-il sa propre méthode à une méthode existante? En relisant la question, je me rends compte maintenant que l'inverse de la question a été posé, mais je laisse la réponse ici, car elle semble liée et a obtenu quelques votes favorables.
Rachel

4

Réinventer la roue est un excellent moyen d’apprendre le fonctionnement d’une roue, mais ce n’est pas un bon moyen de construire une voiture.


4

Je travaille actuellement pour un groupe de radins.

Lorsque la décision est prise entre "construire ou acheter", au lieu de prendre une décision rationnelle basée sur des considérations économiques, les gestionnaires ont choisi de "construire". Cela signifie qu'au lieu de payer quelques milliers de dollars pour un composant ou un outil, nous passons des mois à la construction de nos propres. L'achat d'une roue auprès d'une autre entreprise coûte de l'argent qui sort du budget, ce qui est contre-performant pour les bonus de fin d'année. Le temps des programmeurs est gratuit et ne compte donc pas pour les bonus de fin d’année (avec l’avantage supplémentaire de faire en sorte que les programmeurs n’aient pas tout fait "à temps"); une roue réinventée est donc une roue libre .

Dans une entreprise rationnelle, le coût par rapport aux avantages d'acheter des roues fabriquées par d'autres par rapport à la réinvention de ses propres roues serait basé sur les coûts à court et à long terme, ainsi que sur les coûts d'opportunité perdus, car on ne peut pas créer de nouveaux widgets tant qu'on est réinventer les roues. Chaque jour que vous passez à réinventer la roue est un autre jour où vous ne pouvez pas écrire quelque chose de nouveau.

Présentation sur la construction vs acheter .
Article sur la construction vs acheter .

Si je vois quelqu'un réinvente clairement la roue en construisant sa propre méthode de quelque chose qui est déjà intégré dans le langage / cadre. Tout d'abord, supposons que leur méthode soit aussi efficace que la méthode intégrée. De plus, le développeur, conscient de la méthode intégrée, préfère sa propre méthode.

Pourquoi devrait-il utiliser le construit en un sur son propre?

La version intégrée aura eu beaucoup plus de gens à cogner dessus - donc trouver et corriger plus de bugs que votre code homebrew ne peut en avoir.

Enfin, lorsque votre développeur local quittera et que quelqu'un d'autre maintiendra le code qu'il a écrit, il sera totalement refactoré et remplacé par ce qui est dans le cadre. Je sais que cela se produira parce que mon employeur actuel a un code qui a migré vers de nouvelles versions de VB au fil des ans (le produit le plus ancien est sur le marché depuis environ 20 ans) et c’est ce qui s’est passé. Le développeur avec le plus long emploi dans mon bureau est ici depuis 17 ans.


Pour être juste, la version "standard" a parfois été créée pour réinventer ce que la plupart des gens ont fini par faire avant que la version standard ne soit développée. IOW, le standard est censé être la "réinvention finale". Cependant, le passage à une version standard, bien testée, beaucoup plus robuste et corrigée de bogues peut entraîner des bogues, car le code de votre application émet des hypothèses vraies pour votre ancienne version non standard, mais fausses pour la nouvelle version standard.
Steve314

1
Dans une entreprise rationnelle, s’il est décidé que l’immobilisation du fournisseur est acceptable, l’entreprise (en tant qu’acheteur et dépendant de l’offre du fournisseur) devra établir de bonnes relations d’affaires avec le fournisseur et se protéger contre divers incidents. Exemples: refus de fournir une assistance / correction de bugs, hausse de prix, modification des conditions du contrat, poursuites frivoles ou départ définitif de l’entreprise. Cette couverture fait également partie des coûts et est souvent ignorée. (Tout comme le coût de développement interne est ignoré.) Remarque: ce coût n'existe pas dans les offres intégrées.
Rwong

N'oubliez-vous pas que les employeurs malavisés que vous avez égarés vous procurent plus de travail rémunéré que vous n'auriez autrement? Vous devriez les encourager au lieu de s'en plaindre!
Neil Haughton

4

Le problème avec la réinvention de la roue est qu’il n’ya parfois pas de roue standard prête à l'emploi qui fasse ce dont vous avez besoin. Il y a beaucoup de bonnes roues dans beaucoup de tailles, couleurs, matériaux et modes de construction. Mais certains jours, il suffit de disposer d’une roue très légère en aluminium anodisé vert, et personne ne la fabrique. Dans ce cas, vous devez créer le vôtre.

Maintenant, cela ne veut pas dire que vous devriez faire vos propres roues pour chaque projet - la plupart des choses peuvent utiliser des pièces standard et être meilleures pour cela. Mais de temps en temps, vous constatez que les pièces standard ne fonctionnent tout simplement pas et que vous en fabriquez vous-même.

Le plus important est de savoir QUAND faire le vôtre. Vous devez avoir une bonne idée de ce que les pièces standard peuvent faire et ce qu’elles ne peuvent pas faire avant de commencer à concevoir les vôtres.


4

Réinventer ou non la roue est une question de coût / bénéfice. Les coûts sont assez évidents ...

  • Il faut beaucoup de temps pour réinventer.
  • Il faut encore plus de temps pour documenter ce que vous avez inventé.
  • Vous ne pouvez pas embaucher des personnes qui comprennent déjà ce que vous avez inventé.
  • Il est trop facile de réinventer quelque chose de mal, ce qui entraîne des coûts permanents pour les problèmes causés par la mauvaise conception.
  • Nouveau code signifie nouveaux bogues. Dans la plupart des bogues, la plupart des bogues avaient déjà été supprimés dans l'ancien code et des solutions de contournement subtiles de problèmes que vous ignorez risquent de ne pas pouvoir résoudre dans la nouvelle conception.

La dernière est importante - il y a un article de blog quelque part qui met en garde contre la tendance à "jeter l'ancien code et repartir à zéro" sur la base du fait que beaucoup de vieux fichiers que vous ne comprenez pas sont en fait des corrections de bogues essentielles. Il y a un récit édifiant sur Netscape, IIRC.

Les avantages peuvent être ...

  • La possibilité d'ajouter des fonctionnalités que les bibliothèques existantes n'ont pas. Par exemple, j'ai des conteneurs qui "maintiennent" leurs instances d'itérateur / curseur. Les insertions et les suppressions n'invalident pas les itérateurs. Un itérateur pointant sur un vecteur continuera de pointer vers le même élément (pas le même index), indépendamment des insertions et des suppressions antérieures dans le vecteur. Vous ne pouvez simplement pas faire cela avec des conteneurs C ++ standard.
  • Une conception plus spécialisée ciblant vos exigences particulières et respectant vos priorités (mais méfiez-vous de la tendance à l'effet de plate-forme interne).
  • Contrôle total - un tiers ne peut pas décider de redéfinir l'API de manière à ce que vous deviez réécrire la moitié de votre application.
  • Compréhension complète - vous l’avez conçue de cette manière, de sorte que vous comprenez, espérons-le, parfaitement comment et pourquoi vous l’avez fait.
  • ÉDITER Vous pouvez tirer les leçons des autres bibliothèques sans vous laisser piéger dans les mêmes pièges en choisissant de façon sélective comment vous les imitez.

Une chose - utiliser une bibliothèque tierce peut compter pour réinventer la roue. Si vous avez déjà votre propre bibliothèque ancienne, bien utilisée et bien testée, réfléchissez bien avant de la jeter pour utiliser plutôt une bibliothèque tierce. C'est peut-être une bonne idée à long terme - mais il peut y avoir beaucoup de travail et beaucoup de mauvaises surprises (à partir de subtiles différences sémantiques entre les bibliothèques) avant de vous y rendre. Par exemple, considérons l’effet du fait que je passe de mes propres conteneurs à ceux de bibliothèques standard. Une traduction naïve du code d'appel ne tiendrait pas compte du fait que les conteneurs de bibliothèque standard ne conservent pas leurs itérateurs. Les cas où je garde un itérateur pour plus tard sous forme de "signet" ne pourraient pas être mis en œuvre avec une simple traduction - je '


3

S'il existe un composant fonctionnel qui répond à vos besoins, alors pourquoi passer votre temps à écrire et à déboguer votre propre version? De même, si vous avez déjà écrit du code pour remplir une fonction similaire précédemment, pourquoi le réécrire?

Joel a écrit un article sur Not-Invented-here qui en dit long sur la réécriture de code et de logiciels.


3

Réinventer la roue peut être un excellent moyen d’apprendre comment quelque chose fonctionne - et je vous recommande de le réinventer à votre guise - mais lorsque vous écrivez une application, pourquoi réinventer s’il existe des solutions bien établies qui font déjà la même chose?

Par exemple, je n'écrirais jamais de code JavaScript à partir de rien; au lieu de cela, je commencerais par jQuery et créerais mes applications par-dessus ce cadre.


3

Ma règle personnelle:

Réinventer la roue est une bonne chose lorsque vous venez d'apprendre. Si vous avez une date limite, vous pouvez utiliser les roues existantes.


3

Être "mauvais" ou même "mal" est un mot plutôt fort.

Comme toujours, il y a des raisons de choisir une implémentation personnelle sur une implémentation intégrée. Auparavant, un programme C pouvait rencontrer des bogues dans la bibliothèque d'exécution et devait donc simplement fournir sa propre implémentation.

Cela ne s'applique pas aux programmes Java car la machine virtuelle Java est très strictement définie, mais certains algorithmes restent très difficiles à obtenir. Par exemple, Joshua Bloch explique comment l'algorithme de recherche binaire, d'une simplicité trompeuse, de la bibliothèque d'exécution Java contenait un bogue dont l'apparition a pris neuf ans:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Il a été trouvé, corrigé et distribué dans les futures distributions Java.

Si vous utilisez la recherche binaire intégrée, vous gagnez du temps et de l’argent en faisant en sorte que Sun se charge de trouver, de corriger et de distribuer ce correctif. Vous pouvez exploiter leur travail simplement en disant "vous avez besoin d'au moins Java 6 update 10".

Si vous utilisez votre propre implémentation - qui contiendra très probablement aussi cette erreur -, vous devez d'abord que le bogue se manifeste. Étant donné que celui-ci n'apparaît que sur de grands ensembles de données, il est inévitable que la production se produise quelque part, ce qui signifie qu'au moins un de vos clients sera affecté et perdra probablement de l'argent réel pendant que vous trouvez, corrigez et distribuez le correctif.

Il est donc tout à fait correct de préférer votre propre implémentation, mais la raison en vaut bien mieux, car elle sera forcément plus chère que de tirer parti du travail des autres.


+1 pour compter sur la plate-forme pour déployer des corrections de bugs. D'autre part, il appartient au fournisseur de la plate-forme de décider de distribuer ou non le correctif. Un autre fournisseur peut choisir: (1) de distribuer le correctif, gratuitement; (2) retenir le correctif jusqu'à ce qu'une mise à jour majeure de version; (3) distribue le correctif aux utilisateurs de la version la plus récente, mais refuse les versions précédentes (4) refuse de corriger, affirmant qu'il peut "entraîner une incompatibilité généralisée" et "n'affecte que des utilisateurs limités".
Rwong

@ rwong, si vous rencontriez un bogue dans la routine intégrée, le mieux serait de fournir votre propre version corrigée. Cela va sous "une très bonne raison de le faire".

ørn: Ce que je veux dire, c'est qu’outre le ou les vendeurs bienveillants que vous avez mentionnés, il existe aussi d’autres types de vendeurs.
Rwong

@rwong, dans ce cas, cela constitue "une très bonne raison de choisir une implémentation personnelle".

3

J'ai récemment blogué mes pensées sur ce sujet. Résumer:

  1. C'est presque toujours mal de construire la vôtre, surtout si c'est une fonction intégrée à la langue. Mais si vous évaluez un cadre immature / maintenu discutable / mal documenté que vous avez trouvé sur Internet contre la possibilité d'écrire le vôtre, cela pourrait être une évidence.

  2. Je pense que réinventer la roue est une analogie assez terrible pour un logiciel anti-modèle. Cela implique que la solution initiale ne peut jamais être améliorée. C'est absurde. La soi-disant roue peut devenir obsolète du jour au lendemain, ou ses propriétaires pourraient arrêter de la conserver. La roue a une valeur différente sur chaque système où elle est utilisée. Ainsi, il est souvent tout à fait possible d'inventer une meilleure roue.

  3. L'un des principaux avantages de la création de votre propre cadre est que vous n'avez pas à assumer la responsabilité des bogues de quelqu'un d'autre. (C’est la philosophie d’Amazon .) Pensez-y de la manière suivante: lequel de ces problèmes convient le mieux à un client? -

    "Notre site Web est tombé en panne. C'était la faute de quelqu'un d'autre, et nous avons enregistré un bogue avec son créateur. Nous ne pouvons rien y faire à part attendre. Nous vous tiendrons au courant."

    "Notre site Web est tombé en panne et nous avons pu le réparer immédiatement."


0

Peut-être est-ce aussi efficace, mais est-il aussi robuste? Je pense que la raison la plus convaincante d’utiliser une bibliothèque plutôt que de rouler vous-même est que tant de personnes l’utilisent dans le framework qu’elles peuvent trouver et corriger rapidement les bogues. Les bibliothèques développées en interne, bien qu'elles puissent fournir autant (ou plus) de fonctionnalités, ne peuvent rivaliser avec une bibliothèque regroupant des millions d'utilisateurs pour effectuer des tests dans pratiquement tous les cas d'utilisation. Vous ne pouvez pas battre ce genre de test en interne.


0

Eh bien, sa propre méthode étant aussi efficace que le cadre serait assez rare, car la plupart des cadres ont encore des bogues et aucun cadre ne peut vous donner une solution prête à l'emploi. La plupart des programmeurs qui ne savent pas penser n'essaieront jamais d'écrire quoi que ce soit au niveau du framework; ils vont juste chercher sur Google pour une solution toute faite. Tout programmeur avisé verra d’abord s’il existe un framework libre doté des fonctionnalités dont il a besoin, puis écrira lui-même la solution s’il n’y en a pas. Parfois, il est trop difficile d'expliquer la situation actuelle du projet et le développeur est le meilleur juge.

Réinventer la roue n’est pas mauvais, c’est une déclaration faite par des paresseux pour éviter de travailler dur. Même les auteurs de cadre réinventent; l’ensemble du cadre .Net a été réinventé pour faire ce que COM offrait.


0

Aussi offensant que cela puisse être pour certains, j'ai toujours trouvé ce terme invraisemblable lorsqu'il était utilisé par une forme quelconque d'ingénieur ou en référence à un sujet de création ou de conception. En fait, je ne peux m'empêcher de voir cela comme une hypocrisie compte tenu des pressions qui pèsent sur l'innovation dans le monde en évolution rapide. Se répéter (ou ignorer des solutions adéquates, préexistantes) n’est jamais une bonne idée, mais en réalité, il ya une raison pour laquelle nous ne regardons pas encore tous les écrans noirs remplis de lettres vertes.

Je comprends "si ce n’est pas cassé ne le répare pas", bien que je suppose qu'une telle phrase puisse paraître ignorante à certains. Pourtant, avec les efforts actuels pour réinventer la roue pour les besoins de voyages dans l’espace, de courses, de transports maritimes, etc., "ne réinventez pas la roue" est également assez ignorant et n’est pas aussi intelligent que cela puisse paraître.

Mon parcours consiste à diriger de nombreux projets et j'ai dû travailler avec de nombreux stagiaires et d'autres formes de développeurs verts. J'ai également dû gérer de nombreuses questions naïves que certains qualifieraient de "stupides", et j'ai également dû dissuader les gens de chasser les lapins. des ensembles en dehors du cadre de leurs tâches. Cependant, je ne découragerais jamais l' innovation ou la créativité et j'ai vu de grandes choses en "réinventant la roue".

Ma réponse réelle à la question: Il n'y a que deux situations qui font que réinventer la roue est une mauvaise chose:

  1. Si ce n'est pas vraiment nécessaire
  2. Si c’est l’autre type qui le fait quand vous pourriez avoir

Edit: Je peux voir par les votes au volant que je dois avoir offensé certains. Ce que je voudrais ajouter, c’est que cette phrase a toujours été une de mes grandes bêtes noires. Je comprends que mes deux cents peuvent sembler plutôt trollish, mais je n’ai aucune intention de troll, de provoquer des incendies ou d’offenser.


0

Les arguments sur la "réinvention d'une roue" sont souvent utilisés dans le mauvais contexte d'utiliser une bibliothèque, mais ce n'est pas la même chose.

Supposons que j'évalue une bibliothèque «formulaires-plus», récemment devenue populaire et qui aide à gérer les formulaires. Il a une belle page de destination, des graphismes modernes et cool, et un cercle (oups, je veux dire une communauté) qui jure à quel point cela rend les formes superbes. Mais "formes-plus" est une abstraction au-dessus de "formes". "formes" était possible mais difficile à traiter, de sorte que l'abstraction qui le rend plus facile devient populaire.

De nouvelles abstractions se produisent tout le temps. Il est difficile de les comparer aux roues. Cela ressemble plus à un nouvel appareil de contrôle et à un nouveau manuel pour un appareil quelconque, déjà très compliqué, dont vous avez besoin pour fonctionner.

L’évaluation de ce nouveau dispositif "forms-plus" sera différente en fonction de votre expérience personnelle. Si je n'ai jamais construit de formulaires auparavant, alors "formulaires-plus" sera très convaincant car il est plus facile de commencer. L'inconvénient est que si "formes-plus" s'avère être une abstraction qui fuit, il me faudra quand même apprendre "formes". Si je construisais des formulaires sans "formulaires-plus", je devrais alors prendre en compte le temps nécessaire pour apprendre un nouvel outil. Le revers de la médaille, c’est que je connais déjà les «formes», je n’ai donc pas peur des abstractions. Les avantages à court terme seront souvent plus importants pour les nouveaux utilisateurs car il n'y aurait probablement pas de nouvelle bibliothèque si elle n'améliorait pas quelque chose. Les avantages à long terme varieront considérablement en termes de qualité de l'abstraction, du taux d'adoption,

Après avoir soigneusement évalué les avantages et les inconvénients de l’utilisation d’une nouvelle abstraction "formes-plus" par rapport à l’utilisation de "formes" à os nu, je prends une décision. La décision est fortement basée sur mes expériences personnelles et différentes personnes prendront une décision différente. J'aurais peut-être choisi d'utiliser des "formes" nues. Peut-être que plus tard dans le temps, formes-plus avait gagné plus de mouvement et était devenu un standard de facto. Et peut-être que ma propre mise en œuvre au fil du temps est devenue très complexe et a commencé à couvrir beaucoup de choses que font maintenant les formes-plus. Les gens qui viendront à ce moment-là seront amenés à critiquer le fait que je suis désireux de réinventer la roue et que j'aurais dû utiliser la bibliothèque existante à la place. Mais il est également possible qu’à l’époque où je devais prendre une décision au sujet de «formulaires plus», il y avait aussi de nombreuses autres alternatives à «formulaires plus»,

En fin de compte, le choix des bons outils est une décision compliquée à prendre et la "réinvention de la roue" n’est pas une perspective très utile.


-1

J'ai écrit un petit article à ce sujet - http://samueldelesque.tumblr.com/post/77811984752/what-re-re-inventing-the-wheel-can-teach-you

D'après mon expérience, la réinvention a été une bonne chose - bien que très longue et fastidieuse. Je dirais que si vous ne connaissez pas exactement les modèles de programmation que vous allez utiliser, écrivez-les vous-même (si vous avez le temps et l'énergie). Cela vous apprendra exactement ce que signifient ces modèles de programmation et vous deviendrez finalement un meilleur programmeur. Bien sûr, si vous travaillez pour un client et que vous avez juste besoin de faire quelque chose rapidement, vous voudrez probablement juste faire des recherches et trouver le bon logiciel pour vous.

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.