Réusinage du code legacy en Kotlin : guide étape par étape

Réfactorisation du code legacy en Kotlin : stratégie et exemples pratiques

Travailler avec du code legacy est une partie inévitable de la vie de tout développeur. Souvent, ce code est écrit en Java, mais migré vers Kotlin sans profonde remise en question, ou représente des « spaghettis » de fonctions utilitaires et de champs nullable. La refactorisation de ce code améliore non seulement la lisibilité, mais aussi les performances et la sécurité de l'application. Dans cet article, nous allons détailler une stratégie étape par étape pour refactoriser du code legacy en Kotlin avec des exemples concrets.

1. Préparation et test : le fondement de la sécurité

Avant de modifier le code, il est nécessaire de garantir son bon fonctionnement après les changements. Sans tests, la refactorisation devient un jeu de devinettes.

• Écrivez des tests de caractérisation (Characterization Tests) : Exécutez le code existant avec différentes données d'entrée et enregistrez les valeurs de sortie. Ces tests deviendront votre « filet de sécurité ».
• Utilisez l'annotation @Deprecated : Si vous ne pouvez pas supprimer immédiatement l'ancienne API publique, marquez-la avec @Deprecated en indiquant une alternative.
• Travaillez par petites étapes : Ne refactorisez jamais plus d'un bloc logique à la fois. Chaque commit doit passer tous les tests.

Exemple de test de caractérisation pour une ancienne fonction :

// Code legacyfun calculateTotal(items: List<Int>?): Int {    if (items == null) return 0    var sum = 0    for (item in items) {        sum += item    }    return sum}

// Test@Testfun `calculateTotal returns sum or zero`() {    assertEquals(0, calculateTotal(null))    assertEquals(6, calculateTotal(listOf(1, 2, 3)))    assertEquals(0, calculateTotal(emptyList()))}

2. Élimination de la null-sécurité et utilisation des fonctions de portée (Scope-functions)

Le code legacy souffre souvent de vérifications redondantes de null. Kotlin fournit des outils élégants pour travailler avec les types nullable.

Ce que nous faisons : Remplacer les if (x != null) imbriqués par let, run ou also.

// Avant la refactorisationfun processUser(user: User?) {    if (user != null) {        if (user.name != null) {            println("User: ${user.name}")        }    }}

// Après la refactorisationfun processUser(user: User?) {    user?.let { u ->        u.name?.let { name ->            println("User: $name")        }    }}

// Ou encore plus court avec runfun processUserShort(user: User?) {    user?.run {        name?.let { println("User: $it") }    }}

Cette approche rend le code plus déclaratif et réduit le risque d'oublier une vérification.

3. Remplacement des classes utilitaires par des fonctions d'extension (Extension-functions)

Dans les projets Java legacy, on trouve souvent des classes utilitaires statiques (StringUtils, DateUtils). En Kotlin, il est préférable de les remplacer par des fonctions d'extension.

Pourquoi c'est important : Les fonctions d'extension rendent le code plus lisible et permettent à l'IDE de les proposer comme des méthodes de la classe elle-même.

// Style Java legacyobject StringUtils {    fun isPalindrome(input: String): Boolean {        val cleaned = input.filter { it.isLetterOrDigit() }.lowercase()        return cleaned == cleaned.reversed()    }}

// Utilisationval result = StringUtils.isPalindrome("A man, a plan, a canal: Panama")

// Refactorisation en Kotlinfun String.isPalindrome(): Boolean {    val cleaned = this.filter { it.isLetterOrDigit() }.lowercase()    return cleaned == cleaned.reversed()}

// Utilisationval result = "A man, a plan, a canal: Panama".isPalindrome()

Il convient également de prêter attention au remplacement de java.util.Date par java.time (LocalDate, Instant) — cela améliorera la sécurité de la gestion du temps.

4. Optimis