Ist es wirklich so schlimm, das Rad neu zu erfinden?

Es ist allgemein bekannt, dass es schlecht oder böse ist, das Rad neu zu erfinden .

Aber warum ist das so?

Ich behaupte nicht, dass es gut ist. Ich glaube es ist falsch. Ich habe jedoch einmal einen Artikel gelesen, in dem gesagt wurde, wenn jemand etwas falsch macht (programmiertechnisch), erkläre er ihnen, warum es falsch ist, wenn du es nicht kannst, dann solltest du dich vielleicht fragen, ob es wirklich falsch ist.

Das führt mich zu dieser Frage:

Wenn ich sehe, erfindet jemand das Rad eindeutig neu, indem er eine eigene Methode für etwas erstellt, das bereits in die Sprache / das Framework integriert ist. Nehmen wir zunächst an, dass ihre Methode aus Gründen der Argumentation genauso effizient ist wie die eingebaute Methode. Auch der Entwickler, der die eingebaute Methode kennt, bevorzugt seine eigene Methode.

Warum sollte er das eingebaute über sein eigenes benutzen?

Wie ich schon einmal auf StackOverflow gepostet habe, ist es oft eine sehr gute Wahl , das Rad neu zu erfinden , entgegen der landläufigen Meinung. Der Hauptvorteil besteht darin, dass Sie die volle Kontrolle über die Software haben, was häufig unerlässlich ist. Eine vollständige Diskussion finden Sie in meinem ursprünglichen Beitrag .

Hängt davon ab..

Wie bei allem geht es um den Kontext:

Es ist gut, wenn:

• Das Framework oder die Bibliothek ist zu schwer und Sie benötigen nur eingeschränkte Funktionen. Ein besserer Ansatz ist es, Ihre eigene extrem leichte Version zu entwickeln, die Ihren Anforderungen entspricht.
• Wenn Sie etwas Komplexes verstehen und lernen möchten, ist es sinnvoll, sich selbst zu drehen.
• Sie haben etwas anderes zu bieten als die Implementierungen anderer. Kann eine neue Wendung sein, eine neue Funktion usw.

Es ist schlimm, wenn:

• Funktionalität existiert bereits und ist als stabil und bekannt (populär) bekannt.
• Ihre Version fügt nichts Neues hinzu.
• Ihre Version enthält Fehler oder Einschränkungen (z. B. Ihre Version ist nicht threadsicher).
• In Ihrer Version fehlen Funktionen.
• Ihre Version hat eine schlechtere Dokumentation.
• Ihrer Version fehlen Unit-Tests im Vergleich zu dem, was sie ersetzt.

Ich denke, der Fall, dass ein Entwickler das Rad wissentlich neu erfindet, "weil er seine eigene Methode bevorzugt", ist ziemlich selten. Meistens geschieht dies aus Unwissenheit und manchmal aus Sturheit.

Ist das alles so schlimm? Ja. Warum? Denn das vorhandene Rad wurde höchstwahrscheinlich im Laufe der Zeit hergestellt und bereits unter vielen Umständen und anhand vieler verschiedener Arten von Daten getestet. Die Entwickler des vorhandenen Rades sind bereits auf die Randfälle und Schwierigkeiten gestoßen, die sich der Neuerfinder noch nicht einmal vorstellen kann.

Vierkanträder müssen neu erfunden werden. Anstrengungen, die scheiße sind, müssen verdoppelt werden. Möglicherweise fehlt es an Dokumentation für die Methode, und der andere Programmierer ist der Ansicht, dass es einfacher ist, nur seine eigene zu schreiben, als zu versuchen, es herauszufinden. Möglicherweise ist der Aufruf der Methode umständlich und passt nicht in die Programmiersprache.

Fragen Sie ihn einfach, was der Mangel ist.

Im Allgemeinen vermeide ich es, das Rad neu zu erfinden, wenn die von mir gewünschte Funktionalität oder eine Annäherung daran in der Standardbibliothek der von mir verwendeten Sprache vorhanden ist.

Wenn ich jedoch Bibliotheken von Drittanbietern einbinden muss, ist dies ein Urteil, je nachdem, wie weit verbreitet und geschätzt die Bibliothek ist. Ich meine, reden wir über Boost oder Bobs Kick-Ass String-Parsing Tools 1.0?

Auch wenn die Bibliothek in der gesamten Branche allgemein bekannt und geschätzt ist, handelt es sich dennoch um eine Abhängigkeit von Drittanbietern . Programmierer legen im Allgemeinen großen Wert auf die Vorzüge der Wiederverwendung von Code, während sie häufig die Gefahr von Abhängigkeiten verschleiern. Ein Projekt mit zu vielen Abhängigkeiten von Drittanbietern wird wahrscheinlich langfristig auseinanderfallen, da es sich langsam in einen Wartungs-Albtraum verwandelt.

Die Nutzung des vorhandenen Codes ist also gut, aber die Abhängigkeiten sind schlecht . Leider sind diese beiden Aussagen nicht miteinander vereinbar, weshalb der Trick darin besteht, das richtige Gleichgewicht zu finden. Aus diesem Grund müssen Sie akzeptable Abhängigkeiten identifizieren . Wie ich bereits sagte, ist alles in der Standardbibliothek der Sprache höchstwahrscheinlich eine akzeptable Abhängigkeit. Der Umzug von da an Bibliotheken , die in der Branche hoch angesehen werden , sind im Allgemeinen auch akzeptabel (wie Boost - für C ++ oder jQuery für Javascript) - aber sie sind noch weniger wünschenswert als der Standard Library , weil sie sich neigen dazu , weniger stabil zu sein als standardisierte Bibliotheken .

Bei Bibliotheken, die relativ unbekannt sind (z. B. der letzte Upload auf SourceForge), handelt es sich um äußerst riskante Abhängigkeiten, und ich würde generell empfehlen, diese im Produktionscode zu vermeiden, es sei denn, Sie sind mit dem Quellcode vertraut genug, um sie selbst zu verwalten.

Es ist also wirklich alles ein Balanceakt. Aber der Punkt ist, dass nur blind gesagt wird: "Code wiederverwenden gut! Rad neu erfinden schlecht!" ist eine gefährliche Haltung. Die Vorteile der Nutzung von Drittanbieter-Code müssen gegen die Nachteile der Einführung von Abhängigkeiten abgewogen werden.

Wenn die Leute die Räder nicht neu erfinden würden, wäre die Welt voll davon.

Hier ist ein Dialog von meinem Arbeitsplatz:

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

Es gibt zwei Möglichkeiten: entweder das Rad neu erfinden oder Colorama verwenden. Daraus würde sich für jede Option Folgendes ergeben:

Colorama verwenden

• Vielleicht etwas schneller zum Laufen
• Hinzufügen einer Drittanbieterabhängigkeit für etwas Triviales
• Sie sind weiterhin so dumm wie vor der Verwendung von Colorama

Das Rad neu erfinden

• Sie verstehen, wie manche Programme Farbe anzeigen können
• Sie lernen, dass Sonderzeichen zum Ausmalen auf jedem Terminal verwendet werden können
• Sie können in jeder Programmiersprache einfärben, die Sie in Zukunft verwenden werden
• Es ist weniger wahrscheinlich, dass Ihr Projekt abbricht

Wie Sie sehen, hängt alles vom Kontext ab. Das Rad neu zu erfinden ist etwas, was ich sehr oft tue, weil ich in der Lage sein und für mich selbst denken will und mich nicht darauf verlassen will, dass andere Leute für mich denken. Wenn Sie jedoch eine bestimmte Frist einhalten oder die zu implementierenden Maßnahmen sehr umfangreich sind und bereits existieren, ist es besser, die vorhandenen Maßnahmen zu verwenden.

Ein nützlicher Grund, das Rad neu zu erfinden, sind Lernzwecke - aber ich würde empfehlen, es in Ihrer Freizeit zu tun. Je mehr vordefinierte Lösungen verfügbar sind und je mehr Abstraktionsebenen bereitgestellt werden, desto produktiver werden wir. Wir können uns eher auf das Geschäftsproblem konzentrieren als auf die allgemeinen Dinge, die immer wieder optimiert wurden. ABER aus diesem Grund können Sie Ihre Fähigkeiten schärfen und viel lernen, indem Sie versuchen, eine eigene Lösung erneut zu implementieren. Nur nicht unbedingt für die Produktion.

Eine andere Sache - wenn es sich um die Abhängigkeit von einer Drittanbieter-Bibliothek eines Unternehmens handelt, die möglicherweise verschwindet, stellen Sie sicher, dass es eine Option gibt, den Quellcode abzurufen, oder zumindest ein paar andere Möglichkeiten, auf die Sie zurückgreifen können.

Übrigens, wenn Sie Ihre eigenen implementieren möchten, vermeiden Sie dies für die Kryptografie oder andere sicherheitsrelevante Funktionen. Dafür gibt es etablierte (und vollständig getestete) Tools, und heutzutage ist es viel zu riskant, eigene Tools zu entwickeln. Das ist es nie wert und es ist beängstigend, dass ich immer noch von Teams höre, die das tun.

Es gibt zwei Arten von Effizienz - Verarbeitung / Geschwindigkeit (so schnell wird es ausgeführt), mit der es möglicherweise mithalten kann, und Entwicklungsgeschwindigkeit, die mit ziemlicher Sicherheit nicht erreicht wird. Das ist der erste Grund - für jedes Problem von angemessener Komplexität, bei dem vorhandene Lösungen verfügbar sind, ist es mit ziemlicher Sicherheit schneller, eine vorhandene Bibliothek zu recherchieren und zu implementieren, als Ihre eigene zu codieren .

Der zweite Grund ist, dass die vorhandene Bibliothek (vorausgesetzt, sie ist ausgereift) getestet wurde und nachweislich funktioniert - wahrscheinlich in einem viel breiteren Spektrum von Szenarien als ein Entwickler, und ein Testteam wird in der Lage sein, eine neu geschriebene Routine durchzuarbeiten, und dies kommt zustande Null Aufwand.

Drittens ist es viel einfacher zu unterstützen. Es wird nicht nur von jemand anderem unterstützt und verbessert (wer auch immer die Bibliothek / Komponente geschrieben hat), es ist auch viel wahrscheinlicher, dass andere Entwickler damit vertraut sind und in der Lage sind, den Code für die Zukunft zu verstehen und zu warten Kosten.

Und das alles setzt funktionale Äquivalenz voraus, was normalerweise nicht der Fall ist. Häufig bieten Bibliotheken Funktionen an, die Sie als nützlich erachten, die das Einrichten jedoch niemals rechtfertigen könnten. All diese Funktionen sind plötzlich kostenlos verfügbar.

Es gibt Gründe, sich selbstständig zu machen - hauptsächlich dort, wo Sie etwas tun möchten, was die eingebaute Funktion nicht kann und wo dies einen echten Vorteil bietet oder wo die verfügbaren Optionen nicht ausgereift sind -, aber sie sind seltener als viele Entwickler vermuten.

Außerdem, warum sollten Sie Ihre Zeit damit verbringen, bereits gelöste Probleme zu lösen? Ja, es ist eine großartige Möglichkeit zu lernen, aber Sie sollten dies nicht auf Kosten der richtigen Lösung für Produktionscode tun. Ich gehe davon aus, dass es sich um das handelt, worüber wir sprechen.

Natürlich aus Unwissenheit und Arroganz das Rad aus einer Laune heraus neu zu erfinden, kann eine schlechte Sache sein, aber meiner Meinung nach ist das Pendel zu weit geschwungen. Es ist ein enormer Vorteil, ein Rad zu haben, das genau das tut , was Sie wollen, und nicht mehr .

Wenn ich mir ein vorhandenes Rad anschaue, leidet es oft viel mehr als ich es brauche, leidet unter dem inneren Plattformeffekt und ist daher unnötig komplex, oder es fehlt ein Schlüsselmerkmal, das ich brauche, und das wäre schwierig zusätzlich zu dem implementieren, was bereits vorhanden ist.

Darüber hinaus werden meinem Projekt durch die Verwendung vorhandener Räder häufig Einschränkungen hinzugefügt, die ich nicht möchte. Zum Beispiel:

• Das vorhandene Rad erfordert eine andere Sprache und / oder einen anderen Programmierstil, als ich es sonst bevorzugen würde.
• Das vorhandene Rad funktioniert nur mit der älteren Version einer Sprache (z. B. Python 2 anstelle von Python 3).
• Wo es Kompromisse zwischen Effizienz, Flexibilität und Einfachheit gibt, trifft das vorhandene Rad Entscheidungen, die für meinen Anwendungsfall nicht optimal sind. (Es ist bekannt, dass ich in diesen Fällen sogar die Funktionalität von Bibliotheken neu erfunden habe, die ich ursprünglich selbst geschrieben habe. Normalerweise liegt es daran, dass ich die Bibliotheksversion der Funktion als generisch und einigermaßen effizient geschrieben habe, wenn ich derzeit etwas benötige, das in meinem speziellen sehr schnell ist Fall.)
• Das vorhandene Rad verfügt über Tonnen von veralteter Cruft, die im Fall von neuem Code völlig nutzlos sind, das Leben jedoch erschweren (z. B. eine von mir verwendete Java-Bibliothek, die mich dazu zwingt, die beschissenen Container-Klassen zu verwenden, da sie vor Generika usw. geschrieben wurden). .
• Die Art und Weise, wie das Problem bei den vorhandenen Radmodellen auftritt, ist völlig anders als in meinem Anwendungsfall. (Vielleicht ist es für mich praktisch, einen gerichteten Graphen durch Knotenobjekte und Referenzen darstellen zu lassen, aber das vorhandene Rad verwendet eine Adjazenzmatrix oder umgekehrt. Vielleicht ist es für mich praktisch, meine Daten in der Hauptreihenfolge der Spalten anzuordnen, aber die vorhandenes Rad besteht auf Zeilensprung oder umgekehrt.)
• Die Bibliothek fügt eine massive, spröde Abhängigkeit hinzu, die ein großer Aufwand wäre, um überall dort, wo ich meinen Code bereitstellen möchte, einsatzbereit zu sein, wo ich nur eine kleine Teilmenge seiner Funktionen benötige. Andererseits extrahiere ich in diesem Fall manchmal einfach das gewünschte Feature in eine neue, kleinere Bibliothek oder kopiere / füge es einfach ein, wenn die Bibliothek Open Source ist und die Codebasis dies ausreichend einfach macht. (Ich habe das sogar mit relativ großen Bibliotheken gemacht, die ich selbst geschrieben habe, nicht nur mit denen anderer Leute.)
• Das vorhandene Rad versucht, pedantisch einer Norm zu entsprechen, die für meinen Anwendungsfall sowohl unpraktisch als auch irrelevant ist.

Oft benutze ich meine eigene, weil ich sie gebaut habe, bevor ich die bereits existierende entdeckt habe, und ich bin zu faul, um jede Instanz zu finden und zu ersetzen. Außerdem verstehe ich meine eigene Methode vollständig, während ich eine bereits existierende Methode möglicherweise nicht verstehe. Und schließlich kann ich, da ich das bereits existierende nicht vollständig verstehe, nicht überprüfen, ob es absolut alles tut, was mein jetziges tut.

Es gibt viel zu programmieren, und ich habe nicht viel Zeit, um zurückzugehen und etwas neu zu programmieren, es sei denn, dies wirkt sich auf die Produktion aus.

Tatsächlich verfügt eine Asp-Webanwendung, die noch heute verwendet wird, über ein voll funktionsfähiges Diagramm, das Daten in einem Tabellenformat anzeigt und das Sortieren / Bearbeiten ermöglicht, jedoch kein Datagrid ist. Es wurde vor ein paar Jahren gebaut, als ich asp.net zum ersten Mal lernte und keine Ahnung von Datagrids hatte. Ich habe ein bisschen Angst vor dem Code, da ich keine Ahnung habe, was ich damals gemacht habe, aber er funktioniert, ist genau, lässt sich leicht ändern, stürzt nicht ab und die Benutzer lieben ihn

Das Rad neu zu erfinden ist eine großartige Möglichkeit zu lernen, wie ein Rad funktioniert, aber es ist keine gute Möglichkeit, ein Auto zu bauen.

Ich arbeite derzeit für ein paar Geizhals.

Wenn die Entscheidung zwischen "Bauen oder Kaufen" getroffen wurde, entschieden sich die Manager für "Bauen", anstatt eine rationale, auf Wirtschaftlichkeit basierende Entscheidung zu treffen. Dies bedeutet, dass wir nicht nur ein paar tausend Dollar für eine Komponente oder ein Werkzeug zahlen, sondern monatelang selbst bauen müssen. Der Kauf eines Rades von einem anderen Unternehmen kostet Geld, das aus dem Budget herauskommt - was gegen schlecht verwaltete Jahresendboni ankommt. Die Zeit der Programmierer ist frei und wird daher nicht auf die Jahresendprämien angerechnet (mit dem zusätzlichen Vorteil, dass die Programmierer dafür sorgen, dass nicht alles "pünktlich" erledigt wird). Daher ist ein neu erfundenes Rad ein Freilauf .

In einem rationalen Unternehmen würden die Kosten im Vergleich zu den Vorteilen des Kaufs von Rädern anderer gegenüber der Neuerfindung der eigenen Räder auf den kurzfristigen und langfristigen Kosten sowie den verlorenen Opportunitätskosten basieren, da man keine neuen Widgets erstellen kann, während man es ist Räder neu erfinden. Jeder Tag, an dem Sie das Rad neu erfinden, ist ein anderer Tag, an dem Sie nichts Neues schreiben können.

Präsentation zu Build vs Buy .
Artikel über Build vs Buy .

Wenn ich sehe, erfindet jemand das Rad eindeutig neu, indem er eine eigene Methode für etwas erstellt, das bereits in die Sprache / das Framework integriert ist. Nehmen wir zunächst an, dass ihre Methode aus Gründen der Argumentation genauso effizient ist wie die eingebaute Methode. Auch der Entwickler, der die eingebaute Methode kennt, bevorzugt seine eigene Methode.

Warum sollte er das eingebaute über sein eigenes benutzen?

Die eingebaute Version wird viel mehr Leute dazu gebracht haben, damit mehr Fehler gefunden und behoben werden können, als Ihr Homebrew-Code jemals haben kann.

Wenn Ihr lokaler Entwickler das Programm verlässt und jemand anderes den von ihm geschriebenen Code warten muss, wird er komplett überarbeitet und durch den Code im Framework ersetzt. Ich weiß, dass dies passieren wird, da mein aktueller Arbeitgeber über einen Code verfügt, der im Laufe der Jahre auf neuere Versionen von VB migriert wurde (das älteste Produkt ist seit etwa 20 Jahren auf dem Markt), und genau das ist passiert. Der Entwickler mit der längsten Beschäftigung in meinem Büro ist seit 17 Jahren hier.

Das Besondere an der Neuerfindung des Rads ist, dass es manchmal kein handelsübliches Standardrad gibt, das genau das tut, was Sie brauchen. Es gibt viele gute Räder in vielen Größen, Farben, Materialien und Konstruktionsweisen. Aber an manchen Tagen muss man nur ein wirklich leichtes Rad haben, das aus grün eloxiertem Aluminium besteht, und niemand stellt es her. In diesem Fall MÜSSEN Sie Ihre eigenen erstellen.

Das soll nicht heißen, dass Sie für jedes Projekt Ihre eigenen Räder bauen sollten - die meisten Dinge können Standardteile verwenden und besser dafür sein. Aber hin und wieder stellen Sie fest, dass die Standardteile einfach nicht funktionieren, also machen Sie Ihre eigenen.

Das Wichtigste ist zu wissen, WANN Sie Ihre eigenen machen. Sie müssen eine gute Vorstellung davon haben, was die Standardteile können und was nicht, bevor Sie beginnen, Ihre eigenen zu entwerfen.

Die Frage, ob das Rad neu erfunden werden soll oder nicht, ist eine Frage des Kosten-Nutzen-Verhältnisses. Die Kosten sind ziemlich offensichtlich ...

• Die Neuerfindung nimmt viel Zeit in Anspruch.
• Es dauert noch länger zu dokumentieren, was Sie erfunden haben.
• Sie können keine Leute einstellen, die bereits verstehen, was Sie erfunden haben.
• Es ist nur allzu leicht, etwas falsch zu erfinden, was für die Probleme, die durch das schlechte Design verursacht werden, laufende Kosten verursacht.
• Neuer Code bedeutet neue Fehler. In der Regel wurden die meisten Fehler bereits aus dem alten Code entfernt, und es können subtile Problemumgehungen für Probleme auftreten, die Sie nicht kennen und die Sie im neuen Design daher nicht umgehen können.

Das Letzte ist wichtig - es gibt irgendwo einen Blog-Beitrag, der vor der Tendenz warnt, "den alten Code wegzuwerfen und von vorne zu beginnen", auf der Grundlage, dass ein Großteil der alten Cruft, die Sie nicht verstehen, tatsächlich wesentliche Bugfixes sind. Es gibt eine warnende Geschichte über Netscape, IIRC.

Die Vorteile können sein ...

• Die Möglichkeit, Funktionen hinzuzufügen, über die vorhandene Bibliotheken nicht verfügen. Zum Beispiel habe ich Container, die ihre Iterator- / Cursor-Instanzen "pflegen". Einfügungen und Löschungen machen Iteratoren nicht ungültig. Ein in einen Vektor zeigender Iterator zeigt weiterhin auf dasselbe Element (nicht auf denselben Index), unabhängig davon, ob der Vektor zuvor eingefügt oder gelöscht wurde. Dies ist mit Standard-C ++ - Containern einfach nicht möglich.
• Ein spezialisierteres Design, das auf Ihre speziellen Anforderungen zugeschnitten ist und Ihre Prioritäten berücksichtigt (achten Sie jedoch auf die Tendenz zum Effekt der inneren Plattform).
• Vollständige Kontrolle - Einige Drittanbieter können sich nicht dazu entschließen, die API so umzugestalten, dass Sie die Hälfte Ihrer Anwendung neu schreiben müssen.
• Umfassendes Verständnis - Sie haben es so entworfen, sodass Sie hoffentlich vollständig verstehen, wie und warum Sie dies getan haben.
• BEARBEITEN Sie können die Lektionen aus anderen Bibliotheken lernen, ohne in die gleichen Fallen geraten zu müssen, indem Sie selektiv festlegen, wie Sie sie imitieren.

Eine Sache - die Verwendung einer Bibliothek eines Drittanbieters kann als Neuerfindung des Rads gelten. Wenn Sie bereits eine alte, gut genutzte und getestete Bibliothek besitzen, überlegen Sie genau, bevor Sie sie verwerfen, und verwenden Sie stattdessen eine Bibliothek eines Drittanbieters. Auf lange Sicht mag es eine gute Idee sein - aber es kann eine Menge Arbeit und böse Überraschungen (aufgrund subtiler semantischer Unterschiede zwischen den Bibliotheken) geben, bevor Sie dort ankommen. Betrachten Sie zum Beispiel den Effekt, dass ich von meinen eigenen Containern zu den Standardcontainern der Bibliothek wechsle. Eine naive Übersetzung von aufrufendem Code würde nicht die Tatsache berücksichtigen, dass die Standard-Bibliothekscontainer ihre Iteratoren nicht beibehalten. Fälle, in denen ich einen Iterator für später als "Lesezeichen" speichere, konnten mit einer einfachen Übersetzung überhaupt nicht implementiert werden.

Wenn es eine funktionierende Komponente gibt, die genau das tut, was Sie brauchen, warum sollten Sie dann die Zeit damit verbringen, Ihre eigene Version zu schreiben und zu debuggen? Wenn Sie bereits Code geschrieben haben, um eine ähnliche Funktion zu erfüllen, warum sollten Sie ihn dann erneut schreiben?

Joel hat einen Artikel über Not-invented-here geschrieben, der darüber spricht, wann das Neuschreiben von Code und Software nicht und nicht nützlich ist.

Das Rad neu zu erfinden kann eine großartige Möglichkeit sein, um zu lernen, wie etwas funktioniert - und ich empfehle, es zu diesem Zweck in Ihrer Freizeit neu zu erfinden -.

Zum Beispiel würde ich niemals JavaScript-Code von Grund auf neu schreiben. Stattdessen würde ich mit jQuery beginnen und meine Anwendungen auf diesem Framework aufbauen.

Meine persönliche Faustregel:

Das Rad neu zu erfinden ist gut, wenn man nur lernt. Wenn Sie eine Frist haben, können Sie vorhandene Räder verwenden.

"Böse" oder sogar "böse" zu sein, sind ziemlich starke Worte.

Wie immer gibt es Gründe, eine persönliche Implementierung einer eingebauten vorzuziehen. In den alten Tagen könnte ein C - Programm auf Fehler stoßen in der Laufzeitbibliothek, und daher einfach haben ihre eigene Umsetzung.

Dies gilt nicht für Java-Programme, da die JVM sehr streng definiert ist, es jedoch immer noch sehr schwierig ist, einige Algorithmen zu finden. Zum Beispiel beschreibt Joshua Bloch, wie der täuschend einfache binäre Suchalgorithmus in der Java-Laufzeitbibliothek einen Fehler enthielt, für dessen Aufdeckung neun Jahre benötigt wurden:

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

Es wurde in zukünftigen Java-Distributionen gefunden, repariert und verteilt.

Wenn Sie die integrierte Binärsuche verwenden, haben Sie nur Zeit und Geld gespart, indem Sie Sun die harte Arbeit beim Auffinden, Beheben und Verteilen dieses Bugfixes ausführen ließen. Sie können ihre Arbeit nutzen, indem Sie nur sagen, dass Sie mindestens Java 6 Update 10 benötigen.

Wenn Sie eine eigene Implementierung verwenden, die sehr wahrscheinlich auch diesen Fehler enthalten würde, müssen Sie zuerst den Fehler finden, um sich zu manifestieren. Angesichts der Tatsache, dass diese Version nur in GROSSEN Datensätzen angezeigt wird, wird sie in der Produktion irgendwo auftreten, was bedeutet, dass mindestens einer Ihrer Kunden betroffen ist und höchstwahrscheinlich echtes Geld verliert, während Sie den Bugfix finden, reparieren und verteilen.

Es ist also durchaus sinnvoll, eine eigene Implementierung zu bevorzugen, aber der Grund dafür ist besser, da dies mit Sicherheit teurer ist, als die Arbeit anderer zu nutzen.

Ich habe kürzlich meine Gedanken zu diesem Thema gebloggt . Zusammenfassen:

1. Es ist fast immer böse, seine eigenen zu bauen, besonders wenn es eine Funktion ist, die in die Sprache eingebaut ist. Aber wenn Sie ein unreifes / fragwürdig gepflegtes / schlecht dokumentiertes Framework, das Sie im Internet gefunden haben, gegen die Möglichkeit, Ihr eigenes zu schreiben, bewerten, könnte dies ein Kinderspiel sein.

2. Ich denke, das Rad neu zu erfinden ist eine ziemlich schreckliche Analogie für ein Software-Anti-Pattern. Dies impliziert, dass die ursprüngliche Lösung niemals verbessert werden kann. Das ist doch Unsinn. Das sogenannte Rad kann über Nacht veralten oder von seinen Besitzern nicht mehr gewartet werden. Das Rad hat bei jedem verwendeten System einen anderen Wert. So ist es oft durchaus möglich, ein besseres Rad zu erfinden.

3. Ein großer Vorteil der Erstellung eines eigenen Frameworks besteht darin, dass Sie nicht die Verantwortung für die Fehler anderer übernehmen müssen. (Dies ist die Philosophie von Amazon .) Stellen Sie sich das so vor: Welches davon ist besser, um es einem Kunden mitzuteilen? -

   "Unsere Website ist kaputt gegangen. Es war die Schuld eines anderen, und wir haben einen Fehler beim Ersteller gemeldet. Wir können nichts dagegen tun, außer warten. Wir halten Sie auf dem Laufenden."

   "Unsere Website ist kaputt gegangen und wir konnten sie sofort reparieren."

Vielleicht ist es genauso effizient, aber genauso robust? Ich denke, der überzeugendste Grund, eine Bibliothek anstelle der eigenen zu verwenden, ist, dass das Framework von so vielen Benutzern verwendet wird, dass sie Fehler schnell finden und beheben können. Eigenentwickelte Bibliotheken bieten zwar möglicherweise genau so viele (oder mehr) Funktionen, können jedoch nicht mit einer Bibliothek mit Millionen von Benutzern konkurrieren, um Tests in nahezu jedem Anwendungsfall bereitzustellen. Diese Art von internen Tests ist einfach nicht zu übertreffen.

Nun, seine eigene Methode, so effizient wie Framework zu sein, wäre ziemlich selten, da die meisten Frameworks immer noch Fehler aufweisen und kein Framework Ihnen eine sofort einsatzbereite Lösung bieten kann. Die meisten Programmierer, die nicht denken können, werden niemals versuchen, etwas auf Framework-Ebene zu schreiben. Sie suchen einfach bei Google nach einer vorgefertigten Lösung. Jeder weise Programmierer wird zuerst prüfen, ob es ein freies Framework gibt, das die von ihm benötigten Funktionen bietet, und dann die Lösung selbst schreiben, wenn dies nicht der Fall ist. Manchmal ist es viel zu schwierig, die aktuelle Projektlage zu erklären, und der Entwickler ist der beste Richter.

Das Rad neu zu erfinden ist nicht schlecht, es ist eine Aussage fauler Leute, die vermeiden wollen, hart zu arbeiten. Sogar Framework-Autoren erfinden neu. Das gesamte .NET-Framework wurde neu erfunden, um das zu tun, was COM anbietet.

So anstößig es für manche auch sein mag, ich habe diesen Begriff immer als unclever empfunden, wenn er von irgendeiner Form von Ingenieur verwendet wird oder sich auf ein Thema bezieht, bei dem es um das Erstellen oder Entwerfen von Dingen geht. In der Tat kann ich nicht anders, als es als unaufrichtig zu betrachten, wenn man den Innovationsdruck in der heutigen schnelllebigen Welt betrachtet. Sich zu wiederholen (oder adäquate, bereits existierende Lösungen zu ignorieren) ist niemals klug, aber es gibt einen Grund, warum wir nicht immer noch alle auf schwarze Bildschirme voller grüner Buchstaben starren.

Ich verstehe, "wenn es nicht kaputt ist, repariere es nicht", obwohl ich vermute, dass ein solcher Satz für manche unwissend klingt. Doch angesichts der derzeitigen Bemühungen, das Rad für die Bedürfnisse der Raumfahrt, des Rennsports, der Schifffahrt usw. neu zu erfinden, ist "das Rad nicht neu erfinden" auch ziemlich unwissend und bei weitem nicht so clever, wie es sich anhört.

Mein Hintergrund besteht darin, viele Projekte zu leiten, und ich musste mit vielen Praktikanten und anderen grünen Entwicklern zusammenarbeiten, mich mit vielen naiven Fragen befassen, die manche als "dumm" bezeichnen würden, und Leute davon abhalten, Kaninchen zu jagen Ganzheiten außerhalb ihres Aufgabenbereichs. Ich würde mich jedoch niemals von Innovation oder Kreativität abbringen lassen und habe gesehen, wie großartige Dinge daraus entstanden sind, das Rad neu zu erfinden.

Meine eigentliche Antwort auf die Frage: Es gibt nur zwei Situationen, in denen es schlecht ist, das Rad neu zu erfinden:

1. Wenn es nicht wirklich gebraucht wird
2. Wenn es der andere ist, der es tut, wenn Sie es könnten

Edit: Ich kann an den Drive-by-Down-Stimmen erkennen, dass ich einige beleidigt haben muss. Die eine Sache, die ich hinzufügen möchte, ist, dass dieser Satz schon immer ein großes Ärgernis für mich war. Ich verstehe, dass meine zwei Cent ziemlich trollig klingen, aber ich habe nicht die Absicht zu trollen, Brände zu verursachen oder zu beleidigen.

Argumente zur "Neuerfindung eines Rades" werden oft im falschen Kontext verwendet, wenn man sich für die Verwendung einer Bibliothek entscheidet, aber es ist kaum ähnlich.

Nehmen wir an, ich bewerte eine Bibliothek mit dem Namen "Forms-Plus", die erst kürzlich populär wurde und beim Umgang mit Formularen hilft. Es hat eine schöne Landingpage, moderne coole Grafiken und eine -cult- (oops ich meine Community), die schwören, wie es macht, dass Formulare wieder großartig sind. "Forms-plus" ist jedoch eine Abstraktion über "forms". "Formen" waren möglich, aber umständlich zu handhaben, so dass Abstraktion, die es einfacher macht, populär wird.

Ständig passieren neue Abstraktionen. Es ist schwer, sie mit Rädern zu vergleichen. Es ist eher wie ein neues Steuergerät und ein neues Handbuch für jedes bereits sehr komplizierte Gerät, das Sie ausführen müssen.

Die Bewertung dieses neuen Geräts "forms-plus" wird je nach persönlicher Erfahrung unterschiedlich aussehen. Wenn ich noch nie zuvor Formulare erstellt habe, wird "forms-plus" sehr überzeugend sein, da der Einstieg einfacher ist. Nachteil ist, dass ich, wenn sich "forms-plus" als undichte Abstraktion herausstellt, trotzdem "forms" lernen muss. Wenn ich Formulare ohne "forms-plus" erstellt habe, muss ich die Zeit berücksichtigen, die ich zum Erlernen eines neuen Tools benötige. Der Vorteil ist, dass ich bereits "Formen" kenne, sodass ich keine Angst vor darüber liegenden Abstraktionen habe. Kurzfristige Vorteile sind für Neueinsteiger häufig größer, da es wahrscheinlich keine neue Bibliothek geben würde, wenn sich nichts verbessern würde. Langfristige Vorteile variieren stark in Bezug auf Abstraktionsqualität, Akzeptanzrate,

Nach sorgfältiger Abwägung der Vor- und Nachteile der Verwendung einer neuen Abstraktion "Forms-Plus" im Vergleich zur Verwendung von "Forms-Plus" ohne Knochen entscheide ich mich. Die Entscheidung basiert in hohem Maße auf meinen persönlichen Erfahrungen und verschiedene Leute werden unterschiedliche Entscheidungen treffen. Ich hätte mich vielleicht dafür entschieden, nackte "Formen" zu verwenden. Vielleicht hatte forms-plus später mehr Bewegung hinter sich und wurde zu einem Defacto-Standard. Und vielleicht wurde meine eigene Implementierung im Laufe der Zeit haarig und deckte eine Menge dessen ab, was forms-plus jetzt tut. Die Leute, die zu dieser Zeit kommen, werden bemängelt, dass ich das Rad unbedingt neu erfinden möchte und stattdessen die vorhandene Bibliothek hätte nutzen sollen. Es ist aber auch möglich, dass es zu der Zeit, als ich mich für "forms-plus" entscheiden musste, noch mehrere andere Alternativen zu "forms-plus" gab.

Letztendlich ist die Auswahl der richtigen Werkzeuge eine komplizierte Entscheidung, und "Neuerfindung des Rades" ist keine sehr hilfreiche Perspektive.

Ich habe einen kleinen Artikel darüber geschrieben - http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

Nach meiner Erfahrung war die Neuerfindung großartig - wenn auch sehr langwierig und langwierig. Ich würde sagen, wenn Sie die zu verwendenden Programmiermodelle nicht genau kennen, schreiben Sie sie selbst (wenn Sie Zeit und Energie haben). Auf diese Weise erfahren Sie, was genau diese Programmiermodelle bedeuten, und werden letztendlich zu einem besseren Programmierer. Wenn Sie für einen Kunden arbeiten und nur schnell etwas erledigen möchten, möchten Sie wahrscheinlich nur ein wenig recherchieren und die richtige Software für Sie finden.