Code Review auf Swift: 10 Dinge, die ich zuerst überprüfe

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Warum Code Review in Swift nicht nur Kritik ist

Stellen Sie sich vor: Sie öffnen den Pull-Request eines Kollegen, sehen 500 Zeilen Swift-Code und wissen, dass in 20 Minuten das Daily beginnt. Kommt Ihnen das bekannt vor? Code Review (oder Code-Review) ist kein Wettbewerb „Wer findet mehr Tippfehler?“. Es ist Ihre Chance, Bugs in der Produktion zu verhindern, die Architektur zu verbessern und Wissen im Team zu teilen.

In diesem Artikel habe ich eine Code-Review-Checkliste für Swift zusammengestellt, die ich selbst verwende. Kein überflüssiges Gerede – nur konkrete Prüfungen, Codebeispiele und Erklärungen, warum sie wichtig sind. Selbst wenn Sie in Python schreiben, aber einen Blick in die iOS-Entwicklung werfen, wird das Material nützlich sein.

\n\n

1. Speichersicherheit und optionale Typen

Swift ist stolz auf seine Speichersicherheit, aber das bedeutet nicht, dass man sich entspannen kann. Das häufigste Problem ist Force Unwrapping. Jedes Ausrufezeichen ist ein potenzieller Absturz.

\n\n

Was zu prüfen ist:

Force Unwrap (!) – nur in Tests zulässig oder wenn Sie sich zu 100% sicher sind. Im Produktionscode – eine rote Flagge.
IUO (Implicitly Unwrapped Optionals) – verwenden Sie sie nur für IBOutlet oder Eigenschaften, die nach init, aber vor der ersten Nutzung initialisiert werden.
Retain Cycles – überprüfen Sie Closures auf [weak self] oder [unowned self].

\n\n

// Schlecht: Force Unwrap ohne Prüfung\nlet url = URL(string: "https://pythonlib.ru")! // Absturz, wenn der String ungültig ist\n\n// Gut: guard let\nguard let url = URL(string: "https://pythonlib.ru") else {\n    print("Ungültige URL")\n    return\n}\n\n// Prüfung auf Retain Cycle in Closure\nclass NetworkManager {\n    var completionHandler: (() -> Void)?\n    \n    func fetchData() {\n        completionHandler = { [weak self] in\n            guard let self = self else { return }\n            self.updateUI() // self ist jetzt eine schwache Referenz\n        }\n    }\n    \n    func updateUI() { /* ... */ }\n}\n

\n\n

Tipp fürs Code Review: Wenn Sie ! sehen, fragen Sie: „Warum gibt es hier kein guard oder if let?“. Das verhindert viele Abstürze.

\n\n

2. Fehlerbehandlung: Ausnahmen nicht verschlucken

Swift bietet einen leistungsstarken Mechanismus do-catch, aber Entwickler ignorieren ihn oft. Ein typisches Antipattern ist try! oder ein leerer catch.

\n\n

Was zu prüfen ist:

try! – fast immer schlecht. Nur, wenn Sie einen Test schreiben.
Leerer catch {} – Sie verlieren einfach die Fehlerinformationen. Mindestens protokollieren Sie ihn.
Fehlerweitergabe nach oben (throws) – die Funktion sollte den Fehler entweder behandeln oder explizit weiterleiten.

\n\n

// Schlecht: Fehler verschlucken\ndo {\n    let data = try fetchData()\n} catch {\n    // Nichts tun – Fehler verloren\n}\n\n// Gut: Protokollieren und dem Benutzer anzeigen\ndo {\n    let data = try fetchData()\n    updateUI(with: data)\n} catch let error as NetworkError {\n    showAlert(message: error.localizedDescription)\n} catch {\n    print("Unbekannter Fehler: \\(error.localizedDescription)")\n    showGenericError()\n}\n

\n\n

Überprüfen Sie im Code Review für Swift immer, dass Error nicht einfach ignoriert wird. Der Benutzer sollte verstehen, was schiefgelaufen ist.

\n\n

3. Architektur: MVC, MVVM oder VIPER?

Egal, welches Muster Sie gewählt haben – wichtig ist, dass der Code ihm folgt. Im Code Review sehen Sie, ob der ViewController zu einem „God Object“ (einer Klasse, die alles macht) geworden ist.

\n\n