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

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?

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 .

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.

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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 '

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.

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.

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.

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

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

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.

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.

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.

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.

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.