Frankenstein in der Programmierung — was es ist, Ursachen und Prävention

Was ist Frankenstein in der Programmierung

Frankenstein (Frankenstein-Code, Frankenstein-Muster) ist ein Antipattern, bei dem ein Softwaresystem aus Teilen zusammengesetzt wird, die nicht für die Zusammenarbeit ausgelegt sind. Wie Frankensteins Monster kann solcher Code funktionieren, aber er ist hässlich, unberechenbar und gefährlich bei kleinsten Änderungen.

Der Begriff stammt aus der Literatur: In Mary Shelleys Roman „Frankenstein oder Der moderne Prometheus“ (1818) erschuf ein Wissenschaftler ein Lebewesen aus Fragmenten verschiedener toter Körper. In der Programmierung ist die Analogie genau — Entwickler nehmen Stücke verschiedener Frameworks, Bibliotheken, Sprachen und kleben sie „lebendig“ zusammen, um ein funktionierendes, aber monströses Ergebnis zu erhalten.

Der Unterschied zwischen Frankenstein und Spaghetti-Code liegt in Umfang und Natur. Spaghetti-Code ist eine verworrene Struktur innerhalb eines einzigen Technologie-Stacks. Frankenstein ist Eklektizismus auf Architekturebene: verschiedene Technologien, inkompatible Paradigmen, widersprüchliche Ansätze innerhalb desselben Systems.

Frankenstein vs Microservices

Microservice-Architektur erlaubt die Verwendung verschiedener Technologien für verschiedene Dienste, aber unter der Bedingung klarer Grenzen und standardisierter Interaktionsprotokolle. Frankenstein ist eine chaotische Mischung ohne Grenzen: REST und GraphQL im selben Controller, zwei ORMs im selben Modul, SQL und NoSQL für dieselbe Entität.

Warum das Frankenstein-Syndrom entsteht

Das Fehlen eines technischen Leiters oder Architekten ist die Hauptursache. Wenn es keine Person gibt, die für die architektonische Integrität verantwortlich ist, wählt jeder Entwickler Werkzeuge „für sich selbst“. Einer mag Spring, ein anderer Guice, ein Dritter verwendet ein benutzerdefiniertes DI. Das Ergebnis ist ein architektonischer Mischmasch.

Die Zusammenlegung von Projekten ist die zweithäufigste Ursache. Zwei Teams entwickelten ihre Module unabhängig voneinander mit unterschiedlichen Stacks. Wenn die Module zu einer Anwendung kombiniert werden müssen, werden sie einfach mit Adaptern und Middleware „verklebt“. Das Ergebnis ist Frankenstein.

Unternehmensübernahmen sind das dritte Szenario. Firma A kaufte Firma B und möchte deren Produkt in ihr eigenes integrieren. Statt Neuschreibung — Verklebung via APIs, gemeinsame Datenbanken und Workarounds. Nach einem Jahr wird das System zu einem Monster, das niemand versteht.

Der „Kreativität“-Faktor

Erfahrene Entwickler, die neue Technologien in der Produktion ausprobieren möchten, werden oft zur Quelle von Frankenstein. Anstatt Experimente auf ein isoliertes Modul zu beschränken, führen sie experimentellen Code in kritische Teile des Systems ein.

Beispiele für Frankenstein in echten Projekten

Ein klassisches Beispiel ist die Verwendung mehrerer ORMs in einer einzigen Anwendung. Einige Module verwenden Hibernate, einige MyBatis, und einige direkte JDBC-Abfragen. Transaktionen werden unkontrollierbar, der Cache inkonsistent, und ein neuer Entwickler weiß nicht, welchen Ansatz er für eine neue Funktion wählen soll.

Ein zweites Beispiel ist die Vermischung architektonischer Stile. In einem REST-API-Controller finden sich SOAP-Service-Aufrufe, direkte SQL-Abfragen, Dateisystemzugriff und HTML-Generierung. Eine solche Anwendung zu testen, zu erweitern oder zu dokumentieren ist unmöglich.

Ein drittes Beispiel ist ein Technologie-Stack, bei dem Python für das Backend, Node.js für einen Microservice, C# für einen Desktop-Client und Java für eine Android-App verwendet wird, während die gesamte Geschäftslogik ohne klare Aufgabentrennung zwischen ihnen verteilt ist.

// Frankenstein — gemischte Stile und Technologien
// Callbacks, Promises und async/await kombiniert

// Callbacks
db.query("SELECT * FROM users", function(err, rows) {
  if (err) handleError(err);
  // Promise innerhalb von Callback
  fetch("/api/data").then(function(data) {
    // async/await innerhalb von then
    (async () => {
      const result = await processData(data);
      sendResponse(result);
    })();
  });
});

// sauberer Code — einheitlicher async/await-Stil
async function getUserData(userId) {
  const user = await db.query("SELECT * FROM users WHERE id = ?", [userId]);
  const data = await fetch("/api/data/" + userId);
  return await processData(user, data);
}

Frankenstein auf Datenebene

Eine einzige Datenbank wird gleichzeitig als SQL-relational (mit Normalisierung) und als NoSQL-dokumentenorientiert (mit JSON-Spalten) genutzt. Einige Abfragen laufen über ORM, einige über gespeicherte Prozeduren, einige über direktes SQL aus dem Code. Das DB-Schema ist nicht dokumentiert, Migrationen kollidieren.

Folgen von Frankenstein-Code

Die Komplexität des Onboardings ist die erste Folge. Ein neuer Entwickler muss 5 Sprachen, 3 Frameworks, 2 Architekturstile kennen, um zu verstehen, wie das System funktioniert. Das Onboarding dehnt sich von Wochen auf Monate aus. Laut LinkedIn (2023) verlieren Projekte mit technologischem Eklektizismus neue Mitarbeiter 2-mal häufiger.

Die Unvorhersehbarkeit des Verhaltens ist die zweite Folge. Eine Änderung im Python-Microservice kann unerwartet das Java-Modul zerstören, weil sie eine gemeinsame Datenbank ohne klare Verträge nutzen. Das Debuggen solcher Probleme erfordert gleichzeitige Kenntnis aller Technologien im Stack.

Sicherheit ist die dritte Folge. Jede Technologie im Stack erfordert ihre eigene Sicherheitskonfiguration, ihre eigenen Patches, ihr eigenes Monitoring. Die Sicherheit auf einem akzeptablen Niveau für 5-6 heterogene Technologien zu halten, ist praktisch unmöglich. Eine davon wird zwangsläufig verwundbar sein.

Frankensteins technische Schulden

SonarQube kann technische Schulden messen, aber nicht „architektonische Schulden“ — die Inkompatibilität von Komponenten. Diese Schulden zeigen sich nicht in Linter-Warnungen, sondern in der Unmöglichkeit, eine neue Funktion hinzuzufügen, ohne drei verschiedene Module zu ändern, die in verschiedenen Technologien geschrieben wurden.

Wie man die Erschaffung eines Monsters vermeidet

Der erste und wichtigste Schritt ist die Ernennung eines Architekten oder Tech Leads, der für die Integrität des Technologie-Stacks verantwortlich ist. Diese Person hat ein Vetorecht bei der Einführung neuer Technologien ohne architektonische Prüfung. Keine Demokratie, sondern verantwortungsvolle Einzelentscheidung bei Schlüsseltechnologien.

Der zweite Schritt ist die Einführung des Architecture Decision Record (ADR)-Prozesses. Jede bedeutende architektonische Entscheidung (DB-Auswahl, Framework, Protokoll) wird als kurzer Text dokumentiert: Kontext, betrachtete Alternativen, getroffene Entscheidung, Konsequenzen. ADRs werden im Repository gespeichert und sind dem gesamten Team zugänglich.

Der dritte Schritt ist die Etablierung des Prinzips „eine Aufgabe — ein Werkzeug“. Für HTTP-Anfragen — ein Client. Für ORM — eine Bibliothek. Für Logging — ein Framework. Ausnahmen sind nur via ADR mit Begründung erlaubt. Wenn das Projekt bereits Axios hat — füge fetch nicht hinzu, wenn es SLF4J hat — schreibe nicht über System.out.

• Architekt mit Vetorecht bei neuen Technologien
• Architecture Decision Records für jede bedeutende Wahl
• Vereinheitlichter Stack für jede Aufgabe — ein HTTP-Client, ein ORM
• RFC für große Änderungen mit teamweiter Diskussion
• Technologie-Radar zur Verfolgung, was übernommen werden kann

Richtlinie für experimentelle Technologien

Experimente sind erlaubt, aber in einer isolierten Umgebung. Weisen Sie ein Modul oder einen Dienst zu, der mit einer neuen Technologie neu geschrieben werden kann, ohne den Rest des Systems zu beeinträchtigen. Wenn das Experiment erfolgreich ist — standardisieren Sie es via ADR. Wenn nicht — entfernen Sie es ohne Konsequenzen.

Wie man bestehenden Frankenstein refaktoriert

Bestandsaufnahme — der erste Schritt. Erstellen Sie eine vollständige Karte des Technologie-Stacks: welche Frameworks, Bibliotheken, Sprachen, Protokolle werden verwendet, in welchen Modulen und für welche Aufgaben. Sie werden das Ausmaß des Problems sehen: Werkzeugduplikate, konkurrierende Technologien, ungenutzte Abhängigkeiten.

Standardisierung — der zweite Schritt. Wählen Sie ein Werkzeug für jede Aufgabe. Zum Beispiel: nur Hibernate für ORM, nur SLF4J + Logback für Logging, nur REST für API. Dokumentieren Sie den Standard in ADR. Beginnen Sie mit dem Austausch in Modulen, wo Eklektizismus die meisten Probleme verursacht.

Parallel Run-Strategie — der dritte Schritt. Das alte und das neue Werkzeug arbeiten parallel, bis das neue seine Zuverlässigkeit bewiesen hat. Zum Beispiel arbeiten der alte HTTP-Client und der neue gleichzeitig, aber der neue bearbeitet nur einen Teil der Anfragen. Nach einer Stabilisierungsphase wird der alte entfernt.

// Frankenstein — drei HTTP-Ansätze in einem Projekt
// Modul A: OkHttp
OkHttpClient client = new OkHttpClient().newCall(request);

// Modul B: RestTemplate (Spring)
restTemplate.getForObject(url, String.class);

// Modul C: java.net.HttpURLConnection
HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection();

// einheitlicher Ansatz: RestTemplate für synchron, WebClient für reaktiv
@Autowired
private RestTemplate restTemplate;

public String callApi(String url) {
    return restTemplate.getForObject(url, String.class);
}

Die Rolle des technischen Leiters bei der Prävention

Ein technischer Leiter ist das wichtigste Werkzeug im Kampf gegen Frankenstein. Kein Manager, kein Architekt im Elfenbeinturm, sondern ein praktizierender Entwickler, der Code schreibt, PRs reviewt und architektonische Entscheidungen trifft. Ohne eine solche Person rutscht das Projekt unweigerlich in technologischen Eklektizismus ab.

RFC (Request for Comments) ist ein aus Open-Source-Communities übernommener Prozess. Vor der Einführung einer bedeutenden Technologie schreibt der Autor ein RFC: Problem, Lösungsvorschlag, Alternativen, Implementierungsplan. Das Team diskutiert, stimmt ab, akzeptiert oder lehnt ab. RFC schafft Transparenz und verhindert „stille“ architektonische Entscheidungen.

Das Technologie-Radar (ThoughtWorks Technology Radar) ist ein Kategorisierungswerkzeug: Adopt, Trial, Assess, Hold. Das Team überprüft regelmäßig das Radar und aktualisiert die Status. Dies hilft, „trendig“ von „nützlich“ zu unterscheiden und die Einführung unerprobter Technologien in kritischen Code zu vermeiden.

Das Konsistenzprinzip

Die wichtigste Eigenschaft der Architektur ist Konsistenz. Selbst ein nicht so gutes Werkzeug, das im gesamten Projekt verwendet wird, ist besser als das beste Werkzeug, das nur in einem Modul verwendet wird. Konsistenz reduziert die kognitive Belastung, vereinfacht das Onboarding und macht Code vorhersehbar.