Pourquoi il faut réinventer l'eau chaude

Récemment, j'ai proposé à des personnes que je coache de re-coder les outils de travail qu'ils utilisent au quotidien : Jest, React, voire même TypeScript.

Ô, re-coder, c'est un bien grand mot. Disons plutôt travailler le principe fondateur de ces outils. Le "gist", comme on dit sur GitHub.

Jest, par exemple. Une librairie de test qui assure en fait 3 fonctions distinctes :

• L'exécution de scénarios de test, avec des fonctionnalités bien pratiques telles que grouper des tests (describe) et les cibler (skip/only).
• La réalisation d'assertions, avec une interface en langage naturel très agréable : expect(actual).toEqual(expected).
• La capacité à mocker les dépendances (ou pas, la programmation fonctionnelle permet de s'en passer), voire réaliser des assertions au travers de mocks espions.

Le premier volet est ce que l'on appelle un test runner. Implémenter un test runner suppose de pouvoir enregistrer des scénarios de test dans une liste, en tant que fonctions, puis de les jouer les uns après les autres. Autrement dit : invoquer ces fonctions.

Donc à bien y regarder, rien de très compliqué. En 20 lignes de code, on a un test runner rudimentaire (https://github.com/mathieueveillard/jest-gist).

Quel est l'intérêt ?

Le fun ! Rien de mieux pour se détendre le vendredi soir quand la semaine est finie, à l'heure de l'apéritif. Chacun son fun, j'en ai bien conscience^*.

Non, au-delà, cela permet de désacraliser des outils qui, parfois, nous semblent un peu magiques. Or, à bien y regarder, il n'y a rien d'extraordinaire : on fait de l'informatique de gestion, on n'envoie pas des gens sur la Lune. La difficulté de nos métiers provient surtout de la nécessité de créer du code à l'échelle, autrement dit de travailler efficacement à plusieurs. Jest, React et TypeScript répondent tous trois à cet objectif.

Cet exercice se rapproche des small scale simulations évoquées par C. Martraire dans "Living Documentation: Continuous Knowledge Sharing by Design" : une version simplifiée d'un système complexe, issue d'un démonstrateur technique ou bien créée a posteriori dans le but de faciliter la compréhension dudit système.

Réinventer un outil permet aussi de mieux en percevoir la valeur ajoutée. Parfois, on hésite à utiliser une librairie pour faire des choses qui restent simples. A titre d'exemple, je n'utilise aucune librairie pour la programmation fonctionnelle : ni Ramda, ni fp-ts, ni Lodash. Leur valeur ajoutée me semble trop faible au regard des contraintes qu'elles apportent. Et ça, je le sais parce que les monades, je les fais à la main mon cousin.

Enfin, ce type d'exercice est avant tout une exploration, pour laquelle on ne va pas nécessairement faire du Test-driven development : coder Jest en TDD, je reconnais que ça peut faire mal à la tête 🤯 La nature de ce travail est exploratoire et relève plus d'un démonstrateur technique. Pour autant, sans faire de TDD pur et dur, on peut en extraire des éléments de méthode : identifier les axes de complexité, les considérer les uns après les autres, et surtout, surtout, faire des baby steps.

Car oui, c'est bien contre ça que lutte le TDD : cet indécrottable optimisme qui nous fait coder, coder, coder, parce que oui bien sûr ça va marcher, coder, coder, ho ho oui c'est trop bien je suis le maître du Monde, coder, coder et allez je teste et…

Ô miracle ! Ça marche pas.

Et là, bon courage pour debugger.

* Il faudrait peut-être que je revoie certains aspects de ma vie.