Code-Review in Kotlin: Worauf man achten sollte und wie man Feedback gibt
Code-Review ist eines der effektivsten Werkzeuge, um Code-Qualität zu erhalten, Wissen im Team zu teilen und Fehler zu vermeiden. Es reicht jedoch nicht aus, einen Pull-Request nur "überflogen" zu haben. In der Sprache Kotlin mit ihrem reichhaltigen Typsystem, Coroutinen und funktionalen Fähigkeiten ist es wichtig, auf bestimmte Punkte zu achten. In diesem Artikel schlüsseln wir auf, worauf man bei der Überprüfung von Kotlin-Code genau achten sollte und wie man Kommentare so formuliert, dass sie nützlich und nicht verletzend sind.
1. Grundlegende Prinzipien konstruktiven Feedbacks
Bevor wir zu den technischen Details übergehen, erinnern wir uns an ein paar Regeln, die Code-Review für alle Beteiligten nützlich machen.
Konzentrieren Sie sich auf den Code, nicht auf den Autor
Sagen Sie statt "Sie haben schlechten Code geschrieben" lieber "Diese Methode kann mit let vereinfacht werden." Spezifität und ein neutraler Ton reduzieren Spannungen.
Kategorisierung
Markieren Sie Kommentare als:
- Blocking — muss behoben werden (Logikfehler, Ressourcenleck).
- Nitpick — kleine Spitzfindigkeiten (Stil, Formatierung).
- Question — Nachfrage (Absicht ist unklar).
Erklären Sie das "Warum"
Es reicht nicht zu sagen "verwenden Sie filterNotNull()." Fügen Sie hinzu: "Dadurch wird eine unnötige Schleife eliminiert und der Code erklärt sich selbst." So lernt der Autor, nicht nur zu korrigieren.
2. Null-Sicherheit und Typen: Kotlins wichtigste Verbündete
Kotlin wurde entwickelt, um NullPointerException zur Kompilierzeit zu vermeiden. Überprüfen Sie, dass dieser Schutz nicht umgangen wird.
Vermeiden Sie unnötiges !! (Not-Null-Assertion)
Der !!-Operator ist ein Hilferuf. Seine Verwendung sollte die Ausnahme sein, nicht die Regel.
// Schlecht: NPE-Risikofun process(user: User?) { val name = user!!.name}
// Gut: sicherer Aufruffun process(user: User?) { val name = user?.name ?: "Gast"}Worauf Sie achten sollten: Wenn Sie !! sehen, fragen Sie den Autor, ob es durch ?.let, ?: (Elvis) oder requireNotNull() ersetzt werden kann.
Korrekte Verwendung von nullable Typen
Nicht alle Parameter müssen nullable sein. Wenn eine Funktion immer einen Wert erwartet, deklarieren Sie den Typ ohne Fragezeichen.
// Diskutabel: null bedeutet nichtsFunktion log(message: String?) { println(message ?: "null")}
// Besser: explizite AnforderungFunktion log(message: String) { println(message)}3. Coroutinen und Threads: Async ohne Schmerz
Kotlin Coroutinen sind ein mächtiges Werkzeug, aber man kann sie leicht falsch verwenden. Achten Sie bei der Überprüfung auf folgende Punkte.
Korrekter Dispatcher für Aufgaben
Führen Sie keine langen Operationen (Netzwerk, Festplatte) auf Dispatchers.Main aus.
// Schlecht: blockiert die UIGlobalScope.launch(Dispatchers.Main) { val data = fetchFromNetwork() // hängt auf}
// Gut: KontextwechselviewModelScope.launch { val data = withContext(Dispatchers.IO) { fetchFromNetwork() } updateUI(data)}Coroutinen-Lecks und strukturierte Nebenläufigkeit
Verwenden Sie viewModelScope, lifecycleScope oder coroutineScope anstelle von GlobalScope. Letzteres lebt so lange wie die Anwendung und führt leicht zu Lecks.
// Gefährlich: LeckGlobalScope.launch { /* ... */ }
// Sicher: an den Lebenszyklus gebundenlifecycleScope.launch { /* ... */ }4. Sammlungen und funktionaler Stil: Prägnanz und Lesbarkeit
Kotlin bietet eine umfangreiche Bibliothek für die Arbeit mit Sammlungen. Verwenden Sie diese anstelle von expliziten Schleifen.
Verkettungen statt Mutationen
Vermeiden Sie manuelles Hinzufügen zu einer Liste, wenn Sie das Ergebnis mit einer Kette von Operationen sammeln können.