Refactoring von Java-Code: Wann und wie man nicht in die Falle tappt

Refactoring von Java-Code: Die Kunst, aus einem "Chaos" eine Leckerei zu machen

Haben Sie jemals Ihr altes Java-Projekt geöffnet und das Gefühl gehabt, gleich losweinen zu müssen? Klassen so groß wie "Krieg und Frieden", Methoden mit fünf Verschachtelungsebenen und Variablen mit Namen wie a1, temp2 und resultFinalReallyFinal. Kommt Ihnen das bekannt vor? Willkommen in der Welt des "Code mit Geruch" (Code Smell).

Aber beeilen Sie sich nicht, alles zu löschen und neu zu schreiben. Es gibt einen eleganteren Weg – das Refactoring von Java-Code. Es geht nicht darum, "alles neu zu schreiben", sondern darum, den Code sauberer, verständlicher und sicherer für Änderungen zu machen, ohne sein Verhalten zu beeinträchtigen. In diesem Artikel werden wir uns ansehen, wann Sie mit dem Refactoring beginnen sollten und wann es besser ist, alles so zu lassen, wie es ist, und anhand konkreter Beispiele zeigen, wie es richtig gemacht wird.

Wann ist ein Refactoring von Java-Code notwendig? Anzeichen für "schlechten Code"

Refactoring ist kein Hobby und keine Freitagabend-Unterhaltung. Es ist eine Investition in die Zukunft des Projekts. Aber wie erkennt man, dass es Zeit zum Handeln ist? Hier sind einige sichere Anzeichen:

• Monster-Methode (Long Method). Wenn eine Methode mehr als 20–30 Zeilen umfasst und Sie nicht verstehen, was sie tut, ohne auf- und abzuscrollen – das ist ein Alarmzeichen.
• Gott-Klasse (God Object). Eine Klasse weiß alles und macht alles: Sie arbeitet mit der Datenbank, zeichnet die UI und schreibt Logs. Eine solche Klasse verstößt gegen das Prinzip der einzigen Verantwortung (SRP).
• Code-Duplizierung (Duplicated Code). Haben Sie denselben Codeblock an drei verschiedenen Stellen kopiert? Wenn Sie die Logik ändern müssen, werden Sie garantiert vergessen, mindestens eine davon zu korrigieren.
• Komplexe bedingte Konstrukte (Switch/if-else-Manier). Eine Verzweigung mit 10+ Bedingungen, die mit jeder neuen Anforderung wächst – ein klarer Kandidat für die Ersetzung durch Polymorphie.
• Geruch der "Faulen Klasse" (Lazy Class). Eine Klasse, die zu wenig tut, um ihre Existenz zu rechtfertigen. Sie entsteht normalerweise nach einem fehlgeschlagenen Refactoring oder als "Vorsorge".

Wenn Sie Ihren Code in mindestens einem Punkt wiedererkennen – großartig! Dann gibt es Raum für Verbesserungen. Wenn in allen – keine Panik, wir werden alles reparieren.

Wann man KEIN Refactoring von Java-Code durchführen sollte

Ja, es gibt Situationen, in denen es besser ist, die Hände von der IDE zu lassen:

• Der Code funktioniert und wird nicht angefasst. Wenn das Projekt morgen abgegeben wird und Sie heute beschließen, "es zu verschönern" – hören Sie auf. Refactoring ohne Tests ist russisches Roulette.
• Es gibt keine automatischen Tests. Sie können nicht beweisen, dass sich der Code nach den Änderungen gleich verhält. Ohne Tests wird Refactoring zu "blindem Refactoring".
• Eine vollständige Überarbeitung ist geplant. Wenn Sie in einem Monat auf Microservices umsteigen, müssen Sie den Monolithen nicht aufpolieren. Konzentrieren Sie sich auf das, was jetzt wichtig ist.

Praktische Beispiele für das Refactoring von Java-Code

1. Long Method loswerden: Methode auslagern

Stellen Sie sich vor, Sie haben eine Methode, die einen Rabatt berechnet und gleichzeitig prüft, ob der Kunde VIP ist:

public double calculatePrice(double basePrice, String clientType) {    double discount = 0.0;    if (clientType.equals("VIP")) {        discount = 0.2;        // Logging des VIP-Kunden        System.out.println("VIP client detected!");    } else if (clientType.equals("REGULAR")) {        discount = 0.1;    } else {        discount = 0.05;    }    // noch 20 Zeilen Code mit Prüfungen...    return basePrice * (1 - discount);}

Dies ist ein klassisches "Taschenmesser-Methode". Wir lagern die Logik der Rabattberechnung in eine separate private Methode aus:

public double calculatePrice(double basePrice, String clientType) {    double discount = getDiscountForClientType(clientType);    logClientIfVip(clientType);    return basePrice * (1 - discount);}

private