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

Code review en Kotlin : que vérifier et comment donner un retour pour les débutants

Code review (revue de code) — c'est l'un des processus clés dans le développement moderne. Pour les débutants en Kotlin, cela semble souvent intimidant : comment trouver les erreurs ? Que regarder exactement ? Comment ne pas offenser l'auteur du code ? Dans cet article, nous allons voir sur quoi se concentrer lors d'un code review de projets en Kotlin, et comment donner un retour qui soit utile, pas blessant. Ce contenu convient aussi bien à ceux qui apprennent à faire des revues qu'à ceux qui souhaitent améliorer leurs compétences.

Pourquoi un code review en Kotlin est-il nécessaire ?

Kotlin est un langage moderne, concis et sûr, mais il donne beaucoup de liberté au développeur. Sans code review, il est facile de commettre des erreurs liées à la null-sécurité, à une mauvaise utilisation des coroutines ou à une complexité excessive. La revue aide à :

• Trouver les bugs à un stade précoce.
• Améliorer la lisibilité et la maintenabilité du code.
• Diffuser les connaissances au sein de l'équipe.
• Respecter un style de code uniforme.

Pour les débutants, c'est aussi un excellent moyen d'apprendre sur des exemples des autres. Passons aux détails concrets.

Que vérifier lors d'un code review de code en Kotlin

Voici une checklist des points clés à vérifier dans chaque pull request. Divisons-les en blocs logiques.

1. Null-sécurité et types

Kotlin est fier de sa null-sécurité, mais elle peut être compromise. Vérifiez :

• Les types nullable (par exemple, String?) sont-ils utilisés uniquement là où c'est vraiment nécessaire ?
• Y a-t-il des !! (assertion non-null) inutiles ? Idéalement, il ne devrait pas y en avoir du tout dans le code de production.
• Les appels sécurisés (?.let { ... }) et l'opérateur Elvis (?:) sont-ils utilisés à la place de if (x != null) ?

Mauvais exemple :

val name: String? = getName()val length = name!!.length // Dangereux : provoque une NPE si name == null

Bon exemple :

val name: String? = getName()val length = name?.length ?: 0 // Sécurisé : si null, alors 0

2. Fonctions et leurs signatures

Kotlin prend en charge les arguments nommés et les valeurs par défaut. Vérifiez :

• La fonction est-elle trop longue (plus de 20–30 lignes) ? Il faudrait peut-être la diviser.
• Les paramètres par défaut sont-ils utilisés pour simplifier l'appel ?
• Y a-t-il des fonctions avec plus de 3–4 paramètres ? Cela complique la lecture.
• L'utilisation de fonctions d'extension est-elle appropriée ? Elles ne doivent pas modifier l'état de l'objet.

Exemple :

// Au lieu de cela :fun processUserData(name: String, age: Int, email: String, city: String, phone: String) { ... }

// Mieux ainsi :data class UserData(val name: String, val age: Int, val email: String, val city: String, val phone: String)fun processUserData(user: UserData) { ... }

3. Travail avec les coroutines (Coroutines)

Les coroutines sont un outil puissant de Kotlin, mais il est facile de les utiliser incorrectement. Faites attention :

• Le thread est-il bloqué à l'intérieur d'une coroutine (appel à Thread.sleep() ou entrées-sorties bloquantes) ?
• Le bon dispatcher est-il utilisé (Dispatchers.IO pour les requêtes réseau, Dispatchers.Main pour l'interface utilisateur) ?
• Y a-t-il des fuites de coroutines (par exemple, lancées dans une Activity sans annulation) ?
• withContext est-il utilisé pour changer de dispatcher, plutôt que launch à l'intérieur de launch ?

Mauvais exemple :

fun fetchData() {    GlobalScope.launch { // Fuite : non annulée lors de la destruction du composant        Thread.sleep(1000) // Bloque le thread !    }}

Bon exemple :

fun fetchData(scope: CoroutineScope) {    scope.launch {        withContext(Dispatchers