Revue de code TypeScript : 10 erreurs qui agacent les seniors

Introduction : Pourquoi votre revue de code TypeScript ressemble-t-elle à un voyant rouge sur un tableau de bord ?

Avez-vous déjà envoyé une pull request pour recevoir une heure plus tard 20 commentaires d'un développeur senior, dont la moitié commençait par « on peut faire mieux » ? Ça vous parle. Si vous écrivez en TypeScript mais que votre code donne encore envie à vos collègues de le réécrire entièrement, cet article est pour vous.

Chez PythonLib, nous rencontrons souvent des situations où les développeurs, même connaissant la syntaxe TypeScript, commettent les mêmes erreurs. Ces erreurs ne cassent pas le code, mais le rendent illisible, non sécurisé et difficile à maintenir. Aujourd'hui, je vais vous montrer 10 remarques typiques que les seniors écrivent lors d'une code review TypeScript, et comment les éviter. Préparez-vous au refactoring !

1. « Any » — votre ennemi, pas votre ami

La critique la plus fréquente dans toute revue de code TypeScript est l'utilisation de any. Il semble plus simple d'écrire const data: any = await fetch(...) que de se pencher sur les types. Mais les seniors voient cela comme un chiffon rouge.

Mauvais :

function processUser(user: any) {  console.log(user.name.toUpperCase());}

Bon :

interface User {  id: number;  name: string;  email: string;}

function processUser(user: User): void {  console.log(user.name.toUpperCase());}

Pourquoi est-ce important ? TypeScript perd tout son sens si vous utilisez any. Vous désactivez littéralement le système de types. Si les données proviennent d'une API — créez une interface. Si le type est complexe — utilisez unknown avec des vérifications. C'est l'une des principales règles des TypeScript best practices.

2. Ignorer le mode strict

De nombreux projets désactivent le mode strict dans tsconfig.json, parce que « c'est plus rapide » ou « les types énervent ». Un développeur senior TypeScript remarquera immédiatement que votre code ne vérifie pas null et undefined.

Mauvais (strict: false) :

function getLength(str: string) {  return str.length; // str peut être null, et cela plantera}

Bon (strict: true) :

function getLength(str: string | null): number {  if (str === null) return 0;  return str.length;}

Conseil : Activez strict: true dans tsconfig.json. Cela vous obligera à écrire un code plus sûr. Lors d'une revue de code TypeScript, ce sera un atout, pas un défaut.

3. Magie avec les types : complexité excessive

Parfois, les développeurs essaient de montrer à quel point ils sont forts et écrivent des types qui font même réfléchir les seniors. Par exemple, des types conditionnels avec des génériques imbriqués là où une simple interface suffirait.

Mauvais (sur-ingénierie) :

type DeepReadonly<T> = {  readonly [P in keyof T]: T[P] extends object ? DeepReadonly<T[P]> : T[P];};

Bon (simplicité) :

interface Config {  readonly apiUrl: string;  readonly timeout: number;}

Les seniors apprécient la lisibilité du code. Si votre type peut être remplacé par une interface à trois champs — faites-le. Ne compliquez pas inutilement.

4. Gestion incorrecte des erreurs

Une erreur typique lors d'une code review TypeScript est le try-catch avec any ou un bloc catch vide. Les seniors le signaleront immédiatement.

Mauvais :

try {  const data = await fetchData();} catch (e) {  console.log('Erreur');}

Bon :

try {  const data = await fetchData();} catch (error: unknown) {  if (error instanceof Error) {    console.error(error.message);  } else {    console.error('Erreur inconnue', error);  }}

Utilisez unknown pour les erreurs. Cela vous