Code Review en Swift : 10 choses que je vérifie en premier

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Pourquoi le Code Review en Swift n'est pas une question de pinaillage

Imaginez la situation : vous ouvrez la pull request d'un collègue, vous voyez 500 lignes de code Swift et vous réalisez que le daily commence dans 20 minutes. Familier ? Le code review (ou revue de code) n'est pas une compétition « qui trouvera le plus de fautes de frappe ». C'est votre chance de prévenir des bugs en production, d'améliorer l'architecture et de transmettre des connaissances à l'équipe.

Dans cet article, j'ai rassemblé une checklist de code review pour Swift que j'utilise moi-même. Rien de superflu — seulement des vérifications concrètes, des exemples de code et des explications sur pourquoi c'est important. Même si vous codez en Python mais que vous jetez un œil au monde du développement iOS, ce contenu vous sera utile.

\n\n

1. Sécurité mémoire et types optionnels

Swift est fier de sa sécurité mémoire, mais cela ne signifie pas qu'on peut se relâcher. Le problème le plus fréquent est le force unwrapping. Chaque point d'exclamation est un crash potentiel.

\n\n

Que vérifier :

Force unwrap (!) — acceptable uniquement dans les tests ou lorsque vous êtes sûr à 100% de la valeur. Dans le code de production, c'est un drapeau rouge.
IUO (Implicitly Unwrapped Optionals) — utilisez-les uniquement pour les IBOutlet ou les propriétés qui sont initialisées après init, mais avant la première utilisation.
Cycles de rétention — vérifiez les closures pour la présence de [weak self] ou [unowned self].

\n\n

// Mauvais : force unwrap sans vérification\nlet url = URL(string: "https://pythonlib.ru")! // Crash si la chaîne est invalide\n\n// Bon : guard let\nguard let url = URL(string: "https://pythonlib.ru") else {\n    print("URL invalide")\n    return\n}\n\n// Vérification de cycle de rétention dans une closure\nclass NetworkManager {\n    var completionHandler: (() -> Void)?\n    \n    func fetchData() {\n        completionHandler = { [weak self] in\n            guard let self = self else { return }\n            self.updateUI() // self est maintenant une référence faible\n        }\n    }\n    \n    func updateUI() { /* ... */ }\n}\n

\n\n

Conseil pour le code review : si vous voyez ! — demandez « pourquoi pas guard ou if let ici ? ». Cela évitera de nombreux plantages.

\n\n

2. Gestion des erreurs : n'avalez pas les exceptions

Swift offre un mécanisme puissant do-catch, mais les développeurs l'ignorent souvent. Un anti-patron typique est try! ou un catch vide.

\n\n

Que vérifier :

try! — presque toujours un mal. Uniquement si vous écrivez un test.
catch {} vide — vous perdez simplement l'information sur l'erreur. Au minimum, loggez-la.
Propagation des erreurs vers le haut (throws) — la fonction doit soit gérer l'erreur, soit la propager explicitement.

\n\n

// Mauvais : on avale l'erreur\ndo {\n    let data = try fetchData()\n} catch {\n    // On ne fait rien — l'erreur est perdue\n}\n\n// Bon : on logge et on affiche à l'utilisateur\ndo {\n    let data = try fetchData()\n    updateUI(with: data)\n} catch let error as NetworkError {\n    showAlert(message: error.localizedDescription)\n} catch {\n    print("Erreur inconnue : \\(error.localizedDescription)")\n    showGenericError()\n}\n

\n\n

Dans un code review pour Swift, vérifiez toujours que Error n'est pas simplement ignorée. L'utilisateur doit comprendre ce qui s'est mal passé.

\n\n

3. Architecture : MVC, MVVM ou VIPER ?

Peu importe le patron que vous avez choisi — l'important est que le code le suive. Lors du code review, vous voyez si le ViewController ne s'est pas transformé en « God Object » (une classe qui fait tout).

\n\n