Code review en TypeScript : quoi vérifier et comment donner un retour

Introduction : pourquoi une revue de code en TypeScript ?

La revue de code n'est pas simplement une vérification formelle du code avant le merge. C'est un outil puissant pour améliorer la qualité du projet, partager les connaissances au sein de l'équipe et prévenir les bugs dès les premières étapes. Quand il s'agit de TypeScript, la revue de code prend une importance particulière : le typage statique, le puissant système de generics et les paramètres stricts du compilateur permettent de détecter de nombreuses erreurs avant même le lancement de l'application. Cependant, même en TypeScript, il existe des pièges faciles à manquer.

Dans cet article, nous allons voir sur quoi se concentrer lors de la revue de code TypeScript, et comment donner un retour qui soit utile, et non blessant.

1. Typage et generics : ne laissez pas any tout gâcher

L'un des principaux objectifs de TypeScript est de rendre les types explicites. Si any apparaît dans le code, c'est presque toujours un signal d'alarme. Lors de la revue de code, vérifiez :

• L'absence de any. Remplacez-le par unknown avec une vérification de type ultérieure, ou par un type spécifique.
• La correction des generics. Assurez-vous que les paramètres de type ne sont pas perdus et ne deviennent pas trop larges. Par exemple :

// Mauvais : on perd le typefunction getFirst(arr: any[]): any {    return arr[0];}

// Bon : on conserve le type via un genericfunction getFirst<T>(arr: T[]): T | undefined {    return arr[0];}

• Le typage des réponses API. Si un JSON arrive du serveur, il doit être décrit par une interface, et non par any.
• Les utility types. Utilisez Partial, Pick, Omit pour travailler de manière flexible avec les objets — cela réduit la duplication de code.

Conseil : activez dans tsconfig.json les flags strict: true et noImplicitAny: true — cela éliminera la plupart des problèmes au niveau de la compilation.

2. Logique et gestion des erreurs : ne taisez pas les problèmes

TypeScript ne protège pas contre les erreurs logiques, donc la revue de code doit vérifier la logique métier et la gestion des exceptions.

Que regarder :

• La gestion des cas limites. Que se passe-t-il si le tableau est vide, l'objet null ou la chaîne vide ? Exemple :

// Mauvais : on ne vérifie pas la présence de l'élémentfunction getUserName(users: User[], id: string): string {    return users.find(u => u.id === id)!.name; // peut planter avec une erreur}

// Bon : on vérifiefunction getUserName(users: User[], id: string): string | null {    const user = users.find(u => u.id === id);    return user ? user.name : null;}

• Les opérations asynchrones. Assurez-vous que les promesses sont correctement traitées via async/await, et que les erreurs sont capturées dans un try/catch.
• Éviter les mutations. Si une fonction ne doit pas modifier les données d'entrée, utilisez readonly et des méthodes immutables (par exemple, map au lieu de forEach avec modification d'un tableau externe).

3. Style de code et lisibilité : le code est écrit pour les humains

Même un code parfaitement typé peut être illisible. La revue de code est un excellent moment pour discuter du style.

Points principaux :

• Nommage. Les variables, fonctions et classes doivent indiquer leur objectif. Évitez les noms d'une seule lettre (sauf pour les indices de boucle). Exemple : fetchUserData est meilleur que getData.
• Taille des fonctions. Une fonction ne doit pas faire plus d'une chose. Si elle dépasse 20-30 lignes, c'est une raison de penser au refactoring.
• Commentaires. Les commentaires doivent expliquer pourquoi le code est écrit ainsi, et non ce qu'il fait. Si un commentaire duplique le code, supprimez-le.
• Formatage. Utilisez