Wie heißt das Gegenmuster zu „das Rad neu erfinden“? [geschlossen]

Das Antimuster " Das Rad neu erfinden " ist weit verbreitet - anstatt eine fertige Lösung zu verwenden, schreiben Sie Ihre eigenen von Grund auf neu. Die Codebasis wächst unnötig, es gibt leicht unterschiedliche Schnittstellen, die das Gleiche tun, aber leicht unterschiedlich sind. Es wird Zeit verschwendet, um leicht verfügbare Funktionen zu schreiben (und zu debuggen!). Das wissen wir alle.

Aber es gibt etwas am anderen Ende des Spektrums. Wenn Sie keine eigene Funktion mit zwei Codezeilen schreiben, sondern ein Framework / API / eine Bibliothek importieren, instanziieren, konfigurieren, den Kontext in einen vom Framework als akzeptabel eingestuften Datentyp konvertieren und dann diese eine einzige Funktion aufrufen, die genau das tut, was Sie benötigen, zwei Zeilen Geschäftslogik unter einem Gigabyte Abstraktionsebenen. Und dann müssen Sie die Bibliothek auf dem neuesten Stand halten, Build-Abhängigkeiten verwalten, die Lizenzen synchron halten, und Ihr Code für die Instanziierung ist zehnmal länger und komplexer als wenn Sie nur das Rad neu erfunden hätten.

Die Gründe können vielfältig sein: Das Management ist strikt gegen eine "Neuerfindung des Rades", unabhängig von den Kosten, jemanden, der seine bevorzugte Technologie trotz geringfügiger Überschneidungen mit den Anforderungen vorantreibt, eine schwindende Rolle eines ehemals wichtigen Moduls des Systems oder die Erwartung einer Erweiterung und eines umfassenderen Angebots Verwendung des Frameworks, das einfach nie ankommt, oder Missverständnis des "Gewichts", das ein paar Anweisungen zum Importieren / Einschließen / Laden "hinter den Kulissen" mit sich bringen.

Gibt es einen gebräuchlichen Namen für diese Art von Antimuster?

_{(Ich versuche nicht, eine Diskussion zu beginnen, wenn dies richtig oder falsch ist oder wenn es sich um ein echtes Gegenmuster oder um eine auf Meinungen basierende Frage handelt. Dies ist eine einfache, unkomplizierte und objektive Nomenklaturfrage.)}

Bearbeiten: Das vorgeschlagene "Duplikat" befasst sich mit der Überarbeitung des eigenen Codes, um ihn "für alles bereit" zu machen, ganz abgesehen von externen Systemen. Dies mag in bestimmten Fällen darauf zurückzuführen sein, ist aber im Allgemeinen auf "Abneigung gegen die Neuerfindung des Rads" zurückzuführen - die Wiederverwendung von Codes um jeden Preis; Wenn es eine "fertige" Lösung für unser Problem gibt, werden wir sie verwenden, egal wie schlecht sie passt und zu welchen Kosten sie anfällt. Die Erstellung neuer Abhängigkeiten wird dogmatisch gegenüber der Codeduplizierung favorisiert, wobei die Kosten für die Integration und Wartung dieser Abhängigkeiten im Vergleich zu den Kosten für die Erstellung und Wartung des neuen Codes völlig unberücksichtigt bleiben.

Nein. Es gibt keinen häufig verwendeten Anti-Pattern-Namen, der das beschreibt, was Sie beschreiben.

Goldener Hammer

Der goldene Hammer ist ein Werkzeug, das nur gewählt wird, weil es schick ist. Es ist weder wirtschaftlich noch effizient bei der Ausführung der beabsichtigten Aufgabe.

Quelle: xkcd 801

(Trotz der Abwärtsstimmen stehe ich zu dieser Antwort. Es ist vielleicht nicht genau das Gegenteil einer semantischen Neuerfindung des Rads, aber es passt zu jedem Beispiel, das in der Frage erwähnt wird.)

Robert Martin verwendet den Begriff " Framework Bound ", um auf die offensichtlichste negative Konsequenz dieses Anti-Patterns hinzuweisen. Da es meines Erachtens keinen gebräuchlichen Namen für das Muster selbst gibt, könnte ein Hinweis auf diese Konsequenz für die meisten Zwecke ausreichen.

Diese Wikipedia-Seite über " Hier erfunden " beschreibt eine etwas andere Situation, aber mit sehr ähnlichen Endergebnissen. Beschreibt die Abneigung eines Teams, eigenen Code zu erstellen, wenn dort entsprechende Funktionen verfügbar sind.

Ich würde behaupten, dass der Name ein bisschen irreführend ist. Macht Sinn, wenn es mit dem Gegenteil in Zusammenhang gebracht wird. Nicht erfunden. Hier ist IMHO so ziemlich ein Synonym für das Erfinden des Rades.

Ich habe " Buy Versus Build " und " Invented Here " als Anti-Pattern-Namen gehört, um zu verhindern, dass Dinge intern entwickelt werden, auch wenn dies möglicherweise sinnvoll ist. (Und obwohl der Ausdruck "Kaufen gegen Bauen" eine Wahl zwischen realisierbaren Alternativen anzeigen soll, finde ich, dass er normalerweise erwähnt wird, wenn jemand glaubt, dass "Kaufen" die richtige Wahl ist.)

Verwenden Sie keine Kanone, um eine Mücke zu töten

Konfuzius

AKA Overkill

Aufblähen ist ein weit gefasster Begriff, der jedoch das umfassen kann, was Sie beschreiben. Unsere Software wird aufgrund all der zusätzlichen Transformationen und Abstraktionen übermäßig komplex (aufgebläht), und sowohl die Komplexität als auch die Abhängigkeiten selbst tragen zu einer geringeren Leistung / geringeren Effizienz und einem höheren Ressourcenverbrauch (Festplatte, Bandbreite) bei.

Wenn wir möchten, könnten wir mit einem Begriff wie aufgeblähte Abhängigkeiten klarstellen .

Ich denke, einen Vorschlaghammer zu benutzen, um eine Nuss zu knacken, ist ziemlich nah. Es ist möglich, aber es erfordert eine übermäßige Menge an Arbeit, um eine Nuss auf diese Weise zu knacken, ohne dass irgendwelche der zahlreichen möglichen unerwünschten Nebenwirkungen auftreten. (Und es gibt eine ganze Tüte Nüsse zu knacken ...)

Der Ausdruck hat auch den Vorteil, dass es sich nicht um Fachsprache handelt. Daher kann er sehr hilfreich sein, um jemandem, der keine hat, einen Hinweis zu geben.

Übrigens gibt es eine Unterscheidung mit Abhängigkeitshölle zu ziehen . Wenn jemand bereits alle Komplexitäten in eine Kapselung eingebunden hat, die einfache, übersichtliche und benutzerfreundliche Schnittstellen erstellt, und vorausgesetzt, der Aufwand für CPU-Zyklen oder die Speichernutzung ist nicht übermäßig hoch, und vorausgesetzt, eine zukünftige Änderung des gekapselten Codes ist unwahrscheinlich benötigt wird, dann ist ein verbleibendes Argument gegen dessen Verwendung die Abhängigkeitshölle, die es verursachen könnte.

Ich glaube nicht, dass es ein genaues Analogon gibt, aber ich würde sagen, dass Überdesign oder Überentwicklung am nächsten kommen.

Zumindest würde ich behaupten, dass dies wirklich geschah, als ich auf etwas Ähnliches gestoßen bin, wie Sie es beschreiben.

Eine Bibliothek zu verwenden, anstatt eigenen Code zu schreiben, um dieselbe Funktionalität zu implementieren, ist so gut wie nie schädlich.

Selbst in Ihrem hypothetischen Beispiel ist es möglicherweise nicht erforderlich, eine Bibliothek zum Ersetzen von "zwei Codezeilen" zu verwenden, aber es ist unwahrscheinlich, dass Sie viel Kummer bekommen - wenn es sich wirklich um eine Bibliothek handelt, die dasselbe wie Ihre beiden Codezeilen tun soll .

Eine Bibliothek, um eine einfache Sache zu tun, wird auch einfach sein. Es ist unwahrscheinlich, dass Sie die Kopfschmerzen bekommen, die Ihre Frage mit sich bringt.

Wenn Sie eine komplizierte Bibliothek verwenden, um etwas Einfaches zu tun, müssen Sie wahrscheinlich mehr tun, als die erforderliche Funktionalität zu implementieren.

B. Funktionen einbauen, die nicht benötigt werden, sich auf eine Zukunft vorbereiten, die niemals kommen wird usw.

Das Problem hier ist nicht wirklich Versagen , das Rad neu zu erfinden , per se .

Wenn Sie das Rad nicht neu erfunden haben, wird höchstwahrscheinlich ein vorhandener Radsatz eines Herstellers oder eines Drittanbieters verwendet.

Wenn es sich um ein Anti-Pattern handelt, wird es normalerweise als Vendor Lock-In bezeichnet.

Berufssicherheit?
Sie erwähnen die ganze Anstrengung, die Dinge synchron zu halten usw. Einige Leute würden lieber den Code anderer Leute verwalten, als ihren eigenen Code zu schreiben. Vor allem Manager.