Journée type d'un développeur TypeScript : code, bugs et revue

Bonjour TypeScript : comment commence la journée d'un développeur

Imaginez : 9h00 du matin. Vous ouvrez votre ordinateur portable, préparez un café et voyez un message Telegram d'un collègue : « Hé, j'ai écrit une fonction hier, mais TypeScript râle sur le type unknown. Tu peux m'aider ? ». Ça vous parle ? Bienvenue dans la journée type d'un développeur TypeScript. Ce n'est pas seulement écrire du code — c'est l'art de jongler entre typage strict, deadlines et refactorings sans fin.

Dans cet article, je vous montre le quotidien réel d'un développeur TypeScript : du daily standup matinal au commit du soir. Vous découvrirez des exemples de code concrets, les problèmes typiques et leurs solutions. C'est parti !

Matin : standup et revue de code

9h30 — Daily standup

Petite réunion d'équipe. Vous dites : « Hier, j'ai terminé le module d'authentification, aujourd'hui je prévois de gérer le typage des réponses API ». Et là, vous entendez : « Pourquoi ne pas extraire les interfaces dans un fichier séparé ? On a une convention de code ». Un développeur TypeScript pense toujours un coup d'avance : interfaces, génériques, utility types.

Exemple : vous discutez du typage d'une réponse serveur. Au lieu d'écrire any, vous proposez :

interface ApiResponse<T> {\n  data: T;\n  error: string | null;\n  status: number;\n}\n\ntype User = {\n  id: string;\n  name: string;\n  email: string;\n};\n\n// Utilisation\nconst response: ApiResponse<User[]> = await fetchUsers();\n

Les collègues approuvent — c'est la bonne approche. Un développeur TypeScript le sait : un bon typage, c'est la moitié du succès.

10h00 — Revue de code : repérer les bugs avant qu'ils nous repèrent

Après le standup, vous ouvrez une Pull Request d'un junior. Il a écrit une fonction de validation d'email. Le code fonctionne, mais TypeScript vous prévient : Type 'string | undefined' is not assignable to type 'string'. Vous laissez un commentaire :

// ❌ Problème : les valeurs null/undefined ne sont pas gérées\nfunction validateEmail(input: string | null | undefined): boolean {\n  if (!input) return false;\n  const emailRegex = /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/;\n  return emailRegex.test(input);\n}\n\n// ✅ Solution : utiliser des guards et l'optional chaining\nfunction validateEmail(input: unknown): input is string {\n  return typeof input === 'string' && \n         input.length > 0 && \n         /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/.test(input);\n}\n

Vous expliquez : un développeur TypeScript pense toujours aux cas limites. Le typage n'est pas une contrainte, c'est une sécurité.

Milieu de journée : écriture de code et travail avec les génériques

11h30 — Tâche principale du jour : refactoring d'un legacy

Vous attaquez un vieux module JavaScript à réécrire en TypeScript. Il contient une fonction qui accepte « n'importe quoi » et retourne « n'importe quoi ». Un classique :

// 🚫 Ancien code JS\nfunction processData(data) {\n  if (data.type === 'user') {\n    return { id: data.id, name: data.name };\n  }\n  if (data.type === 'order') {\n    return { orderId: data.id, total: data.total };\n  }\n  return null;\n}\n

Vous transformez cela en code strictement typé avec des discriminated unions :

// ✅ Version TypeScript\ntype UserData = { type: 'user'; id: string; name: string };\ntype OrderData = { type: 'order'; id: string; total: number };\ntype InputData = UserData | OrderData;\n\ntype ProcessedResult<T> = T extends UserData \n  ? { id: string; name: string }\n  : T extends OrderData \n  ? { orderId: string; total: number }\n  : never;\n\nfunction processData<T extends InputData>(data: T): ProcessedResult<T> {\n  if (data.type === 'user') {\n    return { id: data.id, name: data.name } as ProcessedResult<T>;\n  }\n  return { orderId: data.id, total: data.total } as ProcessedResult<T>;\n}\n

Maintenant, TypeScript déduit automatiquement le type de résultat correct en fonction des données d'entrée. Les collègues