Réusinage de code legacy en Swift : de A à Z

Introduction : pourquoi le réusinage de code legacy en Swift est une nécessité

Chaque développeur iOS/macOS rencontre tôt ou tard du code legacy. Cela peut être un projet écrit en Objective-C et partiellement converti en Swift, ou une application créée à l'époque de Swift 2.0 utilisant Massive View Controller. Ce code fonctionne souvent, mais sa maintenance devient un enfer : toute modification nécessite des heures de test, et l'ajout d'une nouvelle fonctionnalité casse l'ancienne.

Le réusinage de code legacy en Swift n'est pas simplement un "nettoyage" du code. C'est un processus stratégique qui rend l'application plus testable, plus extensible et plus performante. Dans cet article, nous allons voir comment aborder le réusinage correctement, avec des exemples en Swift, pour ne pas casser la production et obtenir un résultat fonctionnel.

1. Diagnostic : comment savoir si le code legacy nécessite un réusinage

Avant de modifier le code, il faut comprendre ce qui nécessite des changements. Les principaux signes de code legacy en Swift :

• Massive View Controller (anti-patron MVC) — des fichiers de 500+ lignes où la logique, l'interface utilisateur et les requêtes réseau sont mélangées dans une seule classe.
• Couplage fort (tight coupling) — les classes dépendent directement les unes des autres, sans protocoles ni injection de dépendances.
• Absence de tests — si vous avez peur de modifier une ligne de code parce que vous ne savez pas ce qui va casser.
• Variables globales et singletons — utilisation de UserDefaults.standard ou NotificationCenter.default dans tout le projet.
• Force unwrapping — utilisation généralisée de ! au lieu d'une extraction sécurisée des optionnels.

1.1. Outils d'analyse du code legacy en Swift

Pour une évaluation objective de l'état du code, utilisez des outils :

• SwiftLint — un analyseur statique qui détecte les violations du code style.
• Xcode Instruments — pour rechercher les fuites mémoire et les problèmes de performance.
• Code coverage — indiquera la quantité de code couverte par les tests (généralement 0-10% dans les projets legacy).

Exemple de code legacy typique nécessitant un réusinage :

class LegacyViewController: UIViewController {        @IBOutlet weak var label: UILabel!    var data: [String] = []        override func viewDidLoad() {        super.viewDidLoad()        // Mélange de logique et d'interface utilisateur        let url = URL(string: "https://api.example.com/data")!        let data = try! Data(contentsOf: url)        let json = try! JSONSerialization.jsonObject(with: data) as! [[String: Any]]        for item in json {            data.append(item["name"] as! String)        }        label.text = data.first    }}

Plusieurs problèmes ici : force unwrapping, requête réseau synchrone sur le thread principal, mélange de logique et de présentation.

2. Stratégie de réusinage de code legacy en Swift : plan étape par étape

Le réusinage sans stratégie mène à la catastrophe. Utilisez l'approche du "démineur" : sécurisez d'abord le terrain, puis modifiez le code.

2.1. Étape 1 : Créez un "filet de sécurité" avec des tests

Avant de modifier quoi que ce soit, écrivez des tests pour le code existant. Utilisez des Characterization Tests — des tests qui figent le comportement actuel du système. Même si le code semble horrible, les tests montreront que vous n'avez pas cassé la logique.

import XCTest@testable import LegacyApp

class LegacyViewControllerTests: XCTestCase {        func testViewDidLoad_SetsLabelText() {        let sut = LegacyViewController()        sut.loadViewIfNeeded()        // Vérifions que label n'est pas nil et contient du texte        XCTAssertNotNil(sut.label.text)    }}

Ce test peut ne pas être idéal, mais il figera l'état actuel. Après le réusinage, le test doit passer.

2.2. Étape