Réusinage de code Swift : quand en a-t-on besoin et comment bien le faire

Votre code fonctionne, mais ce n'est pas une raison pour ne pas y toucher

Vous avez écrit une application, elle se lance, les clients sont satisfaits, les builds ne plantent pas. On pourrait penser qu'il est temps de souffler et de se consacrer à de nouvelles fonctionnalités. Mais à l'intérieur de la base de code se cache un monstre de Frankenstein : des méthodes de 300 lignes, du copier-coller, une logique alambiquée et des nombres magiques dispersés dans tout le projet. Si vous vous êtes déjà surpris à penser « il vaut mieux ne pas toucher à cette classe, sinon tout va casser » — le réusinage de code Swift n'est pas pour vous une simple recommandation, mais une nécessité vitale.

Dans cet article, nous allons voir quand il est vraiment utile de se lancer dans le réusinage, et quand il vaut mieux laisser le code tranquille. Je vais vous montrer des exemples concrets en Swift que vous pourrez appliquer dès aujourd'hui. Et oui, rien de superflu — que de la pratique.

Qu'est-ce que le réusinage et ce qu'il n'est pas

Commençons par les bases. Le réusinage de code Swift est le processus de modification de la structure interne d'un programme sans changer son comportement externe. Vous n'ajoutez pas de nouvelles fonctionnalités, vous ne corrigez pas de bugs (même si vous en trouvez souvent en cours de route). Vous rendez simplement le code plus propre, plus compréhensible et plus facile à maintenir.

Il est important de comprendre : réusinage ≠ réécriture complète. Si vous avez envie de jeter tout le projet et de recommencer de zéro avec SwiftUI et l'architecture TCA — ce n'est pas du réusinage, c'est une réécriture. Et la réécriture, comme le montre l'expérience, se solde par un échec dans 80 % des cas.

Quand faire du réusinage de code Swift : trois signaux fiables

1. La règle de trois (Rule of Three)

Si vous copiez le même fragment de code pour la troisième fois — c'est un signal. Pas à la deuxième, mais bien à la troisième. La première fois, c'est ok, vous avez résolu le problème. La deuxième fois, c'est déjà discutable, mais on peut mettre cela sur le compte de la précipitation. La troisième fois — c'est fini, écrivez une solution généralisée.

// Mauvais : copier-collerfunc formatUserName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

func formatProductName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

// Bon : méthode uniquefunc formatDisplayName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

2. L'« odeur » des méthodes trop longues

Si une méthode ne tient pas sur l'écran d'un téléphone — c'est un problème. Dans la communauté Swift, on considère qu'une méthode doit faire entre 15 et 20 lignes. Bien sûr, il y a des exceptions (calculs complexes), mais dans 95 % des cas, une méthode trop longue est le signe qu'elle en fait trop.

3. Les tests deviennent un enfer

Quand pour tester une seule fonction, vous devez mocker 5 services, configurer une base de données et lire un fichier sur le disque — c'est un signal d'alarme. Le réusinage de code Swift doit rendre votre base de code plus testable. Si écrire des tests est douloureux aujourd'hui — c'est que l'architecture demande du changement.

Exemples pratiques de réusinage Swift

Regardons des situations réelles auxquelles chaque développeur iOS est confronté.

Exemple 1 : Se débarrasser des nombres magiques

Les nombres magiques sont des littéraux numériques dont la valeur est incompréhensible sans contexte. Ils rendent le code fragile et illisible.

// Avant le réusinagefunc calculateDiscount(price: Double) -> Double {    if price > 1000 {        return price * 0.15    } else if price > 500 {        return price * 0.1    } else {        return price * 0.05    }}

// Après le réusinageprivate struct DiscountConstants {    static let premiumThreshold: Double = 1000    static let standardThreshold: Double = 500    static let premiumRate: Double = 0.15    static let standardRate: Double = 0.10    static let basicRate: Double = 0.05}

func calculateDiscount(price: Double) -> Double {    switch price {    case _ where price > DiscountConstants.premiumThreshold:        return price * DiscountConstants.premiumRate    case _ where price > DiscountConstants.standardThreshold:        return price * DiscountConstants.standardRate    default:        return price * DiscountConstants.basicRate    }}