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

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

Code-Review ist nicht nur eine Formalität oder eine Möglichkeit, Fehler zu finden. Es ist ein äußerst wichtiger Prozess des Wissensaustauschs und der Verbesserung der Codequalität. In Kotlin mit seiner ausdrucksstarken Syntax und seinen leistungsstarken Funktionen erfordert das Review besondere Aufmerksamkeit für Details. In diesem Artikel werden wir untersuchen, worauf man bei der Überprüfung von Kotlin-Code achten sollte und wie man Feedback gibt, das nützlich und nicht verletzend ist.

1. Was prüfen: Checkliste für Kotlin-Entwickler

Wenn Sie mit dem Review beginnen, versuchen Sie nicht, alles auf einmal abzudecken. Gehen Sie besser die wichtigsten Kategorien durch. Hier ist eine strukturierte Checkliste für Kotlin.

1.1. Null-Safety und Arbeit mit nullable Typen

Kotlin löst das NPE-Problem, aber nur, wenn der Entwickler !! (Not-Null-Assertion) nicht missbraucht. Dies ist die wichtigste rote Flagge.

\n
• Wonach suchen: Verwendung von !! im Production-Code. Fast immer kann es durch ?.let, ?: (Elvis) oder einen sicheren Cast as? ersetzt werden.
\n
• Beispiel für schlechten Code:
\n

fun processUser(user: User?) {\n    val name = user!!.name // Potenzieller NPE!\n    println(name)\n}

\n
• Beispiel für guten Code:
\n

fun processUser(user: User?) {\n    user?.let { safeUser ->\n        println(safeUser.name)\n    } ?: run {\n        println("User is null")\n    }\n}

1.2. Verwendung von Collections und Stream API

Kotlin bietet eine Vielzahl von Funktionen für die Arbeit mit Collections. Prüfen Sie, wie effizient und lesbar sie verwendet werden.

\n
• Wonach suchen: Überflüssige for-Schleifen, wo map, filter, groupBy verwendet werden könnten. Auch mutable Collections (MutableList), wenn immutable (List) ausreichen.
\n
• Beispiel für schlechten Code:
\n

val names = mutableListOf<String>()\nfor (item in items) {\n    if (item.isActive) {\n        names.add(item.name)\n    }\n}

\n
• Beispiel für guten Code:
\n

val names = items\n    .filter { it.isActive }\n    .map { it.name } // Immutable Liste

1.3. Extension-Funktionen und Sichtbarkeit

Extension-Funktionen sind ein mächtiges Werkzeug, aber sie können leicht im Projekt "verschmiert" werden. Prüfen Sie, ob ihre Verwendung angemessen ist.

\n
• Wonach suchen: Extension-Funktionen, die den Zustand eines Objekts ändern (besonders wenn dies nicht offensichtlich ist). Funktionen, die Methoden einer Klasse sein sollten, aber aus "Schönheitsgründen" als Extension ausgelagert wurden.
\n
• Frage an den Autor: "Warum ist dies eine Extension und keine Methode der Klasse User?"
\n

1.4. Verwendung von when anstelle von if-else

Kotlin fördert die Verwendung von when als lesbarere Alternative zu langen if-else-Ketten.

\n
• Wonach suchen: Treppen aus if-else mit 3+ Bedingungen. Diese sollten durch when ersetzt werden.
\n

// Stattdessen:\nif (status == Status.ACTIVE) { ... } else if (status == Status.PENDING) { ... } else { ... }\n\n// Besser so:\nwhen (status) {\n    Status.ACTIVE -> { ... }\n    Status.PENDING -> { ... }\n    else -> { ... }\n}

2. Wie man Feedback gibt: Von Kritik zur Zusammenarbeit

Der technische Teil ist nur die eine Hälfte. Die andere Hälfte ist die Kommunikation. Schlechtes Feedback kann das Team demotivieren. Gutes Feedback kann Vertrauen stärken.

2.1. Die Regel "Warum, nicht Was"

Anstatt einfach zu sagen "Das ist schlecht", erklären Sie warum es schlecht ist und wie man es beheben kann.

\n
• Schlecht: "Hier ist !! — mach es neu