it-swarm.dev

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

Sa connaissance commune en programmation qui réinvente la roue est mauvaise ou mauvaise .

Mais pourquoi ça?

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

Cela m'amène à cette question:

Si je vois que 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, pour les arguments, supposons que leur méthode est tout aussi efficace que la méthode intégrée. Le développeur, conscient de la méthode intégrée, préfère également sa propre méthode.

Pourquoi devrait-il utiliser celui intégré dans le sien?

104
JD Isaacks

Comme je l'ai déjà publié sur StackOverflow, réinventer la roue est souvent un très bon choix, contrairement aux idées reçues. Le principal avantage est que vous avez controle total sur le logiciel, ce qui est souvent essentiel. Pour une discussion complète, voir mon message d'origine .

73
Dimitri C.

Dépend..

Comme pour tout, son contexte:

C'est bon quand:

  • Le framework ou la bibliothèque est trop lourd 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 est logique.
  • Vous avez quelque chose de différent à offrir, quelque chose que les autres implémentations n'ont pas. Peut être une nouvelle tournure, une nouvelle fonctionnalité, etc.

C'est mauvais 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 bogues ou des contraintes (par exemple, votre version n'est pas adaptée aux threads).
  • Votre version manque de fonctionnalités.
  • Votre version a une documentation pire.
  • Votre version manque de tests unitaires par rapport à ce qu'elle remplace.
83
Darknight

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. Surtout, cela se fait par ignorance, et parfois par entêtement.

C'est si mauvais? Oui. Pourquoi? Parce que la roue existante a très probablement été fabriquée au fil du temps et a déjà été testée dans de nombreuses circonstances et contre de nombreux types de données différents. Les développeurs de la roue existante ont déjà rencontré les Edge-cases et des difficultés que le réinventeur ne peut même pas encore imaginer.

56
Dan Ray

Les roues carrées doivent être réinventées. Les efforts qui craignent doivent être dupliqués. Peut-être qu'il y a un manque de documentation pour la méthode, et l'autre programmeur estime qu'il est plus facile de simplement écrire le leur plutôt que d'essayer de le 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.

Demandez-lui simplement quelle est la carence.

22
user8865

En général, j'évite de réinventer la roue si la fonctionnalité que je désire, ou quelque chose d'approximative, existe dans la bibliothèque standard de la langue que j'utilise.

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

Même si la bibliothèque est généralement bien connue et très appréciée dans l'industrie, elle reste une dépendance tierce . Les programmeurs mettent généralement l'accent sur les vertus de la réutilisation du code, tout en ignorant souvent le danger des dépendances. Un projet avec trop de dépendances tierces est susceptible de s'effondrer à long terme car il se transforme lentement en cauchemar de maintenance.

Tirer parti du code existant est donc bon - mais les dépendances sont mauvaises . Malheureusement, ces deux déclarations sont en désaccord, donc l'astuce consiste à 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. À partir de là, les bibliothèques très appréciées dans l'industrie sont également généralement acceptables (comme Boost pour C++, ou jQuery pour Javascript) - mais elles sont toujours moins souhaitable que la bibliothèque standard car ils le font ont tendance à être moins stables que les bibliothèques standard.

Quant aux bibliothèques qui sont relativement inconnues, (par exemple le dernier téléchargement sur SourceForge), ce sont des dépendances extrêmement risquées, et je recommanderais généralement de les éviter dans le code de production, à moins que vous ne soyez assez familier avec le code source pour les maintenir vous-même.

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

17
Charles Salvia

Si les gens ne réinventaient pas les roues, le monde en serait rempli. enter image description here

Voici un dialogue depuis 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: soit réinventer la roue OR utiliser Colorama. Voici ce que chaque option entraînerait:

Utilisation de Colorama

  • Peut-être un peu plus vite pour démarrer
  • Ajout d'une dépendance tierce 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 la couleur
  • Vous apprenez que des caractères spéciaux peuvent être utilisés pour colorier sur n'importe quel terminal
  • Vous pouvez colorier dans n'importe quel langage de programmation que vous pourriez utiliser à l'avenir
  • Votre projet est moins susceptible de se casser

Comme vous le voyez, tout dépend du contexte. Réinventer la roue est quelque chose que je fais très souvent parce que je veux être capable de penser par moi-même et ne pas compter sur d'autres personnes qui pensent pour moi. Si toutefois vous respectez une échéance ou si ce que vous essayez d'implémenter est énorme et existe déjà, vous feriez mieux d'utiliser ce qui est là.

14
Pithikos

Une raison utile de réinventer la roue est à des fins d'apprentissage - mais je recommanderais de le faire à votre rythme. À mesure que de nouvelles solutions pré-conservées deviennent disponibles et que davantage 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 la production.

Une autre chose - si un problème est la dépendance d'une bibliothèque tierce d'une entreprise qui peut disparaître, assurez-vous qu'il existe une option pour obtenir le code source, ou au moins quelques autres choix sur lesquels s'appuyer.

Soit dit en passant, si vous choisissez d'implémenter le 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 trop risqué de rouler le vôtre. Cela n'en vaut jamais la peine, et c'est effrayant que j'entende encore des équipes faire cela.

13
Mark Freedman

Il existe deux types d'efficacité: le traitement/la vitesse (c'est-à-dire la vitesse à laquelle il s'exécute) auquel il peut correspondre et la vitesse de développement qui ne le sera certainement pas. C'est la première raison - pour tout problème de complexité raisonnable où les solutions existantes sont disponibles, il sera presque certainement plus rapide de rechercher et d'implémenter 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) est testée et a fait ses preuves - probablement dans une gamme de scénarios beaucoup plus large qu'un développeur et qu'une équipe de test sera en mesure de mettre une nouvelle une routine écrite et cela ne nécessite aucun effort.

Troisièmement, c'est beaucoup plus facile à supporter. Non seulement quelqu'un d'autre le prend en charge et l'améliore (celui qui a écrit la bibliothèque/le composant), mais il est beaucoup plus probable que d'autres développeurs le connaîtront et pourront comprendre et maintenir le code à venir, ce qui minimise les coûts en cours.

Et tout cela suppose une équivalence fonctionnelle, ce qui n'est pas normalement le cas. Souvent, les bibliothèques offrent des fonctionnalités que vous jugeriez utiles mais qui ne pourraient jamais justifier leur intégration, qui sont soudainement disponibles gratuitement.

Il y a des raisons de lancer la vôtre - en grande partie là où vous voulez faire quelque chose que la fonction intégrée ne peut pas faire et où il y a un véritable avantage à gagner en le faisant, ou lorsque les options facilement disponibles ne sont pas matures - mais elles sont moins courants que de nombreux développeurs ne le croient.

D'ailleurs, pourquoi voudriez-vous passer votre temps à résoudre des problèmes qui ont déjà été résolus? Oui, c'est une excellente façon d'apprendre, mais vous ne devriez pas le faire au détriment de la bonne solution pour le code de production, ce dont je suppose que nous parlons.

9
Jon Hopkins

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

Souvent, lorsque je regarde une roue existante, elle fait bien plus que je n'en ai besoin, souffre de effet de plate-forme intérieure et est donc inutilement complexe, ou il manque une fonctionnalité clé que je fais besoin et qui serait difficile à mettre en œuvre en plus de ce qui existe déjà.

De plus, l'utilisation de roues existantes ajoute souvent des contraintes à mon projet dont je ne veux pas. Par exemple:

  • La roue existante nécessite un langage et/ou un style de programmation différent de celui que je préférerais autrement utiliser.
  • La roue existante ne fonctionne qu'avec la version héritée d'un langage (par exemple, Python 2 au lieu de Python 3).
  • Lorsqu'il existe des compromis entre efficacité, flexibilité et simplicité, la roue existante fait des choix qui ne sont pas optimaux pour mon cas d'utilisation. (J'ai été connu pour réinventer même les fonctionnalités des bibliothèques que j'avais écrites moi-même dans ces cas. Habituellement, c'est parce que j'ai écrit la version de bibliothèque de la fonction pour être générique et raisonnablement efficace, alors que j'ai actuellement besoin de quelque chose de très rapide dans mon domaine spécifique. Cas.)
  • La roue existante a des tonnes de cruches héritées qui sont totalement inutiles dans le cas d'un nouveau code mais rendent la vie néanmoins difficile (par exemple, une bibliothèque Java que j'utilise qui me force à utiliser ses classes de conteneurs merdiques parce que il a été écrit avant les génériques, etc.).
  • La façon 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 est peut-être pratique pour moi d'avoir un graphique dirigé représenté par des objets de nœud et des références, mais la roue existante utilise une matrice de contiguïté ou vice-versa. la roue existante insiste sur la ligne 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, lorsque tout ce dont j'ai besoin est un petit sous-ensemble de ses fonctionnalités. D'un autre côté, dans ce cas, je viens parfois d'extraire la fonctionnalité que je veux dans une nouvelle bibliothèque plus petite ou simplement de copier/coller si la bibliothèque est open source et que la base de code rend cela suffisamment simple. (J'ai même fait cela avec des bibliothèques relativement grandes que j'ai écrites moi-même, pas seulement avec celles d'autres personnes.)
  • La roue existante tente d'être conforme à la pédale avec une norme qui est à la fois gênante et non pertinente pour mon cas d'utilisation.
9
dsimcha

Souvent, j'utilise le mien parce que je l'ai construit avant de découvrir celui préexistant, 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 comprends peut-être pas une méthode préexistante. Et enfin, parce que je ne comprends pas complètement celui préexistant, je ne peux pas vérifier qu'il fait absolument tout ce que fait mon actuel.

Il y a beaucoup à coder et je n'ai pas beaucoup de temps pour revenir en arrière et recoder quelque chose à moins que cela n'ait un impact sur la production.

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

5
Rachel

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

  • Il faut beaucoup de temps pour faire la réinvention.
  • Il faut encore plus de temps pour documenter ce que vous avez inventé.
  • Vous ne pouvez pas embaucher des gens 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 continus pour les problèmes causés par la mauvaise conception.
  • Un nouveau code signifie de nouveaux bogues. L'ancien code a généralement déjà supprimé la plupart des bogues et peut contenir de subtiles solutions à des problèmes que vous ne connaissez pas et ne peut donc pas être contourné dans la nouvelle conception.

Le dernier est important - il y a un article de blog quelque part qui met en garde contre la tendance à "jeter l'ancien code et recommencer à zéro" sur la base du fait qu'une grande partie de la vieille cruauté que vous ne comprenez pas est 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 itérateur/curseur. Les insertions et les suppressions n'invalident pas les itérateurs. Un itérateur pointant vers un vecteur continuera à pointer vers le même élément (pas le même index), indépendamment des insertions et suppressions antérieures dans le vecteur. Vous ne pouvez tout 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 attention à la tendance à l'effet plateforme interne).
  • Contrôle complet - certains tiers ne peuvent pas décider de reconcevoir l'API d'une manière qui signifie que vous devez réécrire la moitié de votre application.
  • Compréhension complète - vous l'avez conçu de cette façon, vous espérez donc bien comprendre comment et pourquoi vous l'avez fait.
  • EDIT Vous pouvez tirer les leçons des autres bibliothèques sans être pris dans les mêmes pièges en étant sélectif sur la façon dont vous les imitez.

Une chose - l'utilisation d'une bibliothèque tierce peut être considérée comme 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 une bibliothèque tierce à la place. C'est peut-être une bonne idée à long terme - mais il peut y avoir énormément de travail et beaucoup de mauvaises surprises (à cause de subtiles différences sémantiques entre les bibliothèques) avant d'y arriver. Par exemple, considérez l'effet de mon passage de mes propres conteneurs à ceux de la bibliothèque standard. Une traduction naïve du code appelant ne permettrait pas le fait que les conteneurs de bibliothèque standard ne maintiennent pas leurs itérateurs. Les cas où j'enregistre un itérateur pour plus tard en tant que "signet" ne pouvaient pas être implémentés à l'aide d'une simple traduction - j'aurais besoin de moyens alternatifs non triviaux pour indiquer la position des signets.

4
Steve314

Réinventer la roue est un excellent moyen d'apprendre comment fonctionne une roue, mais ce n'est pas un bon moyen de construire une voiture.

4
Dima

Je travaille actuellement pour un tas de patins bon marché.

Lorsque la décision est prise entre "construire ou acheter", au lieu de prendre une décision rationnelle fondée sur l'économie, 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-homme à construire le nôtre. L'achat d'une roue auprès d'une autre entreprise coûte de l'argent qui sort du budget - ce qui compte contre les primes de fin d'année pour mauvaise gestion. Le temps des programmeurs est gratuit et ne compte donc pas dans les bonus de fin d'année (avec l'avantage supplémentaire de dinger les programmeurs pour ne pas tout faire "à temps"), donc une roue réinventée est un roue libre .

Dans une entreprise rationnelle, le coût par rapport aux avantages de l'achat de roues fabriquées par d'autres par rapport à la réinvention de ses propres roues serait basé sur les coûts à court terme et à long terme, ainsi que sur les coûts d'opportunité perdus parce que l'on ne peut pas créer de nouveaux widgets pendant que l'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 build vs buy .
Article sur build vs buy .

Si je vois que 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/framework. Tout d'abord, pour les arguments, supposons que leur méthode est tout 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 celui intégré dans le sien?

La version intégrée aura eu beaucoup plus de gens qui claquent dessus - trouvant et corrigeant ainsi plus de bugs que votre code homebrew ne peut jamais en avoir.

Enfin, lorsque votre développeur local quitte, et quelqu'un d'autre doit maintenir le code qu'il a écrit, il va être totalement refactorisé et remplacé par ce qui est dans le cadre. Je sais que cela se produira car mon employeur actuel a du code qui a été migré vers des versions plus récentes de VB au fil des ans (le plus ancien produit est sur le marché depuis environ 20 ans) et c'est ce que Le développeur avec le plus long emploi dans mon bureau est ici depuis 17 ans.

4
Tangurena

La chose à propos de réinventer la roue est qu'il n'y a parfois pas de roue standard prête à l'emploi qui fera ce dont vous avez besoin. Il y a beaucoup de bonnes roues, dans de nombreuses tailles, couleurs, matériaux et modes de construction. Mais certains jours, il suffit d'avoir une roue très légère en aluminium anodisé vert, et personne n'en fabrique. Dans ce cas, vous DEVEZ créer le vôtre.

Cela ne veut pas dire que vous devez fabriquer 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, alors vous créez les vôtres.

La chose la plus importante est de savoir QUAND faire votre propre. Vous devez avoir une bonne idée de ce que les pièces standard peuvent faire et de ce qu'elles ne peuvent pas avant de commencer à concevoir les vôtres.

4
Michael Kohne

Être "mauvais" ou même "mal" est un mot assez fort.

Comme toujours, il existe des raisons de choisir une implémentation personnelle plutôt qu'une implémentée. Autrefois, un programme C pouvait rencontrer des bogues dans la bibliothèque d'exécution, et donc simplement devoir fournir sa propre implémentation.

Cela ne s'applique pas aux programmes Java car la JVM est très strictement définie, mais certains algorithmes sont encore très difficiles à obtenir correctement. Par exemple, Joshua Bloch décrit comment l'algorithme de recherche binaire d'une simplicité trompeuse dans le Java contenait un bogue, qu'il a fallu neuf ans pour faire apparaître:

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 venez d'économiser du temps et de l'argent en demandant à Sun de travailler dur pour trouver, corriger et distribuer ce correctif. Vous pouvez tirer parti de leur travail en disant simplement "vous avez besoin d'au moins Java 6 update 10").

Si vous utilisez votre propre implémentation - qui contiendrait très probablement cette erreur également - vous devez d'abord que le bogue se manifeste. Étant donné que celui-ci ne s'affiche que sur les grands ensembles de données, il est inévitable qu'il se produise quelque part en production, 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.

Donc, il est parfaitement valable de préférer votre propre implémentation, mais il vaut mieux être vraiment bon, car il est forcément plus cher que de tirer parti du travail des autres.

3
user1249

S'il y a un composant fonctionnel qui fait ce dont vous avez besoin alors pourquoi passer du temps à écrire et déboguer votre propre version? De même, si vous avez déjà écrit du code pour remplir une fonction similaire auparavant, pourquoi le réécrire?

Joel a écrit n article sur Not-invented-here qui en dit long sur la réécriture de code et de logiciel qui n'est pas et n'est pas utile.

3
Dave

Réinventer la roue peut être un excellent moyen d'apprendre comment quelque chose fonctionne - et je recommande de réinventer juste pour cela à votre propre rythme - 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 du code JavaScript à partir de zéro; à la place, je commencerais par jQuery et créerais mes applications au-dessus de ce cadre.

3
Justin Ethier

Ma règle d'or personnelle:

Réinventer la roue, c'est bien quand on apprend. Si vous avez un délai, vous pouvez utiliser des roues existantes.

3
John

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

  1. Il est presque toujours mauvais de construire le vôtre, surtout si sa fonction est intégrée au langage. Mais si vous évaluez un cadre immature/entretenu de manière douteuse/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 horrible pour un logiciel anti-pattern. Cela implique que la solution d'origine 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 cesser de la maintenir. La roue a une valeur différente pour chaque système où elle est utilisée. Il est donc souvent tout à fait possible d'inventer une meilleure roue.

  3. L'un des principaux avantages de créer votre propre framework est que vous n'aurez pas à assumer la responsabilité des bugs de quelqu'un d'autre. (C'est la philosophie d'Amazon .) Pensez-y de cette façon: lequel de ceux-ci est le mieux à dire à un client? -

    "Notre site Web s'est cassé. 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, sauf attendre. Nous vous tiendrons au courant."

    "Notre site Web s'est cassé et nous avons pu le réparer immédiatement."

3
realworldcoder

C'est peut-être tout aussi efficace, mais est-il aussi robuste? Je pense que la raison la plus convaincante d'utiliser une bibliothèque au-dessus de la vôtre est que le cadre a tellement de gens qui l'utilisent qu'ils peuvent trouver et corriger rapidement les bogues. La bibliothèque développée en interne, bien qu'elle puisse fournir autant (ou plus) de fonctionnalités, ne peut pas rivaliser avec une bibliothèque avec des millions d'utilisateurs pour fournir des tests dans pratiquement tous les cas d'utilisation. Vous ne pouvez tout simplement pas battre ce genre de test en interne.

0
Michael K

Eh bien, sa propre méthode étant aussi efficace que le framework serait assez rare car la plupart des frameworks ont encore des bugs et aucun framework ne peut vous donner une solution prête à l'emploi. La plupart des programmeurs qui ne peuvent pas penser n'essaieront jamais d'écrire quoi que ce soit au niveau du framework; ils chercheront simplement sur Google une solution toute faite. Tout programmeur avisé verra d'abord s'il existe un framework gratuit qui possède les fonctionnalités dont il a besoin, puis rédigera lui-même la solution s'il n'y en a pas. Parfois, il est beaucoup 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 gens paresseux pour éviter de travailler dur. Même les auteurs de frameworks se réinventent; l'ensemble du cadre .Net a été réinventé pour faire ce que COM offrait.

0
Akash Kava

Aussi offensant que cela puisse être pour certains, j'ai toujours trouvé que ce terme était onclever lorsqu'il est utilisé par n'importe quelle forme d'ingénieur ou en référence à un sujet de création ou de conception de choses. En fait, je ne peux pas m'empêcher de le voir comme malhonnête quand on considère les pressions pour innover dans le monde trépidant d'aujourd'hui. Se répéter (ou ignorer des solutions adéquates préexistantes) n'est jamais sage, mais vraiment, il y a une raison pour laquelle nous ne regardons pas tous encore des écrans noirs remplis de lettres vertes.

Je comprends "Si ce n'est pas cassé, ne le répare pas", même si je suppose qu'une telle phrase peut sembler ignorante pour certains. Pourtant, avec l'effort actuel de réinventer la roue pour les besoins des voyages dans l'espace, de la course, de l'expédition, etc., "ne réinventez pas la roue" est également assez ignorant et n'est pas aussi intelligent qu'il y paraît.

Mon expérience consiste à diriger de nombreux projets et j'ai dû travailler avec de nombreux stagiaires et d'autres formes de développeurs verts, et j'ai dû gérer de nombreuses questions naïves que certains qualifieraient de "stupides", et j'ai également dû détourner les gens de courir après le lapin hors de la portée de leurs tâches. Cependant, je voudrais jamais décourager l'innovation ou la créativité, et j'ai vu de grandes choses provenir de "réinventer la roue".

Ma réponse à 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 gars qui le fait quand tu aurais pu

Edit: Je peux voir par les votes au volant que j'ai dû en offenser certains. La seule chose que je voudrais ajouter, c'est que cette phrase a toujours été une de mes principales 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
JSON

Les arguments sur "réinventer une roue" sont souvent utilisés dans un mauvais contexte pour choisir d'utiliser une bibliothèque, mais ce n'est guère la même chose.

Supposons que j'évalue une bibliothèque "formulaires plus", qui vient de devenir populaire récemment et aide à gérer les formulaires. Il a une belle page d'atterrissage, des graphismes sympas modernes et un -cult- (oups je veux dire communauté) autour de lui qui jure comment cela rend les formes encore plus belles. Mais "formulaires plus" est une abstraction au-dessus de "formulaires". les "formes" étaient possibles mais lourdes à traiter, donc l'abstraction qui la 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 nouveau dispositif de contrôle et à un nouveau manuel pour tout ce qui est déjà très compliqué à exécuter.

L'évaluation de ce nouvel appareil "formes-plus" sera différente selon l'expérience personnelle. Si je n'ai jamais créé de formulaires auparavant, "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, je devrai quand même apprendre les "formes". Si je construisais des formulaires sans "formulaires plus", je devrai prendre en compte le temps nécessaire pour apprendre un nouvel outil. Le bon côté est que je connais déjà des "formes" donc je n'ai pas peur des abstractions par dessus. Les avantages à court terme seront souvent plus importants pour les nouveaux débutants car il n'y aurait probablement pas de nouvelle bibliothèque si elle ne s'améliorait pas. Les avantages à long terme varieront considérablement en fonction de la qualité de l'abstraction, du taux d'adoption et d'autres facteurs déjà abordés dans d'autres réponses.

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" d'os nus, je prends une décision. La décision est fortement basée sur mes expériences personnelles et différentes personnes prendront des décisions différentes. J'aurais peut-être choisi d'utiliser des "formes" nues. Peut-être plus tard dans le temps, les formes-plus avaient gagné plus de mouvement derrière elles et devenaient une norme de facto. Et peut-être que ma propre implémentation au fil du temps est devenue velue et a commencé à couvrir beaucoup ce que les formulaires-plus font maintenant. Les gens qui viendront à ce moment-là seront attirés par la critique du fait que je souhaite réinventer la roue et que j'aurais dû utiliser la bibliothèque existante à la place. Mais il est également possible qu'au moment où je devais prendre une décision sur "formulaires-plus", il y avait également plusieurs autres alternatives à "formulaires-plus", la plupart d'entre eux étant des projets morts à ce jour, et j'ai peut-être gagné en ne choisissant pas le mauvais une.

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

0
Ski