« You Ain’t Gonna Need It » qui peut se traduire par « vous n’en aurez pas besoin » est un principe d’extreme programming qui déclare que les programmeurs ne devraient pas ajouter de fonctionnalité à un logiciel tant que celle-ci n’est pas absolument nécessaire.

Il y a quelques temps, je suis retombé sur un article qui parlait de l’Extreme Programming sur le site de IONOS. C’était une pratique à la mode il y a quelques années et qui a marqué toute une génération de développeurs. L’article est ici : Extreme Programming | Principes, Techniques, Avantages et Inconvénients – IONOS . Il commence par rappeler de quoi il s’agit :

L’extreme programming (XP) est considéré – d’où son nom – comme la mise en œuvre la plus radicale du développement agile de logiciels. En d’autres termes : il n’existe probablement pas de méthode plus agile que XP par rapport aux modes de programmation traditionnels. L’extreme programming se démarque donc concrètement aussi du modèle en cascade par exemple, qui présente de nombreux problèmes d’après les inventeurs de XP. Au milieu des années 1990, les développeurs Kent Beck, Ward Cunningham et Ron Jeffries ont décidé de bouleverser la méthode de travail classique et de suivre une autre route.

Même si son nom peut faire peur, l’XP s’appuie sur 5 principes fondamentaux très concrets et très réalistes pour conduire avec succès des projets de développement : Communication, Simplicité, Courage, Feedback, et Respect.

Parmi eux, le principe de simplicité est le plus cool car il est à la fois très « clean », très simple et tout à fait agréable à mettre en œuvre : il fait appel à notre paresse.

Face à un besoin, il s’agit d’en faire le moins possible ! De la paresse intelligente quand même, car il s’agit d’en faire le moins possible, mais de ne rien oublier. A la trappe les bouts de codes « au cas où un jour on veut faire ça », tout en essayant de prévoir tous les cas possibles nécessaires à l’instant T, par exemple tous les cas d’erreur.

Ca me rappelle un vrai exemple dans mon ancienne agence web : sur un projet qui utilisait MySql, un jour un gars de l’équipe m’a dit « regarde, j’ai créé des fonctions d’abstraction pour tous mes appels SQL, comme ça si un jour on veut changer de base de données… ». Que de temps perdu sur le projet d’un client qui ne nous avait jamais parlé de changer un jour de SGBD !

Avec l’XP, l’objectif est toujours la solution la plus simple. Cela comporte plusieurs avantages : en ne se concentrant que sur les besoins requis, on ne perd pas de temps avec des considérations insignifiantes. Cela implique également de ne développer que les caractéristiques nécessaires à l’instant T, sans préparer en amont d’éventuelles exigences futures. L’équipe accélère ainsi le développement. Un code ou un schéma de données épurés sont par ailleurs nettement plus simples à gérer, que ce soit au niveau du perfectionnement ou des travaux de maintenance. De plus, un code simplifié facilite la compréhension, ce qui va également dans le sens de la valeur. Enfin, il est toujours plus facile de tester du code qui va servir tout de suite car il s’insère dans un environnement qui est probablement prêt pour l’utiliser en condition réelle.