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

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

Code review (revue de code) n'est pas une simple formalité, mais un outil puissant pour améliorer la qualité du projet et la croissance de l'équipe. Pour les développeurs débutants en Kotlin, le processus de revue suscite souvent de la peur : « Et si je rate un bug ? », « Comment dire à un collègue que son code est mauvais ? ». Dans cet article, nous allons voir sur quoi se concentrer lors de la vérification du code Kotlin et comment formuler des remarques pour qu'elles soient utiles, et non blessantes.

Nous n'allons pas vous apprendre les bases de la syntaxe — nous supposons que vous écrivez déjà en Kotlin. Au lieu de cela, nous nous concentrerons sur les problèmes typiques rencontrés dans le code des débutants, et sur la façon de donner un retour sans casser l'ambiance.

1. Null safety et gestion des types nullable

Kotlin est fier de son système de types qui élimine la plupart des NullPointerException dès la compilation. Cependant, les débutants abusent souvent de l'opérateur !! (not-null assertion) ou gèrent mal les valeurs nullable.

Que vérifier :

\n
• L'opérateur !! est-il utilisé sans raison valable ? Si vous voyez something!!, demandez à l'auteur : « Pourquoi es-tu sûr qu'il n'y aura pas de null ici ? Ne serait-il pas mieux d'utiliser ?.let ou ?: ? ».
\n
• Les chaînes d'appels via ?. sont-elles correctement gérées ? Par exemple, user?.address?.city est sûr, mais si city est nécessaire, il est préférable d'utiliser ?: pour une valeur par défaut.
\n
• Le lateinit var est-il initialisé avant utilisation ? Vérifiez que tous les champs lateinit seront bien initialisés avant la première lecture.
\n

// Mauvais\nfun getUserCity(user: User?): String {\n    return user!!.address!!.city // Risque de NPE\n}\n\n// Bon\nfun getUserCitySafe(user: User?): String {\n    return user?.address?.city ?: "Inconnu"\n}\n

Comment donner un retour : Au lieu de « Tu as écrit du mauvais code », dites : « Ici, il pourrait y avoir null, remplaçons !! par un appel sécurisé pour éviter un crash à l'exécution ». Proposez une alternative — cela enseigne, plutôt que de critiquer.

2. Idiomaticité de Kotlin : collections, scope-functions et sealed class

Kotlin n'est pas simplement « Java avec une autre syntaxe ». De nombreux débutants écrivent en Kotlin comme s'ils travaillaient encore en Java : ils utilisent des boucles for au lieu des fonctions de collection, oublient apply, let, run et n'utilisent pas sealed class pour représenter les états.

Que vérifier :

\n
• Les fonctions de collection (map, filter, firstOrNull) sont-elles utilisées au lieu de boucles manuelles ? Cela rend le code plus concis et lisible.
\n
• Y a-t-il des variables temporaires redondantes ? Par exemple, val result = list.filter { ... }.map { ... } est mieux que de diviser en trois étapes avec des listes mutables.
\n
• Les sealed class sont-elles utilisées pour les hiérarchies où tous les cas doivent être traités (par exemple, Result, UiState) ? C'est une exigence obligatoire dans les projets Kotlin modernes.
\n

// Mauvais (style Java)\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// Bon (idiomatique Kotlin)\nfun getEvenSquaresIdiomatic(list: List<Int>): List<Int> {\n    return list.filter { it % 2 == 0 }.map { it * it }\n}\n

Comment donner un retour : Indiquez une idiome spécifique : « Au lieu d'une boucle for, tu peux utiliser filter + map, c'est plus court et plus clair. Tu veux que je te montre un exemple ? ». N'imposez pas — proposez d'en discuter.

3. Architecture et testabilité

Même si le projet est petit, la code review est un excellent moment pour vérifier