1 pièce(s) jointe(s)
Refuser TypeScript est un signal que vous ne vous souciez pas de la qualité du code
Refuser TypeScript est un signal que vous ne vous souciez pas de la qualité du code, par Robert Vitonsky
Il y a quelques jours, David Heinemeier Hansson a annoncé que Turbo 8 abandonnait TypeScript. Cela ne me dérange pas, car je ne sais même pas ce qu'est Turbo 8. Cependant, au cours des dernières années, certains programmeurs front-end ont essayé de me vendre l'idée que « TypeScript est inutile, il suffit d'utiliser des tests ». Je pense que les personnes ayant de telles opinions ne se soucient pas de la qualité du code ou ne savent tout simplement pas ce qu'est TypeScript. Ici, je vais expliquer pourquoi vous devriez utiliser TypeScript.*
Le contrôle de la qualité du code est un processus complexe qui permet de maintenir le code à jour. Vous ne pouvez pas simplement couvrir le code avec des tests à 100% ou examiner chaque pull request et être sûr que votre code est maintenable, et quelqu'un d'autre que vous peut le découvrir dans ce désordre.
Vous ne pouvez pas vous assurer que votre code n'a pas de bogues et qu'il est parfaitement maintenable. Vous pouvez seulement augmenter les structures défensives dans votre référentiel pour rendre difficile la diffusion de mauvais code avec des bogues. Plus il y a de barrières au mauvais code, meilleure est la qualité du code.
Cela signifie que vous devez utiliser toutes les méthodes ensemble pour protéger le code dans votre référentiel : tests unitaires/e2e/intégration, revue de code, outils d'analyse de code, et maintenir une documentation claire, etc.
TypeScript est un outil d'analyse de code puissant ; il peut détecter de nombreux défauts dans le code. Un compilateur TypeScript oblige les programmeurs à s'assurer que le code est correct au niveau des types. La valeur du typage statique est sous-estimée par David et beaucoup d'autres.
Voyons quels sont les avantages de TypeScript pour la qualité du code.
Les contrats
Les types statiques permettent de définir des contrats dans le code.
Code:
1
2
3
4
5
6
7
8
9
| type Participant = {
id: string;
name: string;
};
function sayHi(participant: Participant) {
//...
console.log(`Hi ${participant.name}`);
} |
La fonction sayHi requiert un objet avec des propriétés et des types exacts, et ne se soucie pas de ce que l'utilisateur de cette fonction fera pour répondre aux exigences. Le compilateur garantit que le type sera correct.
Un utilisateur peut fournir un objet qui ne répond pas aux exigences et transformer le type en any, mais ce n'est pas un problème pour la fonction sayHi. Il s'agit d'une délégation de responsabilité, un concept important que les développeurs doivent comprendre pour utiliser correctement TypeScript et profiter de ses avantages.
Les programmeurs doivent valider toutes les données non fiables, telles que les entrées utilisateur et autres données d'entrée-sortie, ou les résultats de l'interopérabilité avec JavaScript. Après la validation et la définition des types, ils peuvent ensuite transmettre les données au code TypeScript en étant sûrs que les contrats seront respectés car le compilateur TypeScript a vérifié le code. Si un programmeur fait un cast d'un type, il doit s'assurer que le code est correct au moment de l'exécution.
Si, dans votre projet, vous pouvez convertir des types non intersectés en n'importe quel type, à l'exception des types unknown, sans vérification au moment de l'exécution, vous avez probablement des problèmes de qualité du code dans votre projet.
Les contrats vous permettent d'éviter d'écrire une validation pour chaque fonction afin de garantir l'exactitude des données. C'est excellent pour les performances et la propreté du code, qui devient simple et stupide.
Expérience du développeur et coûts de développement
Il m'arrive d'écrire du code en JavaScript pur, principalement dans la console du navigateur pour des calculs rapides ou l'analyse de données sur une page web. Il y a quelques mois, j'ai écrit un script pour Node.js afin de traduire des fichiers locaux à l'aide de ChatGPT. Ces fichiers contenaient de longs textes, et ChatGPT avait des limites, il fallait donc un certain temps pour découper les textes, les traduire, trouver des erreurs dans les résultats de ChatGPT, retraduire si nécessaire, et enfin recouper les tranches. Ce processus a duré entre 3 et 5 minutes, en fonction de la taille du fichier local.
J'ai perdu un peu de temps au cours de ce processus à cause d'erreurs de type triviales, comme oublier d'utiliser await, ce qui a eu pour conséquence qu'une variable contenant Promise a écrit « [objet Promise] » dans le fichier au lieu du texte traduit, ou de fournir le mauvais objet comme argument d'une fonction.
TypeScript élimine ce type d'erreurs.
Investissements pour l'avenir
TypeScript offre à votre code la possibilité d'être analysé par d'autres outils parce qu'il ajoute un contexte.
Avec l'EDI, vous pouvez renommer une propriété dans une interface, et toutes les entités qui mettent en œuvre l'interface mettront automatiquement à jour le nom de la propriété à leurs places respectives.
Les outils d'intelligence artificielle tels que ChatGPT et Copilot bénéficient des méta-informations supplémentaires fournies par TypeScript, ce qui peut améliorer l'analyse et la génération de code. Les outils d'analyse peuvent mieux identifier le code potentiellement risqué.
Le typage statique et les tests se complètent bien. Le code front-end est fortement asynchrone, ce qui rend difficile la couverture de tous les cas de test possibles et la prise en compte de tous les états de code potentiels. TypeScript oblige les programmeurs à traiter tous les cas possibles d'un état, ce qui améliore la fiabilité du code.
La complexité des types
David avait déclaré :
Citation:
TypeScript me gêne dans ce domaine. Pas seulement parce qu'il nécessite une étape de compilation explicite, mais parce qu'il pollue le code avec des gymnastiques de types qui ajoutent très peu de joie à mon expérience de développement, et assez souvent beaucoup de chagrin. Les choses qui devraient être faciles deviennent difficiles, et les choses qui sont difficiles deviennent n'importe quoi. Non merci !
Je cite cette phrase parce que je l'ai entendue à maintes reprises.
Il est vrai que vous devez parfois écrire des types non triviaux pour convaincre le compilateur que vos données sont correctes.
Ce n'est pas grave. La création d'un code facile à maintenir et de haute qualité nécessite souvent un travail acharné.
Conclusion
TypeScript n'est qu'un outil, il n'améliorera pas automatiquement la qualité du code si vous l'activez simplement. Votre projet doit avoir des règles en place pour utiliser l'outil correctement, et un architecte qui applique ces règles. Plus les règles sont strictes, mieux c'est.
Lorsque vous désactivez les types statiques dans votre projet, vous perdez de nombreuses possibilités de contrôler la qualité du code.
Les fichiers de déclaration de type JSDoc et .d.ts ne peuvent pas remplacer le typage statique du code. Ils permettent simplement de déclarer l'API externe des entités, mais ne permettent pas d'analyser le code à l'intérieur des entités (fonctions, classes et autres blocs de code).
Source : "Refusing TypeScript is a signal that you don't care about code quality"
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
Voir aussi :
:fleche: TypeScript se tourne vers Gopher : Microsoft mise sur Go pour multiplier la vitesse par 10, par Kush Creates
:fleche: Tout partout en même temps : Les promesses JavaScript, par Mensur Durakovic
:fleche: Cinq vérités inconfortables à propos de TypeScript selon Stefan Baumgartner, auteur de livres sur le langage de programmation
