Pas de bon code sans itération

En latin, le verbe iterare était notamment utilisé dans l'agriculture pour exprimer le fait de labourer un champ une seconde fois, afin d'améliorer la qualité du sol. 🌱

C'est de là que vient le mot itération. 🔁

Dans le développement logiciel, les itérations, on connaît un peu. Et, par un étrange parallèle, elles permettent aussi d'améliorer la qualité du code. 💻

L'agriculteur ne va pas apporter de la nouvelle terre pour améliorer son champ : il doit faire avec celle qui est là.

Dans le logiciel, pour améliorer un code, la tentation de le ré-écrire est toujours présente. C'est généralement une erreur. Le code existant sait des choses dont il faut tirer profit. On ne peut pas le casser et espérer construire mieux par dessus. 💥

Le parallel change pousse la démarche itérative encore plus loin : il faut conserver l'ancien code et le nouveau côte à côte tant que le nouveau n'est pas prêt à prendre entièrement la place. Guillaume Saint-Etienne l'explique très bien même s'il préfère les analogies du BTP à celles de l'agriculture.

Cette technique des changements en parallèle est fondamentale lorsque le code est organisé pour du Trunk Based Development. Elle est notamment obligatoire pour une des techniques essentielles du TBD, les branches par l'abstraction.

En fait, cette présence de deux implémentation côte à côte est ce qui remplace très avantageusement l'utilisation des branches d'un gestionnaire de code. Plutôt que d'utiliser un outil externe, on apprend à organiser son code pour que plusieurs versions cohabitent pendant le temps du changement.

Les branches d'un gestionnaire de code, c'est la négation de la démarche itérative. On minimise le code existant car on se focalise sur le nouveau code que l'on écrit. On se permet de détruire ce code existant car il est toujours présent dans l'autre branche, que l'on s'empresse d'oublier le plus rapidement possible.

Beaucoup de gens pensent que l'on va plus vite comme ça. Et c'est certain. On va toujours plus vite pour écrire du nouveau code quand on met tout en oeuvre pour éviter de lire celui qui était déjà là. 🚀

J'ai remarqué cette préférence qu'ont les développeurs pour écrire du code plutôt que pour lire du code - surtout s'ils n'ont pas écrit le code à lire. Comment voulez-vous itérer dans ces conditions ?

Une des choses les plus difficiles à faire pour apprendre à bien coder c'est d'aimer vivre avec le code que l'on n'a pas écrit, aimer le changer pour l'améliorer. ❤️

"Embrace Change" disait, en sous-titre, le premier livre sur Extreme Programming. Paru en 1999, c'était un des premiers livres sur le développement agile de logiciels, avant même que le terme existe.

Cette mise en avant du changement, de l'itération à partir de l'existant, pour améliorer un logiciel est l'idée clef qui m'a fait aimer les méthodes agiles. Malgré le temps qui passe, c'est une idée qui semble toujours aussi difficile à faire comprendre. 🔑