Parce que la forme est contraignante, l'idée jaillit plus intense

[Rediffusion d'un article originellement publié le 23 novembre 2022]

Promis, on va parler de programmation.

Mais avant, laissons-nous porter par cette œuvre du peintre expressionniste Franz Marc (1). Il est intéressant de constater à quel point le style de l'artiste s'est affirmé en quelques années seulement, avec l'introduction d'un formalisme strict qui emprunte au futurisme. Comparez ce tableau à ses premières œuvres, le contraste est flagrant.

Le formalisme, c'est la contrainte : pourquoi vouloir se contraindre ?

La réponse nous est soufflée par Charles Baudelaire : "parce que la forme est contraignante, l'idée jaillit plus intense !" Autrement dit, la créativité naît de la contrainte, qui est un point d'accroche pour vaincre la page blanche. Créer le cadre pour en sortir. C'est vrai de la peinture, de la musique et de l'art en général.

Eh bien le code, c'est tout pareil 😊

Les développeurs ont pour habitude de faire des kata de code. Le mot n'est pas innocemment emprunté aux arts martiaux, puisqu'il s'agit bien de valeurs auxquelles adhèrent les artisans du logiciel.

Les kata sont des exercices codifiés que l'on fait et refait à l'infini. La beauté de la chose est que la personne la plus gradée (ceinture noire nième dan) s'exerce sur les mêmes kata que le débutant, reconnaissant humblement que l'on n'a jamais fini d'apprendre.

Ainsi, enchaîner les kata comme on coche des cases n'aurait aucun sens. Il faut au contraire y revenir périodiquement, en premier lieu parce que c'est l'occasion de constater les progrès accomplis depuis la dernière fois.

Mais parfois, c'est l'inverse qui se produit : on se prend les pieds dans le tapis sans l'avoir vu venir et l'on échoue sur un kata censé être simple. C'est peut-être un peu vexant, mais c'est là qu'on apprend, car on revient à l'essence des choses.

C'est particulièrement vrai du TDD (Test-driven development) : allez, c'est bon on va pas vérifier que le test échoue, c'est évident donc on avance. Le truc à pas faire, sauf qu'il faut l'avoir fait pour savoir qu'il ne faut pas le faire 😁

Mais l'essentiel — et c'est là qu'on reboucle avec l'ami Franz Marc — refaire un kata, c'est souvent l'occasion d'expérimenter autre chose, de prendre des risques, de travailler sous contrainte et de s'amuser un peu.

Voici quelques approches que j'affectionne :

• Coder à l'aide du seul clavier, sans toucher au trackpad ni à la souris : une bonne façon de se familiariser avec son IDE ;
• Varier les paradigmes (fonctionnel/objet), sur le kata Tennis par exemple ;
• Varier les implémentations (boucle for/reduce/récursivité) : les kata ATM et Diamond s'y prêtent particulièrement bien ;
• Aller plus loin sur un kata : le kata Fraction pour le defensive programming, RPN pour la gestion d'erreurs avec des monades ou bien encore FizzBuzz pour une exploration des functors (OK, une exploration qui va peut-être trop loin) ;
• Optimiser les performances : Game of Life s'y prête bien ;
• Et plus généralement refactorer une précédente implémentation d'un kata.

L'intérêt de ces explorations est que le savoir acquis vous sert ensuite au quotidien lors de l'écriture de code de production : tout ça n'est pas que pour le plaisir intellectuel.

(1) En passant, ce tableau possède une histoire pour le moins mouvementée.