Code-Review in Kotlin: Was prüfen und wie man Feedback an Anfänger gibt

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

Code-Review (Code-Überprüfung) ist nicht nur eine Formalität, sondern ein mächtiges Werkzeug zur Verbesserung der Projektqualität und des Teamwachstums. Für angehende Kotlin-Entwickler löst der Review-Prozess oft Angst aus: „Was, wenn ich einen Bug übersehe?“, „Wie sage ich einem Kollegen, dass sein Code schlecht ist?“. In diesem Artikel schauen wir uns an, worauf man bei der Überprüfung von Kotlin-Code achten sollte und wie man Anmerkungen formuliert, damit sie hilfreich und nicht verletzend sind.

Wir werden Ihnen nicht die Grundlagen der Syntax beibringen – es wird vorausgesetzt, dass Sie bereits in Kotlin schreiben. Stattdessen konzentrieren wir uns auf typische Probleme, die im Code von Anfängern auftreten, und darauf, wie man Feedback gibt, ohne die Stimmung zu verderben.

1. Null Safety und Umgang mit nullable Typen

Kotlin ist stolz auf sein Typsystem, das die meisten NullPointerException bereits zur Kompilierzeit eliminiert. Anfänger missbrauchen jedoch oft den Operator !! (Not-Null-Assertion) oder behandeln nullable-Werte falsch.

Was prüfen:

\n
• Wird !! ohne triftigen Grund verwendet? Wenn Sie something!! sehen, fragen Sie den Autor: „Warum bist du sicher, dass hier kein null vorkommt? Vielleicht ist ?.let oder ?: besser?“.
\n
• Werden Aufrufketten mit ?. korrekt behandelt? Z.B. user?.address?.city ist sicher, aber wenn city benötigt wird, sollte ?: für einen Standardwert verwendet werden.
\n
• Wurde vergessen, lateinit var vor der Verwendung zu initialisieren? Überprüfen Sie, ob alle lateinit-Felder vor dem ersten Lesen definitiv initialisiert werden.
\n

// Schlecht\nfun getUserCity(user: User?): String {\n    return user!!.address!!.city // Risiko einer NPE\n}\n\n// Gut\nfun getUserCitySafe(user: User?): String {\n    return user?.address?.city ?: "Unknown"\n}\n

Wie Feedback geben: Sagen Sie statt „Du hast schlechten Code geschrieben“ lieber: „Hier könnte null vorkommen, lass uns !! durch einen sicheren Aufruf ersetzen, um einen Laufzeitabsturz zu vermeiden.“ Schlagen Sie eine Alternative vor – das lehrt, anstatt zu kritisieren.

2. Idiomatisches Kotlin: Collections, Scope-Funktionen und Sealed Classes

Kotlin ist nicht nur „Java mit anderer Syntax“. Viele Anfänger schreiben in Kotlin, als ob sie noch in Java arbeiten würden: Sie verwenden for-Schleifen anstelle von Collection-Funktionen, vergessen apply, let, run und nutzen keine sealed class zur Darstellung von Zuständen.

Was prüfen:

\n
• Werden Collection-Funktionen (map, filter, firstOrNull) anstelle von manuellen Schleifen verwendet? Das macht den Code prägnanter und lesbarer.
\n
• Gibt es überflüssige temporäre Variablen? Z.B. val result = list.filter { ... }.map { ... } ist besser, als es in drei Schritte mit mutablen Listen aufzuteilen.
\n
• Werden sealed class für Hierarchien verwendet, bei denen alle Fälle behandelt werden müssen (z.B. Result, UiState)? Dies ist eine zwingende Anforderung in modernen Kotlin-Projekten.
\n

// Schlecht (Java-Stil)\nfun getEvenSquares(list: List<Int>): List<Int> {\n    val result = mutableListOf<Int>()\n    for (i in list.indices) {\n        if (list[i] % 2 == 0) {\n            result.add(list[i] * list[i])\n        }\n    }\n    return result\n}\n\n// Gut (Kotlin-idiomatisch)\nfun getEvenSquaresIdiomatic(list: List<Int>): List<Int> {\n    return list.filter { it % 2 == 0 }.map { it * it }\n}\n

Wie Feedback geben: Weisen Sie auf die konkrete Redewendung hin: „Anstelle der for-Schleife kannst du filter + map verwenden, das ist kürzer und verständlicher. Möchtest du ein Beispiel sehen?“ Drängen Sie nicht – bieten Sie eine Diskussion an.

3. Architektur und Testbarkeit

Auch wenn das Projekt klein ist, ist das Code-Review ein hervorragender Zeitpunkt, um die