Le meilleur code

est celui dont on peut se passer

J’aime bien cette citation

“Le meilleur code est celui dont on peut se passer.”
Le type qui va maintenir votre code

C’est la clé d’une réalité difficile à accepter et encore plus à prouver : un bon développeur peut être 100 fois plus productif qu’un mauvais.

Dans l’évolution d’un programmer python:

  • Le débutant écrit une implémentation naïve,
  • Celui qui connait le langage résout le problème en une ligne simple,
  • L’expert utilise tout simplement une librairie déjà existante.

Mais il manque un type de développeur: celui qui trouve la solution pour ne pas avoir à écrire ce code.

Illustration avec le Kata du game of life

Lors du code retreat de ce week-end la 3eme itération avec piwai m’a permis  de trouver une illustration simple et concrète de ce précepte. (PRO tip: le pair programming est un moyen pour fabriquer des développeurs 10 fois plus productif à partir de deux développeurs normaux)
Le kata classique d’une code retreat est le game of life, la spec tien en 4 règles:

  1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any live cell with more than three live neighbours dies, as if by overcrowding.
  4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

Chaque itération dure 45min, en pratique il est difficile de finir dans ce temps, ce qui tombe bien car le but d’un kata n’est pas de finir mais d’expérimenter librement. Dans une approche TDD naïve on va commencer par implémenter un test permettant de valider la première règle, puis implémenter le code permettant qui permet de faire passer le test.

Mais TDD ne veut pas pire pas de conception, bien au contraire, la première question à se poser est qu’est qu’on doit tester?

Dans le cas du game of life on réalise très vite qu’on à besoin de stocker l’état des cellules dans 2 structures, une pour la génération actuelle, une autre pour la suivante. Si l’on démarre toujours la génération suivante par une structure vide que l’on va remplir en parcourant la structure actuelle il n’est pas nécessaire d’identifier les cellules à tuer: elles sont déjà toutes mortes dans la prochaine génération. Ce qui permet de ne pas se soucier de 2 règles sur 4.

Ainsi

  1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any live cell with more than three live neighbours dies, as if by overcrowding.
  4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
Devient
  1. All cell are dead in the next generation
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
La complexité du problème a été divisée par deux…
En partant sur ces bases on a pu finir de manière relativement élégante en 30 min.