Revue de code Swift : 7 erreurs qui énervent les développeurs seniors

Revue de code Swift : comment arrêter d'énerver vos collègues et écrire du code de niveau senior

Avez-vous déjà envoyé une Pull Request pour recevoir 15 commentaires de votre chef d'équipe une heure plus tard ? « Force unwrap ? Sérieusement ? », « Et la gestion des erreurs ? », « Ce contrôleur de flux est en mémoire depuis trois jours ». Ça vous parle ? Bienvenue dans le monde de la revue de code Swift — un endroit où même les développeurs expérimentés se sentent parfois comme des stagiaires.

Dans cet article, j'ai rassemblé les remarques les plus fréquentes que les seniors laissent lors des code review. Nous analyserons des exemples réels de code, des anti-patrons et comment les corriger. Ce n'est pas de la théorie ennuyeuse — c'est l'expérience de combat de centaines de revues qui vous aidera à écrire un code qui ne donnera pas envie de tout réécrire. C'est parti !

1. Force Unwrap — premier amour et grande douleur

Commençons par le plus banal mais éternel. Le force unwrap (!) — c'est comme conduire sans ceinture de sécurité. C'est pratique, mais un freinage brusque et vous êtes aux urgences.

Mauvais code (typique d'un junior) :

func getUserName() -> String {    let name: String? = UserDefaults.standard.string(forKey: "user_name")    return name!}

Que dira le senior : « Et si UserDefaults est vide ? Crash. Toujours. Ajoute guard let ou defaultValue. »

Bon code :

func getUserName() -> String {    guard let name = UserDefaults.standard.string(forKey: "user_name") else {        return "Invité"    }    return name}

Exception : Le force unwrap n'est acceptable que dans un seul cas — lorsque vous êtes sûr à 146% que la valeur existe. Par exemple, avec les IBOutlets qui seront garantis initialisés. Mais même ici, le senior conseillera d'utiliser private var label: UILabel! — c'est une convention, pas une béquille.

2. Nombres magiques et chaînes : le code ne doit pas être une énigme

La deuxième chose qui saute aux yeux lors d'une revue de code Swift — ce sont les constantes magiques. « Pourquoi 0.75 ? Ah, c'est le coefficient d'animation... Lequel exactement ? » Si vous écrivez des nombres et des chaînes directement dans le code, vous forcez vos collègues à jouer au détective.

Mauvais code :

if user.age > 18 {    showAdultContent()}button.layer.cornerRadius = 12let url = "https://api.example.com/v1/users"

Que dira le senior : « 18 — c'est un nombre magique. Mets-le dans une constante. URL — dans un enum. cornerRadius — dans une constante stylistique. Le code doit se lire comme un livre, pas comme un code secret. »

Bon code :

private enum Constants {    static let adultAgeLimit = 18    static let defaultCornerRadius: CGFloat = 12    static let baseURL = "https://api.example.com/v1"}

enum APIEndpoint {    case users    var url: String {        switch self {        case .users: return Constants.baseURL + "/users"        }    }}

if user.age > Constants.adultAgeLimit {    showAdultContent()}

3. Memory Leaks : comment accidentellement faire planter l'application

La revue de code Swift passe rarement sans discussion sur les cycles de rétention. Les seniors aiment ce sujet car il montre si vous comprenez comment fonctionne l'ARC. L'anti-patron le plus populaire — la capture de self dans une closure sans référence faible.

Mauvais code :

class NetworkManager {    func fetchData(completion: @escaping (Data) -> Void) {        URLSession.shared.dataTask(with: url) { data, _, _ in            self.process(data) // self capturé fortement            completion(data)        }    }}

Que dira le senior : « Tu gardes une référence forte sur self à l'intérieur de la closure. Tant que la closure est vivante, l'objet ne sera pas libéré. Ajoute [weak self] et vérifie nil. Ou utilise [unowned self] si tu sais avec certitude que self survivra à la closure. »

Bon code :

func fetchDa