Présentation
Même en 2024, 12 ans après la sortie de TypeScript et 17 ans après la sortie de JSDoc, de nombreuses personnes ne savent toujours pas pourquoi utiliser un outil de saisie statique dans leur projet JavaScript, même après qu'il soit devenu un standard dans le langage JavaScript/ Communauté NodeJs.
Dans cet article, je vais vous expliquer ce que sont TypeScript et JSDoc et pourquoi vous devriez utiliser l'un d'entre eux dans vos projets.
TypeScript et JSDoc sont des outils permettant à JavaScript d'avoir un typage statique. Voir ci-dessous pour un exemple des deux.
Comme vous pouvez le voir, TypeScript est généralement moins verbeux que JSDoc, mais d'un autre côté, JSDoc ne nécessite pas d'étape de construction, il fonctionne directement avec les commentaires dans le code JavaScript.
convertir-string-to-int.ts (fichier TYPESCRIPT !)
convertir-string-to-int.js (fichier JAVASCRIPT !)
Avant de parler des avantages, je dois dire que peu importe le nombre d'articles que vous lisez ou la qualité de ces articles, il n'y a aucun moyen de décrire à quel point l'expérience du développeur est meilleure lorsque vous travaillez avec la saisie statique.
Personne ne peut expliquer avec des mots ou des arguments à quel point il est bon de travailler avec une base de code qui a un typage statique par rapport à un typage non typé, pas même le meilleur des poètes.
Comme beaucoup d'autres, je vais essayer de traduire ce sentiment en faits et données, mais je vous assure que cela ne suffira pas à décrire le sentiment exact.
C'est sans aucun doute le plus grand avantage de la saisie statique. Il n'y a pas assez de mots pour décrire à quel point c'est utile, à la fois pour éviter les retouches et pour économiser de l'argent.
Pour expédier les choses rapidement, principalement des hotfix, on finit par ne pas avoir le temps d'écrire des tests unitaires ou de tester tous les flux possibles d'une solution. Si vous travaillez avec du JavaScript pur, il n'y a aucun moyen de garantir que :
Toutes les variables que vous utilisez existent
Toutes les variables que vous utilisez sont déclarées
Vous utilisez des méthodes autorisées pour ce type (ex : vous pouvez utiliser map dans une variable numérique)
Si vous comparez des variables équivalentes (vous ne devriez pas comparer un nombre avec un tableau)
Si vous ne testez pas extrêmement bien votre code, vous devrez y travailler à nouveau pour corriger un bug, en passant un temps précieux sur quelque chose que vous auriez pu tousser auparavant. Les bugs causés par ces choses peuvent paraître stupides, mais ce sont ceux qui surviennent le plus.
En utilisant le typage statique, vous garantissez un développement plus sûr et plus rapide, réduisez de manière absurde le nombre de bugs en production et permettez au développeur de se concentrer uniquement sur ce qui apporte réellement de la valeur : la logique métier.
La plupart des projets existants et des projets à forte intensité cloud (projets comportant de nombreuses ressources exclusives au cloud) ont un processus difficile d'exécution du code localement, ou pire encore, vous devez le déployer pour pouvoir l'exécuter sans simulation.
Le processus d'exécution locale peut être très long et épuisant pour les développeurs, et pouvoir l'éviter permet d'économiser beaucoup de ressources (temps, argent, patience, ressources cloud, etc.).
Avec le typage statique, le code est très prévisible, et vous pouvez tout développer en sachant ce qui se passe dans chaque partie du code, et suivre l'exécution très facilement, ce qui fait que le seul moment où vous avez besoin d'exécuter le code c'est après avoir terminé le développement, pour vraiment tester si tout fonctionne comme prévu.
La plupart du temps (sinon la totalité), lorsque nous essayons d'écrire de la documentation sur une fonction et d'ajouter des exemples d'entrée/sortie, elle devient obsolète en un clin d'œil. Les développeurs ne se souviennent jamais de mettre à jour la documentation et les Scrum Masters ne veulent jamais y consacrer suffisamment de temps.
Avec le typage statique, le code est un live doc. Il ne deviendra jamais obsolète, car lorsque les développeurs mettront à jour le code, ils mettront à jour la documentation.
Après l'implémentation des modules ES dans NodeJs, de nombreuses bibliothèques ont commencé à migrer vers cette nouvelle façon d'écrire du code, donc leurs nouvelles versions (plus sécurisées, fiables, performantes et avec plus de fonctionnalités) ne sont pas compatibles avec les anciennes versions de JavaScript, ce qui vous laisse coincé avec des versions obsolètes et dangereuses.
Devinez ce qui est compatible avec les modules CommonJs et ES sans avoir à changer quoi que ce soit dans votre code (seulement quelques lignes dans la configuration) ? Exactement, TypeScript (malheureusement, je pense que JSDoc n'a pas cet avantage).
Au lieu d'avoir à mémoriser toutes les propriétés et méthodes de quelque chose, laissez le typage statique et votre IDE préféré le faire pour vous !
Cela réduit le temps de développement car :
Vous n'avez pas besoin d'aller et venir pour consulter les propriétés de quelque chose
Vous pouvez taper uniquement les premières lettres de la propriété/méthode et appuyer sur Entrée (ou sélectionner la bonne suggestion, puis appuyer sur Entrée), et elle sera complétée automatiquement
Cela évite également les erreurs d'écriture des mots, ce qui provoque plus de bugs en production qu'il ne le devrait.
Il est courant que dans un projet, différents développeurs écrivent des parties spécifiques du code, et ce qui peut sembler très évident à la personne qui l'écrit peut ne pas être intuitif pour tout le monde.
Si d'autres développeurs travaillent sur une nouvelle chose écrite par une autre personne, ils devront passer un certain temps à la comprendre avant de pouvoir y apporter des modifications. L'utilisation du typage statique permet aux développeurs de gagner BEAUCOUP de temps à comprendre les valeurs des variables et le flux d'exécution.
Si le développeur qui a écrit ce code quitte l'entreprise/l'équipe, cela n'aura pas un impact aussi important qu'il l'aurait fait, car toute cette documentation se trouve directement sur le code. Facile à trouver et facile à comprendre.
Les développeurs doivent également moins s'appuyer sur la programmation en binôme pour pouvoir travailler sur un projet, s'il est bien tapé et suffisamment simple, ils pourront peut-être apporter des améliorations/modifications sans même parler à quelqu'un dans le projet, ce qui augmente de manière absurde. leur efficacité.
TypeScript est l'un des langages les plus appréciés, d'après l'enquête auprès des développeurs Stack Overflow, voici les résultats de 4 années consécutives :
2020 :
2021 :
2022 :
2023 :
JSDoc n'est pas présent dans l'enquête, donc je n'ai aucune sorte de données pour dire que c'est une bonne option. La seule chose que je peux dire, c'est que HTMX l'utilise, mais c'est une bibliothèque très simple.
D'un autre côté, nous pouvons dire que d'après cette enquête, les développeurs ont préféré TypeScript à JavaScript pendant la plupart des dernières années.
Vous n'avez pas besoin de tout taper. TypeScript et JSDoc peuvent deviner le type de la plupart des choses, ce qui le rend beaucoup plus facile et moins verbeux que d'autres langages comme Java ou C.
Pour TypeScript, dans le pire des cas, utilisez-en n'importe lequel. any est du type joker, il représente n'importe quoi, et pour cette raison vous devriez l'éviter à tout prix , mais si vous manquez de temps ou si vous ne voulez pas être bloqué par le manque d'un type, vous avez cette option.
Pour JSDoc, ne commentez simplement rien, c'est du pur JavaScript !
J'expliquerai plus en détail le pourquoi dans la section Il a une courbe d'apprentissage élevée, mais je donnerai quelques spoilers ici.
Les bases de code avec du code incompréhensible doivent être refactorisées, et les bases de code qui n'ont pas de documentation appropriée (que nous convenons qu'il est impossible de maintenir si elle est séparée du code) ont un plus grand nombre de sections impossible à comprendre sans beaucoup de recherche et de temps pour analyser.
Les refactors ne devraient pas se produire parce que votre code est impossible à comprendre, mais en raison de problèmes de performances ou de changements dans la logique métier. devoir faire deux fois la même chose est mauvais pour tout le monde : les développeurs, les utilisateurs et les investisseurs.
Il est courant que plusieurs personnes travaillent sur des projets de longue durée, et cela prend toujours un certain temps (à la fois pour le nouveau venu et les développeurs les plus expérimentés) pour que les nouveaux arrivants maîtrisent cette base de code.
Avec les types statiques, nous pouvons réduire BEAUCOUP le temps nécessaire, car les développeurs peuvent comprendre au moins les bases du code seuls et n'ont besoin de l'aide d'autres développeurs que pour comprendre une logique métier plus complexe (si elles ne sont pas documentées dans le code, mais c'est un sujet pour un autre article).
Cela facilite l'arrivée de nouveaux arrivants dans les projets, réduit considérablement leur courbe d'apprentissage et leur permet de travailler sur le projet avec moins de risque de casser quelque chose, augmentant ainsi l'efficacité de votre équipe dans son ensemble.
Le seul inconvénient de TypeScirpt est que son étape de construction est plus complexe (car soyons réalistes, de nos jours, TOUS les projets JavaScript ont déjà une étape de construction, donc cela ne fait que la rendre un peu plus complexe).
Vous aurez peut-être besoin de plugins ou d'adaptateurs appropriés pour intégrer votre processus de construction avec TypeScript, mais de nos jours, nous disposons d'un tas de bibliothèques, de plugins, d'outils et de tout ce dont vous avez besoin pour le faire fonctionner.
Je ne vais pas mentir, cela peut vous causer des ennuis la première fois, comme la plupart des autres outils de l'écosystème JavaScript, mais pas suffisamment pour dépasser les pros.
Si vous choisissez d'utiliser JSDoc au lieu de TypeScript, ce seul inconvénient de TypeScript a disparu, mais un nouveau apparaît : JSDoc ne fonctionne pas très bien avec des types plus complexes si vous n'utilisez pas de classes pour les représenter.
La saisie statique vous oblige à écrire quelques choses supplémentaires, mais la courbe d'apprentissage n'est pas liée à la chaîne supplémentaire que vous devez écrire, mais à à quel point il est difficile de travailler avec cette base de code.
Sans typage statique, vous avez besoin de BEAUCOUP plus de contexte pour comprendre ce qui se passe dans le code, quelles valeurs a une variable et quelle logique métier est appliquée.
Voyons un exemple :
function processOrders(orders) {
// Logic here
}
Avec seulement ces informations, pouvez-vous déterminer les valeurs des commandes ? Vous pouvez dire C'est un tableau !, mais devinez quoi ? Vous avez tort. les commandes sont un objet. Quelles propriétés possède-t-il ? Bonne chance pour passer au moins une minute à regarder le code pour le comprendre.
Les propriétés sont-elles facultatives ? Existent-ils toujours ? S'agit-il d'objets, de tableaux ou de chaînes ? Est-ce qu'un autre membre de votre équipe a cette connaissance ou la personne qui a écrit ce code est disparue depuis longtemps ?
La saisie statique à elle seule réduit la courbe d'apprentissage d'une quantité colossale.
Avec du JavaScript pur, chaque personne qui travaillerait sur quelque chose lié aux commandes de traitement devrait suivre le même processus :
Se demander ce qu'est une commande
Passer beaucoup de temps dans le processus de logique des commandes à essayer de le comprendre
Si cela nécessite un comportement spécifique de processOrders, demander probablement plus de détails aux autres membres de l'équipe et passer leur temps également
Mettons cela en chiffres, pour que ce soit plus amusant :
Une équipe de 5 personnes, chacune gagnant 100k$/an
Disons qu'ils doivent travailler avec les processOrders une fois tous les 6 mois, suffisamment de temps pour oublier des détails spécifiques
Ils passent 5 minutes pour comprendre TOUT ce dont ils ont besoin (Oui, je suis très, très optimiste ici)
Un projet a généralement des milliers ou au moins des centaines de fonctions, toutes similaires à processOrders, mais considérons ici seulement un petit projet, avec seulement 10 fonctions.
5 développeurs * 10 minutes/an * 10 fonctions = 500 minutes par an
Si chaque développeur gagne 88 cents par minute, Cela coûterait 440 $ seulement pour déterminer ce que les 10 fonctions reçoivent et renvoient. Il s'agit d'un temps improductif, qui ne génère aucune valeur, dans le MEILLEUR cas d'un scénario fictif où votre projet magique n'a que 10 fonctions, et non du monde réel où un projet en a des milliers de celles-ci.
Maintenant, avec TypeScript :
interface Orders {
ids: Array<number>
skipTypes?: Array<string> // Skip orders if they have specific types
}
interface ProcessedOrders {
total: number
success: number // Amount of orders that were succesfully
processed skipped: number // Amount of skipped orders based on input filters
}
function processOrders(orders: Orders): Promise<ProcessedOrders> {
// Logic here
}
Je sais que c'est une fonction terriblement peu intuitive, mais cela se produit dans le code. Cela ne devrait pas, mais c'est le cas, il est donc préférable de le documenter au moins.
Contrairement à la version JavaScript pure, vous avez ici tout le contexte dont vous avez besoin pour comprendre tout ce que la fonction reçoit et renvoie, que ce soit facultatif ou non, et le principe de base de ce que fait la fonction .
Après tout cela, vous pouvez encore argumenter sur beaucoup de choses, comme C'est un problème de code propre, pas un problème de JavaScript ! ou C'est un manque de documentation un problème, pas de JavaScript problème !, mais je vous assure que toutes ces choses sont des problèmes DIFFÉRENTS qui, oui, se produisent dans le code, que je peux aborder dans d'autres articles, mais qui ne sont pas au centre de celui-ci.
C'est la magie de TypeScript : vous n'avez pas besoin que vos bibliothèques prennent en charge TypeScript.
Vous pouvez utiliser la bibliothèque sans aucune saisie, et elle fonctionnera de la même manière, mais comme il sera plus difficile de travailler avec une bibliothèque JavaScript pure (car elle n'a aucun des avantages mentionnés dans cet article), vous devriez probablement envisager en utilisant un autre.
Oui. En tant que développeurs, nous devons apprendre quelque chose de nouveau chaque jour. cela fait partie de notre travail. Nous sommes ici pour créer des solutions techniques aux problèmes, être une référence et trouver comment résoudre les problèmes auxquels nous sommes confrontés.
Apprendre quelque chose de nouveau qui présente tant d'avantages est un effort qui en vaut la peine.
Après avoir su à quel point les outils de typage statique aident au développement, sans aucun inconvénient considérable, il n'y a aucun moyen de nier à quel point ils sont bénéfiques pour tout le monde : le développeur, les utilisateurs et les finances de l'entreprise.
J'espère que cet article vous aidera à le comprendre et à convaincre vos binômes d'améliorer vos expériences de développement.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
