Le principe YAGNI dans le développement de logiciels : Avez-vous vraiment besoin de cette abstraction ou de ce code générique ?

Qu'est-ce que YAGNI? Ne construisez pas ce dont vous n'aurez pas besoin

Au cœur de cette discussion se trouve le principe YAGNI, qui signifie You Aren't Gonna Need It (Vous n'en aurez pas besoin), un concept clé de l'Extreme Programming et du développement logiciel allégé. Comme l'explique Derek, YAGNI indique aux développeurs de ne pas mettre en œuvre des caractéristiques ou des fonctionnalités dont ils pensent avoir besoin à l'avenir, mais plutôt de se concentrer sur les besoins actuels.

Derek ajoute une nuance : s'il faut éviter d'écrire du code spéculatif, il ne faut pas non plus se priver de s'adapter ultérieurement. Le défi est d'éviter de passer du temps sur des fonctionnalités qui pourraient être utiles tout en restant ouvert au changement. Il s'agit d'un dilemme courant dans le domaine des logiciels agiles et de l'ingénierie logicielle.

Il décrit deux mauvaises applications courantes de YAGNI :

1. Planification des fonctionnalités - Vous anticipez les besoins futurs et commencez à construire dès maintenant.

2. Abstractions de code - Vous généralisez ou abstrayez le code existant trop tôt, en devinant les autres fonctionnalités qui pourraient être nécessaires.

Dans les deux cas, le résultat est généralement un gaspillage d'efforts, une complexité accrue et une multiplication des fonctionnalités, soit exactement le contraire de ce que préconisent les bonnes pratiques et le principe KISS (Keep It Simple, Stupid).

Un exemple concret : Système de notification d'expédition

Pour illustrer son propos, Derek prend l'exemple d'un système de gestion des expéditions qui envoie un SMS à un utilisateur une fois son colis livré. Le système utilise Twilio, et la fonctionnalité fonctionne en gérant un événement de livraison, en récupérant les informations de contact et en envoyant un message.

Ce processus de développement de code simple répond à l'exigence actuelle. Il s'agit d'une traduction simple, testable et qui apporte de la valeur. Mais une question se pose alors : Qu'en est-il si nous voulons changer de fournisseur de SMS à l'avenir?

C'est ici que de nombreux développeurs invoquent à tort le principe de YAGNI. Ils partent du principe que, puisqu'une autre implémentation pourrait venir plus tard, ils ont besoin d'abstraire la logique SMS maintenant. Ils créent donc une interface comme ISmsService.

Abstractions : Construisez-vous pour un avenir qui n'existera peut-être pas ?

Derek remet en question cette abstraction précoce : s'il n'y a qu'une seule implémentation et qu'il n'est pas nécessaire de changer de fournisseur, pourquoi faire une abstraction ? Vous ajoutez une complexité inutile pour vous faciliter la vie dans le cadre d'un besoin futur qui ne se matérialisera peut-être jamais.

Il va plus loin en illustrant le coût de l'ingénierie logicielle. Lorsque vous finissez par ajouter un deuxième fournisseur, vous vous rendez compte que votre interface est trop étroitement liée aux besoins spécifiques de Twilio (comme sa logique de numéro de téléphone "from"). Soudain, l'abstraction devient un handicap. C'est ainsi que les abstractions construites sur des connaissances limitées introduisent souvent des bogues et compliquent le remaniement.

Ce qu'il faut retenir : vous ne gagnez pas de temps, vous construisez quelque chose de faux en raison d'un contexte insuffisant.

Passer au générique trop tôt : Un piège pour les développeurs

L'une des violations de YAGNI les plus courantes dans les projets informatiques est la tendance à rendre les choses génériques avant qu'elles n'aient besoin de l'être. Derek explore ce sujet à travers un autre exemple : le regroupement des notifications par SMS et par e-mail en un seul système de notification générique.

Pour ce faire, un développeur peut définir un type de notification (SMS ou courriel), un champ d'adresse universel et créer un service unique qui gère les deux. Mais cette conception trop abstraite finit par compliquer la logique et créer des chemins de code conditionnels qui sont fragiles et difficiles à maintenir.

Il s'agit là d'une dérive classique et d'une caractéristique de l'ignorance du développement de logiciels allégés et de principes solides. Vous écrivez du code spéculatif qui ne répond à aucun besoin immédiat de l'utilisateur - un signal d'alarme dans tout processus de développement logiciel agile.

Préférer l'extension à la modification

Plutôt que de faire de l'ingénierie à outrance, Derek suggère d'opter pour la solution la plus simple : si vous devez ultérieurement prendre en charge les notifications par courrier électronique, il vous suffit d'implémenter cette fonctionnalité séparément.

Grâce à une architecture pilotée par les événements, chaque événement peut déclencher plusieurs gestionnaires indépendants. Par exemple, un gestionnaire pour les SMS et un autre pour les courriels. Il est possible de supprimer ultérieurement l'une des deux traductions sans affecter l'autre. Cette méthode favorise la simplicité, prend en charge les changements d'exigences et respecte la séparation des préoccupations, ce qui est conforme aux meilleures pratiques de développement agile et piloté par les tests.

En construisant des systèmes qui sont extensibles, et non surconçus, vous conservez une certaine flexibilité sans prédire tous les futurs possibles. C'est ainsi que l'on évite toute complexité inutile et que l'on reste adaptable.

Le coût réel de la violation de YAGNI

Derek met en évidence le coût réel de la création de fonctionnalités inutiles :

• Temps passé à construire quelque chose que vous n'utiliserez jamais

• Une complexité accrue qui n'apporte pas de valeur immédiate

• Augmentation des coûts de propriété pour les développeurs qui doivent maintenant maintenir du code inutilisé ou surconstruit

• Plus de place pour les bogues et les erreurs dues à une ingénierie trop poussée

Cette démarche s'aligne sur un autre principe fondamental du développement agile de logiciels : se concentrer sur la fourniture de valeur maintenant, et non pas éventuellement plus tard.

Il note que les développeurs expérimentés commettent souvent l'erreur de se fier à leur instinct quant aux besoins futurs, et qu'ils se trompent. Même avec de l'expérience, prévoir ce dont votre système aura besoin dans plusieurs mois est souvent un jeu perdu d'avance.

Réflexions finales : Le contexte compte, la simplicité l'emporte

Derek conclut en précisant qu'il n'est pas opposé aux principes de conception ou aux abstractions. En fait, il croit en la construction de systèmes capables d'évoluer. Mais l'erreur consiste à mettre en œuvre des éléments sans justification actuelle, ce qui revient à enfreindre le principe YAGNI.

Il encourage les développeurs à "écrire du code et à mettre en œuvre des fonctionnalités qui ont une valeur immédiate" Évitez de chercher à satisfaire des besoins futurs au détriment de vos utilisateurs actuels. Respectez les pratiques de code propre et privilégiez les stratégies de conception qui prennent en charge le changement sans vous enfermer dans des structures spéculatives.

Il invite également les développeurs à partager leurs propres histoires d'horreur YAGNI, où ils ont construit pour l'avenir et n'en ont jamais eu besoin - une histoire courante dans de nombreux projets.

Conclusion : Appliquez YAGNI à votre processus de développement

Le principe de YAGNI reste l'un des outils les plus précieux dans la boîte à outils d'un développeur. Elle s'aligne sur les philosophies agile, lean et KISS, en nous rappelant de ne construire que ce qui est nécessaire, rien de plus. L'analyse de cette idée par Derek Comartin dans sa vidéo, à l'aide d'exemples concrets de code et de processus de développement, offre des conseils clairs sur la manière d'appliquer YAGNI de manière efficace.

Ainsi, la prochaine fois que vous serez tenté d'ajouter une couche d'abstraction, une classe générique ou une fonctionnalité supplémentaire, faites une pause et posez-vous la question :

Résolvez-vous un problème que vous avez ou que vous pensez avoir un jour ?

Évitez de passer du temps sur des futurs imaginaires. Concentrez-vous sur la création de valeur dès aujourd'hui. Veillez à ce que vos logiciels soient simples, faciles à entretenir et adaptés aux besoins réels.

Parce qu'il y a de fortes chances que vous n'en ayez pas besoin.