Code review en Kotlin : quoi vérifier et comment donner un retour

Code review en Kotlin : quoi vérifier et comment donner un retour

Le code review n'est pas qu'une simple formalité ou un moyen de trouver des bugs. C'est un processus essentiel de partage de connaissances et d'amélioration de la qualité du code. En Kotlin, avec sa syntaxe expressive et ses fonctionnalités puissantes, la revue nécessite une attention particulière aux détails. Dans cet article, nous allons voir sur quoi se concentrer lors de la vérification du code Kotlin et comment donner un retour qui soit utile, et non blessant.

1. Quoi vérifier : checklist pour le développeur Kotlin

En commençant une revue, n'essayez pas de tout couvrir à la fois. Il est préférable de parcourir les catégories clés. Voici une checklist structurée pour Kotlin.

1.1. Null Safety et gestion des types nullable

Kotlin résout le problème des NPE, mais seulement si le développeur n'abuse pas de !! (not-null assertion). C'est le principal signal d'alarme.

\n
• Ce qu'on cherche : L'utilisation de !! dans le code de production. Presque toujours remplaçable par ?.let, ?: (elvis) ou un cast sécurisé as?.
\n
• Exemple de mauvais code :
\n

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

\n
• Exemple de bon 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. Utilisation des collections et Stream API

Kotlin offre un riche ensemble de fonctions pour travailler avec les collections. Vérifiez leur efficacité et leur lisibilité.

\n
• Ce qu'on cherche : Des boucles for superflues là où on pourrait utiliser map, filter, groupBy. Ainsi que des collections mutables (MutableList) si des collections immutables (List) suffisent.
\n
• Exemple de mauvais code :
\n

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

\n
• Exemple de bon code :
\n

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

1.3. Fonctions d'extension et portée

Les fonctions d'extension sont un outil puissant, mais elles peuvent facilement être dispersées dans le projet. Vérifiez la pertinence de leur utilisation.

\n
• Ce qu'on cherche : Des fonctions d'extension qui modifient l'état d'un objet (surtout si ce n'est pas évident). Des fonctions qui devraient être des méthodes de classe mais sont extraites en extension pour "l'esthétique".
\n
• Question à l'auteur : "Pourquoi est-ce une extension et non une méthode de la classe User ?"
\n

1.4. Utilisation de when au lieu de if-else

Kotlin encourage l'utilisation de when comme alternative plus lisible aux longues chaînes de if-else.

\n
• Ce qu'on cherche : Des échelles de if-else avec 3 conditions ou plus. Elles devraient être remplacées par when.
\n

// Au lieu de cela :\nif (status == Status.ACTIVE) { ... } else if (status == Status.PENDING) { ... } else { ... }\n\n// Mieux ainsi :\nwhen (status) {\n    Status.ACTIVE -> { ... }\n    Status.PENDING -> { ... }\n    else -> { ... }\n}

2. Comment donner un retour : de la critique à la collaboration

La partie technique n'est que la moitié du travail. L'autre moitié, c'est la communication. Un mauvais retour peut démotiver l'équipe. Un bon retour peut renforcer la confiance.

2.1. La règle du "Pourquoi, pas Quoi"

Au lieu de simplement dire "C'est mauvais", expliquez pourquoi c'est mauvais et comment le corriger.

\n
• Mauvais : "Il y a un !! ici — refais-le"