Code-Review in Swift: Was zu prüfen ist und wie man Feedback gibt

Code Review in Swift: Was prüfen und wie man Feedback gibt

Code Review ist nicht nur ein formelles Verfahren, sondern ein leistungsstarkes Werkzeug zur Verbesserung der Codequalität und des professionellen Wachstums des Teams. Für iOS/macOS-Entwickler in Swift hilft ein gut durchgeführtes Review, Bugs zu vermeiden, die Architektur zu verbessern und einen einheitlichen Codestil beizubehalten. In diesem Artikel besprechen wir, worauf man bei einem Code Review von Swift-Projekten achten sollte und wie man Feedback gibt, das nützlich ist und nicht demotiviert.

1. Architektur und Trennung der Verantwortlichkeiten

Das Erste, was bei einem Review zu bewerten ist, ist, wie gut der Code der gewählten Architektur (MVC, MVVM, VIPER, SwiftUI + Combine) entspricht. Eine schlechte Architektur führt zu „God-Objekten“ und erschwert die Wartbarkeit.

Was prüfen:

• Vermischt der ViewController Geschäftslogik und UI-Code?
• Ist die Netzwerklogik in separate Dienste (NetworkService) ausgelagert?
• Werden Protokolle zur Abstraktion von Abhängigkeiten verwendet?
• Hat eine einzelne Klasse zu viele Verantwortlichkeiten?

// ❌ Schlecht: ViewController kennt URLSession und JSON-Parsingclass UserViewController: UIViewController {    func fetchUser() {        URLSession.shared.dataTask(with: URL(string: "https://api.example.com/user")!) { data, _, _ in            let user = try? JSONDecoder().decode(User.self, from: data!)            DispatchQueue.main.async {                self.updateUI(with: user)            }        }.resume()    }}

// ✅ Gut: Logik in einen Service ausgelagertprotocol UserServiceProtocol {    func fetchUser(completion: @escaping (Result<User, Error>) -> Void)}

class UserViewModel {    private let userService: UserServiceProtocol        init(userService: UserServiceProtocol) {        self.userService = userService    }        func loadUser() {        userService.fetchUser { [weak self] result in            // Ergebnis verarbeiten        }    }}

Tipp für Feedback: Schreiben Sie statt „Diese Klasse ist zu groß“: „Ich sehe, dass UserViewController sowohl für Netzwerkanfragen als auch für das UI verantwortlich ist. Vielleicht könnten wir die Anfrage in einen separaten Service auslagern, wie wir es im Retro besprochen haben? Das würde das Testen vereinfachen.“

2. Speichersicherheit und Lebenszyklusverwaltung

Swift ist eine Sprache mit automatischer Referenzzählung (ARC), aber das entbindet den Entwickler nicht von der Sorge um starke Referenzzyklen. Fehler in diesem Bereich sind eine häufige Ursache für Speicherlecks in iOS-Apps.

Was prüfen:

• Wird [weak self] oder [unowned self] in Closures verwendet, insbesondere bei der Arbeit mit async/await und Combine?
• Wird eine zirkuläre Referenz zwischen dem Delegaten und dem Besitzer erstellt?
• Werden Ressourcen (Beobachter, Timer) korrekt freigegeben?

// ❌ Potenzielles Leck: Starke Referenz auf self in der Closureclass LocationManager {    var onLocationUpdate: ((CLLocation) -> Void)?        func startUpdating() {        someAsyncAPI { location in            self.onLocationUpdate?(location) // self wird stark erfasst        }    }}

// ✅ Behoben mit [weak self]class LocationManager {    var onLocationUpdate: ((CLLocation) -> Void)?        func startUpdating() {        someAsyncAPI { [weak self] location in            guard let self = self else { return }            self.onLocationUpdate?(location)        }    }}

Tipp für Feedback: Weisen Sie nicht nur auf das Problem hin, sondern auch auf die Konsequenzen: „Hier könnte ein Speicherleck entstehen, wenn der LocationManager länger lebt als nötig. Lass uns [weak self] hinzufügen, um den Zyklus zu durchbrechen.“

3. Fehlerbehandlung und Optionalität

Swift ist eine streng typisierte Sprache mit einem leistungsstarken Optional-System. Eine schlechte Behandlung optionaler Werte ist eine der häufigsten Fehlerquellen.