Pourquoi il faut réinventer la roue

• Apprentissage
• Accompagnement

Voici un exercice que j’affectionne et propose souvent aux personnes que j’accompagne : re-coder les outils de développement que nous utilisons au quotidien : Jest, Redux, React, voire même TypeScript. À la réflexion, re-coder est un bien grand mot. Disons plutôt travailler le principe fondateur de ces outils, le gist.

Un framework de test en 20 lignes

Jest, par exemple. Un framework 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 moduler leur exécution (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, voire réaliser des assertions au travers de spys.

Le premier volet, le plus important à mes yeux, 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 à l’heure de l’apéritif, quand la semaine est finie. Chacun son fun, j’en ai bien conscience. Peut-être devrais-je reconsidérer certains aspects de ma vie…

Qui peut le plus peut le moins

Cet exercice est compliqué parce qu’il part de la page blanche et demande de poser un cadre ex-nihilo. Par contraste, la plupart des développements que nous faisons au quotidien s’inscrit dans un cadre pré-établi, par nous-mêmes ou par d’autres. Poser les bases d’un outil de gestion de l’état applicatif, d’un DOM virtuel et de l’algorithme de réconciliation qui va avec vous fera nécessairement gagner en hauteur de vue et en autonomie.

Et puisque le cadre n’existe pas, comment tester nos développements ? Ce type d’exercice est une exploration, nous n’allons pas nécessairement faire du Test-Driven Development (développer un test runner en TDD, ça peut faire mal à la tête 🤯). Pour autant, sans faire de TDD pur et dur, nous pouvons 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.

En passant, sur le cas précis du test runner, le besoin se fait tout de même sentir assez vite d’automatiser les tests de non-régression… et donc d’utiliser le test runner pour tester le test runner : « eat your own dog food! »

Réinventer pour mieux comprendre

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.

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.

Enfin, réinventer un outil permet de mieux en apprécier la valeur. Parfois, on hésite à utiliser une bibliothèque pour faire des choses qui restent simples. A titre d’exemple, je n’utilise aucune bibliothèque 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 cela, je le sais parce que les monades, je les fais à la main, mon cousin.

Ces exercices, assimilables à des kata, sont très formateurs. Et qui sait, peut-être donneront-ils naissance à de nouveaux outils (niveau « création » de la Taxonomie révisée de Bloom) ?