it-swarm.dev

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

Sein allgemeines Wissen in der Programmierung, dass die Neuerfindung des Rades schlecht oder böse ist.

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 es heißt, wenn jemand etwas falsch macht (programmtechnisch), erkläre ihm, warum es falsch ist. Wenn Sie es nicht können, sollten Sie sich vielleicht fragen, ob es wirklich falsch ist.

Das führt mich zu dieser Frage :

Wenn ich sehe, dass jemand das Rad eindeutig neu erfindet, indem er seine eigene Methode für etwas entwickelt, das bereits in die Sprache/das Framework integriert ist. Nehmen wir zunächst an, dass ihre Methode genauso effizient ist wie die integrierte Methode. Auch der Entwickler, der sich der eingebauten Methode bewusst ist, bevorzugt seine eigene Methode.

Warum sollte er den eingebauten über seinen eigenen verwenden?

104
JD Isaacks

Wie ich einmal auf StackOverflow gepostet habe, ist es eine Neuerfindung des Rades oft eine sehr gute Wahl, entgegen der landläufigen Meinung. Der Hauptvorteil ist, dass Sie haben volle Kontrolle über die Software, die oft unerlässlich ist. Für eine vollständige Diskussion siehe meinen ursprünglichen Beitrag .

73
Dimitri C.

Hängt davon ab..

Wie bei allem geht es um den Kontext:

Es ist gut wenn :

  • Framework oder Bibliothek ist zu schwer und Sie benötigen nur eingeschränkte Funktionen. Das Rollen Ihrer eigenen extrem leichten Version, die Ihren Anforderungen entspricht, ist ein besserer Ansatz.
  • Wenn Sie etwas Komplexes verstehen und lernen möchten, ist es sinnvoll, sich selbst zu rollen.
  • Sie haben etwas anderes zu bieten, etwas, das die Implementierungen anderer nicht haben. Kann eine neue Wendung, eine neue Funktion usw. sein.

Es ist schlecht wenn :

  • Funktionalität existiert bereits und ist bekanntermaßen stabil und bekannt (beliebt).
  • Ihre Version fügt nichts Neues hinzu.
  • Ihre Version führt Fehler oder Einschränkungen ein (z. B. ist Ihre Version 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.
83
Darknight

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

Ist das alles so schlimm? Ja. Warum? Weil das vorhandene Rad höchstwahrscheinlich im Laufe der Zeit hergestellt wurde und bereits unter vielen Umständen und gegen viele verschiedene Arten von Daten getestet wurde. Die Entwickler des vorhandenen Rads sind bereits auf die Edge-Fälle und Schwierigkeiten gestoßen, die sich der Neuerfinder noch nicht einmal vorstellen kann.

56
Dan Ray

Vierkanträder müssen neu erfunden werden. Bemühungen, die saugen, müssen dupliziert werden. Möglicherweise fehlt es an Dokumentation für die Methode, und der andere Programmierer ist der Meinung, dass es einfacher ist, nur eigene zu schreiben, als es herauszufinden. Vielleicht ist die Art und Weise, wie die Methode aufgerufen wird, umständlich und passt nicht in die Sprache der Programmiersprache.

Fragen Sie ihn einfach, was der Mangel ist.

22
user8865

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

Wenn ich jedoch Bibliotheken von Drittanbietern einbeziehen muss, ist dies eine Entscheidung, die davon abhängt, 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 Branche allgemein bekannt und hoch geschätzt ist, handelt es sich immer noch um eine Drittanbieter-Abhängigkeit Abhängigkeit. Programmierer legen im Allgemeinen großen Wert auf die Vorteile der Wiederverwendung von Code, während sie häufig die Gefahr von Abhängigkeiten beschönigen. Ein Projekt mit zu vielen Abhängigkeiten von Drittanbietern wird auf lange Sicht wahrscheinlich auseinanderfallen, da es sich langsam in einen Wartungsalptraum verwandelt.

Die Nutzung des vorhandenen Codes ist also gut - aber Abhängigkeiten sind schlecht. Leider sind diese beiden Aussagen im Widerspruch zueinander, so dass der Trick darin besteht, das richtige Gleichgewicht zu finden. Deshalb müssen Sie akzeptabel Abhängigkeiten identifizieren. Wie gesagt, alles in der Standardbibliothek der Sprache ist höchstwahrscheinlich eine akzeptable Abhängigkeit. Von da an sind Bibliotheken, die in der Branche hoch angesehen sind, ebenfalls allgemein akzeptabel (wie Boost für C++ oder jQuery für Javascript) - aber sie sind immer noch weniger wünschenswert als die Standardbibliothek, weil sie do sind in der Regel weniger stabil als standardisierte Bibliotheken.

Bibliotheken, die relativ unbekannt sind (z. B. der letzte Upload auf SourceForge), sind ä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 man blind sagt: "Code wiederverwenden gut! Rad schlecht neu erfinden!" ist eine gefährliche Einstellung. Die Vorteile der Nutzung von Code von Drittanbietern muss Gegen die Nachteile der Einführung von Abhängigkeiten abgewogen werden.

17
Charles Salvia

Wenn die Leute die Räder nicht neu erfinden würden, wäre die Welt mit diesen gefüllt. enter image description here

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 OR Colorama verwenden. Hier ist, was jede Option ergeben würde:

Verwenden von Colorama

  • Vielleicht etwas schneller zum Laufen
  • Hinzufügen einer Drittanbieterabhängigkeit für etwas Triviales
  • Sie sind weiterhin so dumm wie zuvor mit Colorama

Das Rad neu erfinden

  • Sie verstehen, wie einige Programme Farben anzeigen können
  • Sie lernen, dass Sonderzeichen zum Färben auf jedem Terminal verwendet werden können
  • Sie können in jeder Programmiersprache färben, die Sie in Zukunft verwenden könnten
  • Es ist weniger wahrscheinlich, dass Ihr Projekt kaputt geht

Wie Sie sehen, hängt alles vom Kontext ab. Das Rad neu zu erfinden ist etwas, was ich sehr oft mache, weil ich in der Lage sein und für mich selbst denken möchte und mich nicht darauf verlassen möchte, dass andere Leute für mich denken. Wenn Sie jedoch eine Frist einhalten oder das, was Sie implementieren möchten, sehr groß ist und bereits vorhanden ist, sollten Sie besser das verwenden, was vorhanden ist.

14
Pithikos

Ein nützlicher Grund, das Rad neu zu erfinden, sind Lernzwecke - aber ich würde empfehlen, es in Ihrer eigenen Zeit zu tun. Je mehr vorgefertigte Lösungen verfügbar werden und 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 Lösung selbst neu zu implementieren. Nur nicht unbedingt für den Produktionseinsatz.

Eine andere Sache: Wenn ein Problem die Abhängigkeit von einer Drittanbieter-Bibliothek eines Unternehmens ist, das möglicherweise verschwindet, stellen Sie sicher, dass es eine Option gibt, um den Quellcode abzurufen, oder zumindest einige andere Optionen, auf die Sie zurückgreifen können.

Übrigens, wenn Sie sich für die Implementierung Ihrer eigenen entscheiden, vermeiden Sie dies für Kryptografie oder andere sicherheitsrelevante Funktionen. Dafür stehen etablierte (und vollständig getestete) Tools zur Verfügung, und heutzutage ist es viel zu riskant, eigene zu rollen. Das ist es nie wert und es ist beängstigend, dass ich immer noch von Teams höre, die dies tun.

13
Mark Freedman

Es gibt zwei Arten von Effizienz - Verarbeitung/Geschwindigkeit (dh wie schnell sie ausgeführt wird), mit der sie möglicherweise übereinstimmt, und Entwicklungsgeschwindigkeit, die sie mit ziemlicher Sicherheit nicht erreicht. 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 wird und nachweislich funktioniert - wahrscheinlich in einem weitaus breiteren Spektrum von Szenarien, als ein Entwickler und ein Testteam in der Lage sein werden, eine neue zu erstellen schriftliche Routine durch und dies kommt ohne Aufwand.

Drittens ist es viel einfacher zu unterstützen. Nicht nur jemand anderes unterstützt und verbessert es (wer auch immer die Bibliothek/Komponente geschrieben hat), sondern es ist weitaus wahrscheinlicher, dass andere Entwickler damit vertraut sind und das verstehen und warten können Code für die Zukunft, wodurch die laufenden Kosten minimiert werden.

Und das alles setzt funktionale Äquivalenz voraus, was normalerweise nicht der Fall ist. Häufig bieten Bibliotheken Funktionen, die Sie nützlich finden, aber niemals einbauen können. All diese Funktionen stehen plötzlich kostenlos zur Verfügung.

Es gibt Gründe, sich selbst zu rollen - hauptsächlich dort, wo Sie etwas tun möchten, was die eingebaute Funktion nicht kann, und wo dies einen echten Vorteil bringt oder wo die leicht verfügbaren Optionen nicht ausgereift sind -, aber sie sind weniger verbreitet als viele Entwickler glauben machen würden.

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, von der ich annehme, dass wir hier sprechen.

9
Jon Hopkins

Natürlich kann es eine schlechte Sache sein, das Rad aus einer Laune heraus aus Unwissenheit und Arroganz neu zu erfinden, 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 nichts weiter.

Wenn ich mir ein vorhandenes Rad anschaue, macht es oft mehr als nötig, leidet unter dem innerer Plattformeffekt und ist daher unnötig komplex, oder es fehlt eine wichtige Funktion, die ich mache brauchen und das wäre schwierig zu implementieren, zusätzlich zu dem, was bereits da ist.

Darüber hinaus führt die Verwendung vorhandener Räder häufig zu Einschränkungen für mein Projekt, 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 Legacy-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 sogar Funktionen aus Bibliotheken neu erfinde, die ich ursprünglich in diesen Fällen selbst geschrieben habe. Normalerweise liegt es daran, dass ich die Bibliotheksversion der Funktion generisch und einigermaßen effizient geschrieben habe, wenn ich derzeit etwas benötige, das in meinem speziellen Bereich sehr schnell ist Fall.)
  • Das vorhandene Rad hat Tonnen von Legacy-Cruft, die im Fall von neuem Code völlig nutzlos sind, aber dennoch das Leben erschweren (zum Beispiel eine Java -Bibliothek, die ich benutze, die mich zwingt, ihre beschissenen Containerklassen zu verwenden, weil es wurde vor Generika usw. geschrieben).
  • Die Art und Weise, wie das vorhandene Rad das Problem modelliert, unterscheidet sich grundlegend von der für meinen Anwendungsfall geeigneten. (Zum Beispiel ist es für mich vielleicht bequem, 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 bequem, meine Daten in der Hauptreihenfolge der Spalten anzuordnen, aber die vorhandenes Rad besteht auf Reihenmajor oder umgekehrt.)
  • Die Bibliothek fügt eine massive, spröde Abhängigkeit hinzu, die ein großer Aufwand wäre, wenn ich meinen Code überall dort bereitstellen möchte, wo ich nur eine kleine Teilmenge seiner Funktionen benötige. Andererseits extrahiere ich in diesem Fall manchmal einfach die gewünschte Funktion in eine neue, kleinere Bibliothek oder kopiere/füge sie einfach ein, wenn die Bibliothek Open Source ist und die Codebasis dies ausreichend einfach macht. (Ich habe dies sogar mit relativ großen Bibliotheken gemacht, die ich selbst geschrieben habe, nicht nur mit denen anderer Leute.)
  • Das vorhandene Rad versucht, pedantisch einem Standard zu entsprechen, der für meinen Anwendungsfall sowohl unpraktisch als auch irrelevant ist.
9
dsimcha

Oft benutze ich meine eigene, weil ich sie erstellt habe, bevor ich die bereits vorhandene 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 möglicherweise eine bereits vorhandene nicht verstehe. Und schließlich kann ich, da ich das bereits vorhandene nicht vollständig verstehe, nicht überprüfen, ob es absolut alles tut, was mein aktuelles tut.

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

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

5
Rachel

Ob das Rad neu erfunden werden soll oder nicht, ist eine Kosten-Nutzen-Sache. Die Kosten liegen auf der Hand ...

  • Die Neuerfindung nimmt viel Zeit in Anspruch.
  • Es dauert noch länger, um zu dokumentieren, was Sie erfunden haben.
  • Sie können keine Leute einstellen, die bereits verstehen, was Sie erfunden haben.
  • Es ist allzu leicht, etwas schlecht neu zu erfinden, was zu laufenden Kosten für die Probleme führt, die durch das schlechte Design verursacht werden.
  • Neuer Code bedeutet neue Fehler. Bei altem Code wurden in der Regel die meisten Fehler bereits entfernt, und es gibt möglicherweise subtile Problemumgehungen für Probleme, die Sie nicht kennen und daher im neuen Design nicht umgehen können.

Letzteres ist wichtig - irgendwo gibt es einen Blog-Beitrag, der vor der Tendenz warnt, "den alten Code wegzuwerfen und von vorne zu beginnen", da viele 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 Iterator, der auf einen Vektor zeigt, zeigt weiterhin auf dasselbe Element (nicht denselben Index), unabhängig von Einfügungen und Löschungen früher im Vektor. Mit Standard-C++ - Containern ist das einfach nicht möglich.
  • Ein spezielleres Design, das auf Ihre speziellen Anforderungen zugeschnitten ist und Ihre Prioritäten respektiert (achten Sie jedoch auf die Tendenz zum Effekt der inneren Plattform).
  • Vollständige Kontrolle - Einige Drittanbieter können sich nicht dafür entscheiden, die API so neu zu gestalten, dass Sie die Hälfte Ihrer Anwendung neu schreiben müssen.
  • Vollständiges Verständnis - Sie haben es so gestaltet, dass Sie hoffentlich vollständig verstehen, wie und warum Sie dies getan haben.
  • EDIT 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 Rades gelten. Wenn Sie bereits über eine eigene alte, gut genutzte und gut getestete Bibliothek verfügen, überlegen Sie sorgfältig, bevor Sie diese verwerfen, um stattdessen eine Bibliothek eines Drittanbieters zu verwenden. Auf lange Sicht mag es eine gute Idee sein - aber es kann eine Menge Arbeit und viele böse Überraschungen (aufgrund subtiler semantischer Unterschiede zwischen den Bibliotheken) geben, bevor Sie dort ankommen. Betrachten Sie beispielsweise den Effekt, dass ich von meinen eigenen Containern zu Standardbibliotheken wechsle. Eine naive Übersetzung des aufrufenden Codes würde nicht die Tatsache berücksichtigen, dass die Standardbibliothekscontainer ihre Iteratoren nicht verwalten. Fälle, in denen ich einen Iterator für später als "Lesezeichen" speichere, konnten mit einer einfachen Übersetzung überhaupt nicht implementiert werden - ich würde einige nicht triviale alternative Mittel zum Anzeigen von Lesezeichenpositionen benötigen.

4
Steve314

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.

4
Dima

Ich arbeite zurzeit für ein paar billige Skates.

Wenn die Entscheidung zwischen "Bauen oder Kaufen" getroffen wird, anstatt eine rationale Entscheidung auf der Grundlage der Wirtschaftlichkeit zu treffen, entschieden sich die Manager für "Bauen". Dies bedeutet, dass wir, anstatt ein paar tausend Dollar für eine Komponente oder ein Werkzeug zu zahlen, Mannmonate damit verbringen, unsere eigenen zu bauen. Der Kauf eines Rades von einem anderen Unternehmen kostet Geld, das aus dem Budget stammt - was auf schlecht verwaltete Jahresendboni angerechnet wird. Die Zeit der Programmierer ist frei und wird daher nicht auf die Jahresendboni angerechnet (mit dem zusätzlichen Vorteil, dass die Programmierer dafür verantwortlich sind, dass nicht alles "pünktlich" erledigt wird). Daher ist ein neu erfundenes Rad ein Freilauf .

In einem rationalen Unternehmen würden die Kosten gegenüber den Vorteilen des Kaufs von Rädern anderer Hersteller gegenüber der Neuerfindung der eigenen Räder auf kurzfristigen und langfristigen Kosten sowie auf Opportunitätskosten basieren, die verloren gehen, weil man währenddessen keine neuen Widgets erstellen kann 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, dass jemand das Rad eindeutig neu erfindet, indem er seine eigene Methode für etwas entwickelt, das bereits in die Sprache/das Framework integriert ist. Nehmen wir zunächst an, dass ihre Methode genauso effizient ist wie die integrierte Methode. Auch der Entwickler, der sich der eingebauten Methode bewusst ist, bevorzugt seine eigene Methode.

Warum sollte er den eingebauten über seinen eigenen verwenden?

In der integrierten Version werden viel mehr Leute darauf herumhüpfen - so werden mehr Fehler gefunden und behoben, als Ihr Homebrew-Code jemals haben kann.

Wenn Ihr lokaler Entwickler abreist und jemand anderes den von ihm geschriebenen Code beibehalten muss, wird er vollständig überarbeitet und durch den Code ersetzt, der ist im Rahmen. Ich weiß, dass dies passieren wird, weil mein aktueller Arbeitgeber Code hat, der im Laufe der Jahre auf neuere Versionen von VB (das älteste Produkt ist seit etwa 20 Jahren auf dem Markt) migriert wurde Der Entwickler mit der längsten Beschäftigung in meinem Büro ist seit 17 Jahren hier.

4
Tangurena

Die Sache bei der Neuerfindung des Rades ist, dass es manchmal kein Standardrad von der Stange gibt, das 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 eines her. In diesem Fall MÜSSEN Sie Ihre eigenen machen.

Das heißt nicht, dass Sie für jedes Projekt Ihre eigenen Räder herstellen sollten - die meisten Dinge können Standardteile verwenden und sind besser dafür. 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 müssen. Sie müssen eine gute Vorstellung davon haben, was die Standardteile können und was nicht, bevor Sie mit dem Entwerfen Ihrer eigenen beginnen.

4
Michael Kohne

"Schlecht" oder sogar "böse" zu sein, ist ein ziemlich starkes Wort.

Wie immer gibt es Gründe, eine persönliche Implementierung einer integrierten vorzuziehen. Früher konnte ein C-Programm auf Fehler in der Laufzeitbibliothek stoßen und muss daher einfach eine eigene Implementierung bereitstellen.

Dies gilt nicht für Java -Programme, da die JVM sehr streng definiert ist, aber einige Algorithmen sind immer noch sehr schwer zu korrigieren. Zum Beispiel beschreibt Joshua Bloch, wie der täuschend einfache binäre Suchalgorithmus in der Java Laufzeitbibliothek enthielt einen Fehler, dessen Auftauchen neun Jahre dauerte:

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

Es wurde in Zukunft gefunden, behoben und verteilt Java Distributionen).

Wenn Sie die integrierte binäre Suche verwenden, haben Sie nur Zeit und Geld gespart, indem Sun die harte Arbeit geleistet hat, diesen Bugfix zu finden, zu beheben und zu verteilen. Sie können ihre Arbeit nutzen, indem Sie einfach sagen: "Sie benötigen mindestens Java 6 Update 10".

Wenn Sie Ihre eigene Implementierung verwenden, die höchstwahrscheinlich auch diesen Fehler enthalten würde, muss sich der Fehler zuerst manifestieren. Da dieses spezielle nur in GROSSEN Datensätzen angezeigt wird, muss es irgendwo in der Produktion vorkommen, was bedeutet, dass mindestens einer Ihrer Kunden betroffen ist und höchstwahrscheinlich echtes Geld verliert, während Sie den Bugfix finden, beheben und verteilen.

Es ist also durchaus richtig, die eigene Implementierung zu bevorzugen, aber der Grund ist besser, wirklich gut zu sein, da dies sicherlich teurer ist als die Nutzung der Arbeit anderer.

3
user1249

Wenn es eine funktionierende Komponente gibt, die genau das tut, was Sie benötigen , 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 neu schreiben?

Joel schrieb ein Artikel über Nicht erfunden hier, der Bände darüber spricht, wann das Umschreiben von Code und Software nicht nützlich ist und nicht.

3
Dave

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 -, aber wenn Sie eine Anwendung schreiben, warum neu erfinden, wenn es gut etablierte Lösungen gibt, die bereits dasselbe tun?

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.

3
Justin Ethier

Meine persönliche Faustregel:

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

3
John

Ich habe vor kurzem meine Gedanken gebloggt zu diesem Thema. Zusammenfassen:

  1. Es ist fast immer böse, eigene zu bauen, besonders wenn es eine Funktion ist, die in die Sprache eingebaut ist. Wenn Sie jedoch ein unreifes/fragwürdig gepflegtes/schlecht dokumentiertes Framework, das Sie im Internet gefunden haben, gegen die Möglichkeit des Schreibens eines eigenen Frameworks bewerten, kann dies ein Kinderspiel sein.

  2. Ich denke, das Rad neu 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 Unsinn. Das sogenannte Rad kann über Nacht veraltet sein oder seine Besitzer könnten aufhören, es zu warten. Das Rad hat an jedem System, an dem es verwendet wird, einen anderen Wert. So ist es oft durchaus möglich, ein besseres Rad zu erfinden.

  3. Ein wesentlicher Vorteil der Erstellung Ihres eigenen Frameworks besteht darin, dass Sie nicht die Verantwortung für die Fehler anderer übernehmen müssen. (Dies ist Amazonas Philosophie .) Stellen Sie sich das so vor: Welche davon ist besser, um es einem Kunden zu sagen? - -

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

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

3
realworldcoder

Vielleicht ist es genauso effizient, aber genauso robust? Ich denke, der überzeugendste Grund, eine Bibliothek über das Rollen Ihrer eigenen zu verwenden, ist, dass das Framework so viele Benutzer verwendet, dass sie Fehler schnell finden und beheben können. Eigenentwickelte Bibliotheken bieten zwar genauso 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 Tests im eigenen Haus ist einfach nicht zu übertreffen.

0
Michael K

Nun, seine eigene Methode, die so effizient wie das Framework ist, 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 werden nur Google nach einer vorgefertigten Lösung durchsuchen. Jeder weise Programmierer wird zuerst prüfen, ob es ein kostenloses Framework gibt, das die von ihm benötigte Funktionalität 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 von faulen Leuten, um harte Arbeit zu vermeiden. Sogar Framework-Autoren erfinden neu. Das gesamte .Net-Framework wurde neu erfunden, um das zu tun, was COM anbot.

0
Akash Kava

So beleidigend es für manche auch sein mag, ich habe diesen Begriff immer als Onkel empfunden, wenn er von irgendeiner Form von Ingenieur verwendet wird oder in Bezug auf ein Thema des Erstellens oder Entwerfens von Dingen. Tatsächlich kann ich nicht anders, als es als unaufrichtig anzusehen, wenn man den Innovationsdruck in der heutigen schnelllebigen Welt betrachtet. Sich zu wiederholen (oder angemessene, bereits vorhandene Lösungen zu ignorieren) ist niemals klug, aber es gibt einen Grund, warum wir nicht alle immer noch auf schwarze Bildschirme voller grüner Buchstaben starren.

Ich verstehe "Wenn es nicht kaputt ist, repariere es nicht", obwohl ich denke, dass ein solcher Satz für manche unwissend klingt. 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" ebenfalls 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 Formen grüner Entwickler zusammenarbeiten. Ich musste mich mit vielen naiven Fragen befassen, die manche als „dumm“ bezeichnen würden, und ich musste auch Leute davon abhalten, Kaninchen zu jagen Ganzes außerhalb des Aufgabenbereichs. Ich würde jedoch nie von Innovation oder Kreativität abraten und habe großartige Dinge gesehen, wenn ich das Rad neu erfunden habe.

Meine eigentliche Antwort auf die Frage: Es gibt nur zwei Situationen, in denen es eine schlechte Sache 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

Bearbeiten: 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 immer ein großer Pet-Peeve von mir war. Ich verstehe, dass meine zwei Cent vielleicht eher trollisch klingen, aber ich habe nicht die Absicht zu trollen, Feuer zu verursachen oder zu beleidigen.

0
JSON

Argumente über die "Neuerfindung eines Rades" werden oft im falschen Kontext der Wahl einer Bibliothek verwendet, aber es ist kaum ähnlich.

Angenommen, ich evaluiere eine Bibliothek 'Forms-Plus', die erst kürzlich populär geworden ist und beim Umgang mit Formularen hilft. Es hat eine schöne Landingpage, moderne coole Grafiken und einen -cult- (oops ich meine Community), der schwört, wie es macht, Formulare wieder großartig zu machen. Aber "Forms-Plus" ist eine Abstraktion über "Forms". "Formen" waren möglich, aber umständlich zu handhaben, so dass eine Abstraktion, die es einfacher macht, immer beliebter wird.

Es entstehen ständig 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, ist "Forms-Plus" sehr überzeugend, da der Einstieg einfacher ist. Nachteil ist, dass wenn "Forms-Plus" sich als undichte Abstraktion herausstellt, ich trotzdem "Formulare" lernen muss. Wenn ich Formulare ohne "Forms-Plus" erstellt habe, muss ich die Zeit berücksichtigen, die ich zum Erlernen neuer Tools benötige. Der Vorteil ist, dass ich bereits "Formen" kenne, sodass ich keine Angst vor Abstraktionen darüber habe. Kurzfristige Vorteile sind für Neueinsteiger oft größer, da es wahrscheinlich keine neue Bibliothek geben würde, wenn sie etwas nicht verbessern würde. Die langfristigen Vorteile hängen stark von der Qualität der Abstraktion, der Adoptionsrate und anderen Faktoren ab, die bereits in anderen Antworten erörtert wurden.

Nachdem ich die Vor- und Nachteile einer neuen Abstraktion "Forms-Plus" im Vergleich zur Verwendung von "Bare-Bone" -Formen "sorgfältig abgewogen habe, treffe ich eine Entscheidung. Die Entscheidung basiert in hohem Maße auf meinen persönlichen Erfahrungen und verschiedene Menschen werden unterschiedliche Entscheidungen treffen. Ich hätte mich vielleicht für nackte "Formen" entschieden. Vielleicht hatte Formen-Plus später mehr Bewegung dahinter und wurde zu einem Defacto-Standard. Und vielleicht wurde meine eigene Implementierung im Laufe der Zeit haarig und begann viel darüber zu berichten, was Forms-Plus jetzt tut. Leute, die zu dieser Zeit kommen, werden kritisiert, 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, mehrere andere Alternativen zu "Forms-Plus" gab, die meisten davon inzwischen tote Projekte, und möglicherweise habe ich gewonnen, indem ich nicht das falsche gewählt habe einer.

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

0
Ski