FR
RU
EN
ES
ZH
DE
PT
AR
HI
Introduction : quand le code commence à « sentir »
Chaque développeur connaît ce sentiment. Vous ouvrez un fichier que vous avez écrit il y a trois mois, et votre visage s'allonge. Quelque part au fond de vous, vous entendez un murmure : « Ce n'est pas moi qui ai écrit ça, c'était un débutant ». Mais le rétroviseur est impitoyable : c'était vous. Le code fonctionne, les tests passent, mais à chaque ajout d'une nouvelle fonctionnalité, vous perdez de plus en plus de temps. Cela vous parle ?
C'est le moment de penser au réusinage de code TypeScript. Pas de tout réécrire depuis zéro (c'est la voie de l'enfer), mais d'apporter des améliorations chirurgicalement précises qui rendent le code plus propre, plus compréhensible et plus sûr. Dans cet article, nous allons voir quand commencer le réusinage, comment le faire sans douleur et pourquoi TypeScript vous donne des super-pouvoirs pour ce processus.
Quand faut-il effectuer un réusinage de code TypeScript ?
Il existe un mythe selon lequel le réusinage est une tâche distincte dans un sprint. En pratique, le meilleur réusinage est un processus continu. Mais il existe des signaux clairs qui crient : « Stop ! Il faut mettre de l'ordre ici ! ».
La règle de trois (et de deux de plus)
Si vous avez copié le même fragment de code trois fois, extrayez-le dans une fonction ou une classe. Si vous voyez qu'un collègue a copié votre code, c'est la quatrième fois. TypeScript avec son typage strict rend cette règle particulièrement importante : la duplication des types entraîne une désynchronisation des données.
Symptômes d'un code « sale » en TypeScript
- Chaos des any : Si dans votre projet
anyapparaît plus souvent questring, c'est un drapeau rouge. TypeScript perd son sens. - Fonctions monstres : Une fonction de 200+ lignes qui fait tout : valide, parse, envoie une requête et dessine l'interface.
- Nombres et chaînes « magiques » :
if (status === 3)— que signifie 3 ? Personne ne le sait, sauf l'auteur qui a déjà démissionné. - Violation du principe DRY : Des interfaces identiques éparpillées dans 10 fichiers.
- Tests plus effrayants que le code : Si pour tester une fonction, il faut lancer un serveur, une base de données et démarrer Docker, vous avez pris un mauvais chemin.
Rappelez-vous la règle principale : le réusinage de code TypeScript doit être fait lorsque l'ajout d'une nouvelle fonctionnalité prend plus de temps que son écriture à partir de zéro. C'est le moment de vérité.
Principes de base : comment ne pas casser la production
Avant de vous lancer dans le réusinage, souvenez-vous des trois piliers sur lesquels repose un réusinage sûr :
- Les tests sont votre assurance. Sans couverture de tests, le réusinage est une roulette russe. Écrivez au moins des tests unitaires de base avant de commencer.
- Petits pas. N'essayez pas de réusiner tout le projet en une nuit. Un module = un commit.
- Le compilateur TypeScript est votre ami. Utilisez les paramètres stricts de
tsconfig.json:strict: trueest votre détecteur de mensonges.
Techniques pratiques de réusinage avec des exemples en TypeScript
Passons maintenant à la partie la plus intéressante : le code. Nous allons examiner trois situations réelles et montrer comment les améliorer.
1. Se débarrasser de any : la puissance des génériques
Mauvais exemple. La fonction accepte n'importe quoi et retourne n'importe quoi. Ce n'est pas du TypeScript, c'est du JavaScript déguisé.
// MAUVAIS : any tue le typagefunction getFirstElement(arr: any[]): any { if (arr.length === 0) { throw new Error('Array is empty'); } return arr[0];}
const num = getFirstElement([1, 2, 3]); // num: anyconsole.log(num.toUpperCase()); // Erreur à l'exécution, mais le compilateur se taitBon exemple. Utilisation de génériques. Le code devient plus sûr et l'IDE suggère les types.
// BON : les génériques sauventfunction getFirstElement<T>(arr: T[]): T { if (arr.length === 0) { throw new Error('Array is em 
