Fahrrad in der Programmierung: Was es ist, Ursachen und wie man es vermeidet

Was ist ein Fahrrad in der Programmierung

Fahrrad ist ein Begriff aus der Entwickler-Community, der die Erstellung einer eigenen Implementierung einer bereits als Bibliothek, Framework oder Dienst verfügbaren Funktionalität bezeichnet. Im englischsprachigen Raum wird der Ausdruck reinventing the wheel — das Rad neu erfinden — verwendet.

Der Ursprung der Metapher hängt damit zusammen, dass das Rad eine der ältesten Erfindungen der Menschheit ist. Zu versuchen, es im 21. Jahrhundert neu zu erfinden, ist sinnlos. In der Programmierung ist die Analogie noch treffender: Fertige Bibliotheken sind „Räder“, die von Tausenden von Ingenieuren über Jahre optimiert wurden. Ein eigenes Rad von geringerer Qualität zu schaffen, ist eine Ressourcenverschwendung.

RedMonk berechnete in einem Analysebericht (2023), dass die durchschnittliche kommerzielle Anwendung etwa 500 externe Abhängigkeiten verwendet. Müssten Entwickler jede davon unabhängig schreiben, würden sich die Projektkosten verzehnfachen und die Markteinführungszeit um Jahre verlängern. Das Ökosystem der Paketmanager (npm, Maven, PyPI, NuGet) existiert genau, um das Neuerfinden des Rades zu vermeiden.

Anzeichen eines Fahrrads

Code, der ein Fahrrad ist, lässt sich an mehreren Merkmalen erkennen: Er löst ein Standardproblem auf nicht standardisierte Weise, hat keine Tests oder Dokumentation und behandelt keine Grenzfälle, die in fertigen Bibliotheken längst berücksichtigt sind. Oft wird solcher Code in Erwartung „einzigartiger Anforderungen“ des Projekts geschrieben, obwohl sich diese Anforderungen in Wirklichkeit nicht von typischen unterscheiden.

Unterschied zwischen Fahrrad und kundenspezifischer Lösung

Eine kundenspezifische Lösung ist gerechtfertigt, wenn eine fertige Bibliothek aufgrund architektonischer oder lizenzrechtlicher Einschränkungen nicht passt. Ein Fahrrad wird ohne objektive Gründe erstellt — aus dem Wunsch „herumzuspielen“, Misstrauen gegenüber fremdem Code oder Unkenntnis vorhandener Werkzeuge. Der Unterschied ist grundlegend: kundenspezifisch ist eine bewusste Entscheidung, ein Fahrrad ist ein Fehler.

Warum Entwickler das Rad neu erfinden

Der erste und häufigste Grund — Unkenntnis vorhandener Lösungen. Ein Junior-Entwickler weiß möglicherweise nicht, dass die Standardbibliothek eine integrierte Funktion zum Parsen von JSON hat. Stattdessen schreibt er manuell einen Parser. Dieses Problem betrifft besonders Anfänger, die gerade in das Sprach-Ökosystem eintreten.

Der zweite Grund ist die Illusion der Kontrolle. Erfahrene Entwickler sind manchmal überzeugt, dass sie „es besser schreiben können“ als die Autoren einer populären Bibliothek. Die Statistik sagt das Gegenteil: Die Wahrscheinlichkeit eines Fehlers in einer von Millionen Projekten genutzten Bibliothek ist deutlich geringer als in frisch geschriebenem Code. Laut Synopsys (2024) enthält Open-Source-Code durchschnittlich 0,1 Fehler pro tausend Zeilen, während Unternehmenscode 1–2 aufweist.

Der dritte Grund ist das Fehlen einer Wiederverwendungskultur. In Unternehmen, in denen es nicht üblich ist, vor Arbeitsbeginn vorhandene Lösungen zu recherchieren, erstellt jeder Entwickler „sein eigenes Fahrrad.“ Dies führt zur Code-Fragmentierung: In einem Projekt kann es drei verschiedene Implementierungen eines HTTP-Clients geben, die von verschiedenen Mitarbeitern geschrieben wurden.

Psychologische Aspekte

Der IKEA-Effekt ist ein psychologisches Phänomen, bei dem eine Person das, was sie selbst geschaffen hat, höher bewertet als objektiv bessere fertige Dinge. In der Programmierung äußert sich dies als Stolz auf das „eigene Fahrrad“ und mangelnde Bereitschaft, es durch eine fertige Bibliothek zu ersetzen, selbst wenn diese offensichtliche Vorteile bietet.

Folgen der Fahrraderstellung in einem Projekt

Die wirtschaftlichen Folgen sind am offensichtlichsten. Laut einer Schätzung von Stripe (2022) verbringen Entwickler bis zu 35% ihrer Arbeitszeit mit der Erstellung von Code, der bereits als fertige Lösung existiert. Für ein Team von 10 Personen entspricht das etwa 200.000 Dollar pro Jahr, die für das Neuerfinden des Rades ausgegeben werden.

Die technischen Folgen umfassen das Wachstum der Codebasis, eine verringerte Testabdeckung (Eigenentwicklungen werden in der Regel schlechter getestet) und eine Zunahme von Fehlern und Schwachstellen. Darüber hinaus ist jede Eigenentwicklung ein weiterer Ausfallpunkt, der überwacht und gewartet werden muss.

Google stellte in seiner Studie „Why Google Stores Billions of Lines of Code“ (2023) fest, dass selbst im größten Technologieunternehmen ein strenger Entscheidungsprozess für das Hinzufügen einer neuen Abhängigkeit oder das Schreiben einer eigenen Implementierung existiert. Die meisten internen Teams suchen zunächst nach einer fertigen Lösung im einheitlichen Code-Repository.

Auswirkungen auf das Team

Fahrräder schaffen Informationsasynchronität: Wenn ein Entwickler geht, bleibt seine Eigenentwicklung ohne Dokumentation und Support. Neue Teammitglieder müssen nicht standardisierten Code verstehen und verschwenden Zeit, die für produktive Arbeit genutzt werden könnte.

Beispiele für häufige Fahrräder im Code

Das häufigste Beispiel ist manuelles JSON- oder XML-Parsing, obwohl fast alle modernen Sprachen integrierte Werkzeuge haben. Entwickler schreiben rekursive Funktionen zum Durchlaufen von Objektbäumen, ohne zu wissen, dass JSON.parse() das Problem in einer Zeile löst.

Ein zweites Beispiel ist eine eigene Implementierung eines HTTP-Clients. Standardbibliotheken (fetch, axios, OkHttp, URLSession) unterstützen Caching, Wiederherstellung der Verbindung, Timeouts und Sicherheit. Ein eigener Client erfült in der Regel mindestens eine dieser Anforderungen nicht, was zu Fehlern in der Produktion führt.

Ein drittes Beispiel ist ein eigenes Protokollierungssystem anstelle von SLF4J, Winston oder Log4j. Ein Entwickler verbringt Wochen damit, das zu schreiben, was fertige Bibliotheken sofort mit Unterstützung für Rotation, Protokollierungsebenen, asynchrones Schreiben und Integration in Überwachungssysteme bieten.

# Fahrrad — manuelles CSV-Parsing
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# stattdessen Standardbibliothek verwenden
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Anti-Pattern: Eigenes ORM

Das Schreiben eines eigenen ORM (Object-Relational Mapping) ist wohl das teuerste Fahrrad. Fertige ORMs wie Hibernate, Entity Framework oder SQLAlchemy wurden über Jahre entwickelt und unterstützen Caching, Lazy Loading, Migrationen und Dutzende von DBMS. Ein eigenes ORM ist in der Regel auf eine Datenbank beschränkt und enthält kritische Fehler in der Verbindungsverwaltung.

Wann ein Fahrrad gerechtfertigt ist

Lernen ist die einzige Situation, in der ein Fahrrad nicht nur gerechtfertigt, sondern auch nützlich ist. Das Schreiben eines eigenen Parsers, HTTP-Servers oder ORM zu Bildungszwecken hilft zu verstehen, wie diese Werkzeuge im Inneren funktionieren. Es ist wichtig, ein Lernprojekt nicht mit Produktionscode zu verwechseln: Was für ein Pet-Projekt gut ist, ist in der kommerziellen Entwicklung inakzeptabel.

Einzigartige Anforderungen können tatsächlich eine eigene Implementierung erfordern. Wenn keine Bibliothek ein bestimmtes Protokoll, Datenformat oder eine bestimmte Hardware-Plattform unterstützt, ist die Erstellung einer kundenspezifischen Lösung gerechtfertigt. Aber vorher muss sichergestellt werden, dass die Aufgabe wirklich einzigartig und nicht nur schlecht recherchiert ist.

Lizenzbeschränkungen sind ein weiterer legitimer Grund. Einige Open-Source-Lizenzen (GPL, AGPL) können mit dem Geschäftsmodell eines Unternehmens nicht kompatibel sein. In solchen Fällen ist die Entwicklung einer eigenen Implementierung unter einer freizügigeren Lizenz gerechtfertigt.

Die Regel der drei Versuche

Es gibt eine praktische Regel: Bevor Sie Ihre eigene Implementierung schreiben, versuchen Sie, drei verschiedene fertige Lösungen zu finden und zu testen. Wenn keine passt, erstellen Sie Ihre eigene, dokumentieren Sie aber, warum die vorhandenen Optionen abgelehnt wurden. Dies schützt vor unbewusstem Neuerfinden des Rades.

Wie man Fahrräder vermeidet

Der erste Schritt ist, sich anzugewöhnen, vor Beginn jeder Standardaufgabe nach fertigen Lösungen zu suchen. Nutzen Sie die Suche in Paketmanagern, GitHub, Stack Overflow. Die für die Recherche aufgewendete Zeit amortisiert sich vielfach, indem Sie vermeiden, eigenen Code zu schreiben.

Der zweite Schritt ist die Einführung von Code-Reviews mit Fokus auf die Erkennung von Fahrrädern. Stellen Sie beim Review die Frage: „Warum verwenden wir keine fertige Bibliothek für diese Aufgabe?“ Enthält die Antwort keine objektiven Gründe, ist es ein Fahrrad. In großen Unternehmen (Google, Meta) enthält das Code-Review einen obligatorischen Punkt zur Überprüfung auf das Neuerfinden des Rades.

Der dritte Schritt ist die Erstellung eines internen Wissensregisters. Dokumentieren Sie, welche Bibliotheken und Werkzeuge im Projekt verwendet werden und welche Aufgaben sie lösen. Neue Entwickler sollten Zugriff auf diese Informationen haben, um nicht aus Unkenntnis Fahrräder zu erstellen. Führen Sie eine Liste der Architekturentscheidungen (ADR) mit Begründung für jede Wahl.

• Recherchieren Sie den Paketmanager vor Beginn einer neuen Aufgabe
• Überprüfen Sie die Standardbibliothek der Sprache — sie deckt 80% der typischen Aufgaben ab
• Nutzen Sie Code-Reviews zur Erkennung von Fahrrädern
• Dokumentieren Sie Entscheidungen zur Bibliotheksauswahl
• Aktualisieren Sie Ihr Wissen über das Ökosystem auf Konferenzen und in Blogs

Not-Invented-Here-Syndrom

Das NIH-Syndrom (Not Invented Here) ist eine organisatorische Voreingenommenheit gegenüber der Nutzung externer Lösungen. Unternehmen mit NIH-Syndrom ziehen es vor, alles intern zu entwickeln und lehnen Open-Source-Bibliotheken ab, selbst wenn sie die eigenen Entwicklungen übertreffen. Dieses Syndrom ist die unternehmerische Version des Fahrrads.

Ein klassisches Beispiel ist Netscape in den späten 1990er Jahren, als das Unternehmen Jahre damit verbrachte, den Browser von Grund auf neu zu schreiben, anstatt die vorhandene Codebasis weiterzuentwickeln. Das Ergebnis — Marktanteilsverlust und Übernahme durch AOL. Im Gegensatz dazu wurde Android auf dem Linux-Kernel aufgebaut und verwendet Tausende von Open-Source-Komponenten — dies ermöglichte eine rekordverdächtige Markteinführung.

Eine Studie der Harvard Business Review (2023) zeigte, dass Unternehmen mit geringem NIH-Syndrom Produkte 40% schneller auf den Markt bringen und 30% weniger für die Entwicklung ausgeben. Eine Kultur der Code-Wiederverwendung ist ein Wettbewerbsvorteil in der modernen Softwareentwicklung.

// Fahrrad — eigene Sortierimplementierung
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// eingebaute Sortierung — Standardlösung
arr.sort((a, b) => a - b);