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

Code review en TypeScript : quoi vérifier et comment donner un retour d'information en pratique

La code review n'est pas une simple formalité, mais un outil puissant pour améliorer la qualité du code. En TypeScript, avec son riche système de types, la révision peut être particulièrement efficace. Dans cet article, nous allons voir sur quoi se concentrer lors de la vérification du code TypeScript, et comment donner un retour d'information utile, sans être blessant. Tous les exemples sont basés sur du code réel.

1. Types et annotations : éviter `any` et utiliser la rigueur

La première chose qui saute aux yeux lors d'une révision de code TypeScript, ce sont les types. TypeScript a été créé pour détecter les erreurs à la compilation, donc any est un signal d'alarme.

Que vérifier :

\n
• La présence de any. Chaque any doit être justifié. Si c'est une migration depuis JS, c'est acceptable, mais dans du nouveau code, non.
\n
• L'exactitude des types. N'utilisez pas string là où un enum ou un union type est nécessaire.
\n
• La typage excessif. TypeScript sait inférer les types. N'écrivez pas const x: number = 5 — écrivez const x = 5.
\n
• Les paramètres stricts. Vérifiez que dans tsconfig.json, strict: true, noImplicitAny, strictNullChecks sont activés.
\n

Exemple de mauvais code :

function processData(data: any) {\n  return data.name.toLowerCase();\n}

Comment corriger :

interface User {\n  name: string;\n}\n\nfunction processData(data: User): string {\n  return data.name.toLowerCase();\n}

Comment donner un retour d'information :

Au lieu de « Tu utilises any, c'est mal », dites : « Ici, any désactive la vérification des types. Définissons une interface User — cela améliorera la sécurité et la lisibilité du code ».

2. Gestion de null et undefined : strictNullChecks sauve des vies

Les erreurs Cannot read property of undefined sont classiques. TypeScript avec strictNullChecks aide à les éviter, mais seulement si le développeur traite correctement les valeurs nullable.

Que vérifier :

\n
• La vérification de null/undefined avant d'accéder aux propriétés.
\n
• L'utilisation de l'optional chaining (?.) — c'est moderne et sûr.
\n
• L'opérateur ! (non-null assertion) — à utiliser uniquement si vous êtes sûr à 100% que la valeur n'est pas null. Il est préférable de le remplacer par une vérification explicite.
\n
• L'utilisation correcte de ?? (nullish coalescing) au lieu de || pour les valeurs par défaut.
\n

Exemple de mauvais code :

function getCity(user: User | null): string {\n  return user!.address!.city; // Dangereux !\n}

Comment corriger :

function getCity(user: User | null): string {\n  return user?.address?.city ?? 'Unknown';\n}

Comment donner un retour d'information :

« L'utilisation de ! ici est risquée — si user s'avère être null, une erreur sera levée. Remplaçons-le par ?. et ?? — c'est sûr et lisible ».

3. Génériques et types utilitaires : ne compliquez pas inutilement

Les génériques sont une fonctionnalité puissante, mais il est facile de les rendre trop complexes. Le relecteur doit veiller à l'équilibre entre flexibilité et lisibilité.

Que vérifier :

\n
• La complexité excessive. Si un générique n'est utilisé qu'une seule fois, il n'est peut-être pas nécessaire.
\n
• L'utilisation correcte de extends — contraignez les génériques pour qu'ils n'acceptent pas n'importe quoi.
\n
• Les types utilitaires (Partial, Pick, Omit, Record) — leur utilisation simplifie le code.
\n
• Les types de retour — une fonction avec un généri