Un développeur sachant développer…

Le doute tient chez moi une très grande place. Aussi, les aficionados du JavaScript pur (a.k.a. "Vanilla JS") m'ont longtemps fait douter. Comprenez les développeurs qui tiennent ce discours :

"Un bon développeur n'a pas besoin de TypeScript"

Permettez-moi, une fois n'est pas coutume, d'être un chouia incisif :

C'est totalement débile.

C'est tellement insensé que j'ai eu des doutes sur le sujet pendant des années. Eh bien oui, si des personnes soutiennent une telle opinion mordicus, c'est qu'elles doivent avoir des arguments forts et une vision du développement plus large que la mienne. Quelque chose doit m'échapper.

En fait, non.

Alors examinons les choses de plus près 🔎.

Il y a le classique "le typage c'est dur, donc je préfère faire du JavaScript". Ça a le mérite d'être honnête, mais ça me laisse inquiet sur la qualité du code produit.

En effet, si j'écris (en TypeScript) :

type WrappedNumber = {
  value: number;
};

const array: WrappedNumber[] = [
  { value: 0 }, //
  { value: 1 },
  { value: 3 },
];

const result = array.find(({ value }) => value === 2);

console.log(result.value);

Le compilateur va tout de suite indiquer ts(2532): Object is possibly 'undefined'.

Et à raison, puisque la methode Array.find() renvoie undefined si aucun élément du tableau ne satisfait le prédicat.

Pourquoi le compilateur agit-il ainsi ? Se dit-il : "Tiens, on va se marrer un peu et embêter Mathieu, histoire lui faire perdre 10 minutes de son précieux temps 😈" ?

Non. Le compilateur n'est pas là pour nous embêter mais plutôt pour révéler un problème qui existe, que l'on utilise ou non un système de typage. Dire "non" au compilateur, c'est un peu comme dire :

"La gravité ? J'aime pas trop ça, je vais faire sans".

Dit autrement, se passer de tout système de typage ne fait pas disparaître le problème. C'est seulement qu'il apparaîtra en production plutôt qu'en développement. C'est sûr que c'est mieux, ça aura le mérite de pourrir la vie des utilisateurs, et même de nous faire perdre de l'argent avec un peu de chance 👍.

Refuser d'écouter ce que le compilateur a à nous dire, c'est donc faire l'autruche.

Notez bien qu'on pourrait faire toutes ces vérifications à l'exécution et truffer notre code de if. Ce qui revient peu ou prou à écrire à la main un compilateur sous-optimisé. Y'a du Nobel dans l'air.

"Mais j'ai pas besoin de compilateur puisque je sais que .find() peut renvoyer undefined !"

Ah de mieux en mieux, donc là il s'agit carrément de faire la compilation de tête. Changez rien, les gars, z'êtes au top 👌.

Examinons le code suivant (JavaScript, cette fois-ci) :

const random = (min, max, generator) => {
  return min + (max - min) * generator();
};

random(1, 10, "generator");

Ce code, à l'exécution, produit l'erreur suivante : Uncaught TypeError: generator is not a function. Si j'avais voulu l'éviter j'aurais dû lire l'implémentation de la fonction pour savoir que ledit générateur doit être une fonction qui renvoie un nombre.

C'est ça, faire la compilation de tête.

Donc oui, le typage ça peut être dur. Mais "si ça fait mal, c'est que ça fait du bien", disait Jacques Rouxel (le père des Shadoks). En effet, je mets au défi quiconque de faire une vraie application d'ampleur en JavaScript pur. J'entends par là une application avec de vrais enjeux métier, des centaines de milliers de lignes de code et une équipe de développement constituée de plus de 1 développeur.

Quoique seul, on a déjà des problèmes sans typage…

Pour finir sur une note plus subtile et ouvrir un peu les chakras, quelqu'un pourrait dire "mais je fais des tests, donc je n'ai pas besoin de système de typage !"

Je ne l'ai jamais entendu, mais ça aurait du sens.

Sauf que les tests sont bien moins efficaces que le typage. Cette citation de Scott Wlaschin, grand nom du Domain-driven design et de la programmation fonctionnelle, nous en donne assez bien l'intuition :

Unit tests have been compared with shining a flashlight into a dark room in search of a monster. Shine the light into the room and then into all the scary corners. It doesn’t mean the room is monster free — just that the monster isn’t standing where you’ve shined your flashlight.

Si vous voulez aller plus loin sur le sujet, je ne peux que vous recommander cette excellente conférence de Julien Truffaut.

À la semaine prochaine 👋 !

PS : nouveau record personnel pour moi sur marathon dimanche dernier à Berlin, en 2h33'48'' (soit 42km à 16.5km/h). Ne cherchez pas, ça n'a absolument rien à voir avec le reste. Mais je fais ce que je veux, c'est ma newsletter 😁