Refactoring von Swift-Code: Wann es nötig ist und wie man es richtig macht

Ihr Code funktioniert, aber das ist kein Grund, ihn nicht anzufassen

Sie haben eine App geschrieben, sie läuft, die Kunden sind zufrieden, die Builds stürzen nicht ab. Man könnte meinen, durchatmen und sich neuen Features widmen. Aber im Inneren der Codebasis lauert ein Frankenstein-Monster: 300-Zeilen-Methoden, Copy-Paste, verworrene Logik und magische Zahlen, die über das gesamte Projekt verstreut sind. Wenn Sie sich auch nur einmal dabei ertappt haben, zu denken „Diese Klasse sollte ich besser nicht anfassen, sonst geht alles kaputt“ – dann ist Refactoring von Swift-Code für Sie keine bloße Empfehlung, sondern eine Überlebensnotwendigkeit.

In diesem Artikel analysieren wir, wann es sich wirklich lohnt, ein Refactoring anzugehen, und wann es besser ist, den Code in Ruhe zu lassen. Ich zeige konkrete Beispiele in Swift, die Sie noch heute anwenden können. Und ja, kein Blabla – nur Praxis.

Was Refactoring ist und was nicht

Beginnen wir mit den Grundlagen. Refactoring von Swift-Code ist der Prozess der Änderung der internen Struktur eines Programms, ohne dessen externes Verhalten zu verändern. Sie fügen keine neuen Funktionen hinzu, Sie beheben keine Bugs (auch wenn Sie oft welche auf dem Weg finden). Sie machen den Code einfach sauberer, verständlicher und wartbarer.

Wichtig zu verstehen: Refactoring ≠ Neuschreiben von Grund auf. Wenn Sie das gesamte Projekt wegwerfen und mit SwiftUI und der TCA-Architektur neu beginnen möchten – das ist kein Refactoring, das ist Neuschreiben. Und Neuschreiben endet, wie die Erfahrung zeigt, in 80 % der Fälle im Desaster.

Wann man Swift-Code refactoren sollte: Drei sichere Signale

1. Die Regel der Drei (Rule of Three)

Wenn Sie dasselbe Codefragment zum dritten Mal kopieren – das ist ein Signal. Nicht beim zweiten, sondern genau beim dritten Mal. Beim ersten Mal ist es okay, Sie haben die Aufgabe gelöst. Beim zweiten Mal ist es schon fragwürdig, aber man kann es auf Eile schieben. Beim dritten Mal – Schluss, schreiben Sie eine verallgemeinerte Lösung.

// Schlecht: Copy-Pastefunc formatUserName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

func formatProductName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

// Gut: Einheitliche Methodefunc formatDisplayName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

2. Der „Geruch“ langer Methoden

Wenn eine Methode nicht auf einen Telefonbildschirm passt – das ist ein Problem. In der Swift-Community orientiert man sich an 15-20 Zeilen pro Methode. Natürlich gibt es Ausnahmen (komplexe Berechnungen), aber in 95 % der Fälle ist eine lange Methode ein Zeichen dafür, dass sie zu viel tut.

3. Testen wird zur Hölle

Wenn Sie zum Testen einer Funktion 5 Services mocken, eine Datenbank einrichten und eine Datei von der Festplatte lesen müssen – das ist eine rote Flagge. Refactoring von Swift-Code sollte Ihre Codebasis testbarer machen. Wenn das Schreiben von Tests jetzt weh tut – dann schreit die Architektur nach Veränderung.

Praktische Beispiele für Swift-Refactoring

Schauen wir uns reale Situationen an, mit denen jeder iOS-Entwickler konfrontiert wird.

Beispiel 1: Magische Zahlen loswerden

Magische Zahlen sind numerische Literale, deren Bedeutung ohne Kontext unklar ist. Sie machen den Code zerbrechlich und unlesbar.

// Vor dem Refactoringfunc calculateDiscount(price: Double) -> Double {    if price > 1000 {        return price * 0.15    } else if price > 500 {        return price * 0.1    } else {        return price * 0.05    }}

// Nach dem Refactoringprivate struct DiscountConstants {    static let premiumThreshold: Double = 1000    static let standardThreshold: Double = 500    static let premiumRate: Double = 0.15    static let standardRate: Double = 0.10    static let basicRate: Double = 0.05}

func calculateDiscount(price: Double) -> Double {    switch price {    case _ where price > DiscountConstants.premiumThreshold:        return price * DiscountConstants.premiumRate    case _ where price > DiscountConstants.standardThreshold:        return price * DiscountConstants.standardRate    default:        return price * DiscountConstants.basicRate    }}