Sehr oft muss man die Empfehlung "Rad nicht neu erfinden" erfüllen. Manchmal mit ausgeprägter Vernachlässigung und Selbstbestätigung, manchmal angeblich als guter Rat. Selbst wenn es als gut beratener Rat bezeichnet wurde, zeigt es in einer Reihe von Zusammenhängen nur die Inkompetenz des Sprechers.
Der verschachtelte Zweck des Satzes besteht darin, Sie vor der nutzlosen Arbeit, dem Aufruf, eine vorgefertigte Lösung für die Aufgabe zu verwenden, zu bewahren, und aus der Sicht eines externen Beobachters sieht er wirklich vernünftig aus.
Gleichzeitig wird jedoch ein Schlüsselfaktor übersehen, der nicht nur für die Softwareentwicklung, sondern auch für die Lösung von Problemen charakteristisch ist : Wenn Sie den Kontext ändern, in dem die Aufgabe festgelegt ist, ändert sich auch die Lösung .
Dieses Prinzip aus den Augen zu verlieren, ist dasselbe wie zuzugeben, dass Sie nicht in der Lage sind, angewandte Probleme zu lösen.
Betrachten Sie einige Fälle.
Quelle
API über API
Einer der häufigsten Fälle von Vorwürfen des Radfahrens ist der selbstschreibende API-Wrapper eines Dienstes, dessen Implementierung bereits verfügbar ist.
Ein Fall aus meiner Praxis.
Es war notwendig, den Upload von Daten von Facebook zu unserem Service zu implementieren. Die Mainstream-Sprache und die Bibliothek von Facebook selbst wurden in 2 Minuten gegoogelt.
Die Bibliotheksdokumentation entsprach nicht der aktuellen Programmoberfläche , es wurden viele unnötige Aktionen um jede Manipulation gewickelt. Die Bibliothek erwies sich als von sehr schlechter Qualität .
Ergebnis: Nach 1,5 Stunden Arbeit war es nicht einmal möglich, sich anzumelden.
Ein Kollege hat seinen eigenen Facebook-Web-API-Wrapper implementiert. Insgesamt brauchte er ungefähr eine Stunde, um einen Wrapper und die dazugehörigen Funktionen auf der Serviceseite zu erstellen. Auf die Frage "Warum radeln Sie hier ? " Antwortete er in den nächsten Tagen.
Dies zeigt sich insbesondere in Mainstream-Sprachen mit einer großen Community: Es gibt eine ungesunde Tendenz, API-Wrapper über eine andere API unter den Slogans "Für Menschen" und "Auf einfache Weise" zu veröffentlichen. Solche Wrapper werden veraltet, sobald die verpackte Oberfläche aktualisiert wird, und die Autoren geben solche "Projekte" auf, wodurch der Code, der sie verwendet, funktionsunfähig wird.
Eine gute Frage : und was, jedes Mal, um solche Wrapper manuell zu schreiben?
Antwort: Eine viel stärkere Lösung für große Wrapper wäre die Verwendung eines Codegenerators, der die Spezifikationen interpretiert.
Kontrolle über die Codebasis und Weigerung, für die Fehler anderer zu antworten
In Möchtegernkreisen bei der Entwicklung von Computerspielen richtet sich dieser Satz an alle, die es wagen, ihre Engine zu implementieren. "Warum das Rad neu erfinden? Einheit nehmen!" . Oder Game Maker oder, Gott bewahre, Defold.
Es scheint, dass der dviglo \ -Konstruktor alle notwendigen Werkzeuge für die Entwicklung bereitstellt. Viele von ihnen sind plattformübergreifend und vereinfachen im Allgemeinen das Leben.
Wie sollte sich der Kontext hier ändern, damit es notwendig wird, eine eigene Engine zu erstellen?
Zumindest ist dies die Kontrolle über die Codebasis und die Engine-Funktionen (zum Beispiel ist der Spielehersteller bei einer Reihe von Controller-Modellen durchweg fehlerhaft, und das Beheben dieses Problems kann äußerst problematisch sein). Das heißt, es ist notwendig, die Wahrscheinlichkeit zu verringern, dass ein „fremder Fehler“ auftritt , der entweder unmöglich oder äußerst schwierig allein zu beheben ist.
Dies ist besonders ausgeprägt bei Spielen, die nicht mit grafischen und / oder physischen Schnickschnack gesättigt sind - kitschig, nicht so sehr, wie es die bedingte Engine selbst übernimmt.
Darüber hinaus ist es nicht erforderlich, die Gesamtmenge der Codebasis zu erhöhen, wenn ein kleiner Teil ihrer Funktionen von der Engine / dem Konstruktor verwendet wird, und die erforderlichen Tools müssen weiterhin unabhängig hinzugefügt werden , um gleichzeitig die Richtigkeit ihrer Arbeit mit der Engine zu steuern.
Basierend auf solchen Prämissen schrieb Tommy Refenes beispielsweise seinen eigenen Motor für Super Meat Boy .
Jemand wird Einwände erheben : "Aber im Lagerhaus \ einem anderen Speicher gibt es einen Berg von Presets \ Tools \ Erweiterungen!" .
Ja, es ist wunderbar und gibt ein paar Punkte Vorsprung, aber bei Motoren mit einer großen aktiven Benutzerbasis wird der gleiche wie im vorherigen Abschnitt beschriebene "Die Young" -Effekt durchaus beobachtet. Ohne einen Kontext und eine bestimmte Aufgabe kann nicht eindeutig behauptet werden, dass die Fülle an Benutzererweiterungen im Geschäft in die Hände spielt.
Imaginäre Identität. Die Aufgabe an den Ohren ziehen.
Manchmal stellt sich nach der Formulierung des Problems heraus, dass vorhandene Lösungen, die mir in den Sinn kommen, nicht geeignet sind. Aufgrund seines "Fettgehalts" oder der Unzufriedenheit mit einer der Schlüsselbedingungen der Aufgabe ( ja, es gibt mehrere ).
Gutes Beispiel: CluNet.
Cluster hat in seinem Artikel die Gründe für die Entscheidungen, die er bei der Entwicklung des Smart-Home-Protokolls getroffen hat, ausführlich beschrieben. Das Beispiel ist sehr aufschlussreich und gut beschrieben. Ich empfehle, es selbst zu zerlegen.
Fazit
Bei der Suche nach einer Lösung für ein Problem müssen der Kontext und alle gegebenen Bedingungen berücksichtigt werden .
Selbst in einfachen Fällen stellen kleine Details des Kontexts die Lösung auf den Kopf, und die Fähigkeit , angewandte Probleme zu lösen, basiert weitgehend auf der Fähigkeit, die ursprünglichen Prämissen zu sehen und zu bewerten .
Sagt der Satz „das Rad nicht neu erfinden“ über die Unfähigkeit des Beraters, Probleme zu lösen? Wenn der Berater die Motorräder nach ein paar Minuten vor dem Zögern erwähnte, höchstwahrscheinlich ja.
Oder in der Verallgemeinerung des Kapitäns:
Denken Sie nach, bevor Sie sich entscheiden.
Denken Sie nach, bevor Sie sprechen.
Und im Allgemeinen - denken Sie.