20 juil. 2006

YAGNI !

YAGNI par ci, YAGNI par là, YAGNI, YAGNI, YAGNI.

Parmi la multitude de conseils pouvant être donnés en réponse à une question concernant l'architecture logicielle, YAGNI est probablement le plus courant des résultats obtenus. Souvent, sans aucune forme d'explication, la réponse se résout même à cette simple interjection : YAGNI !

Que signifie YAGNI exactement ? Il s'agit d'un acronyme anglais signifiant "You Ain't Gonna Need It" ; en français, celà donne "tu ne vas pas en avoir besoin". YAGNI n'est pas un principe d'architecture mais une bonne pratique, qui consiste à ne pas essayer de prévoir ce qui de toute façon ne sera jamais utilisé par la suite. Ne pas suivre cette pratique a trois conséquences principales:

  • l'architecture logicielle est alourdie par des fonctions non désirées et non utilisées, ce qui peut mener à son pourrissement.
  • puisque le nombre de bugs probable augmente au moins en proportion du nombre de ligne de code, rajouter des élements non nécessaires va obligatoirement ralonger la liste des bugs.
  • le temps de développement est ralongé d'autant, puisque rajouter une fonction necessite aussi de la développer, de la documenter et de la tester. Le temps alloué au projet diminue d'autant plus vite que le nombre de fonctions inutiles augmente.

YAGNI et les problèmes associés a émergé grace à la méthode XP (Xtreme Programming), qui propose un ensemble de bonnes pratiques à suivre pour rendre plus aisé le développement d'applications. Le sens originel de YAGNI est le suivant:

Always implement things when you actually need them, never when you just foresee that you need them.

Ce qui pourrait se traduire par : toujours implémenter les fonctions lorsque vous en avez le besoin, jamais lorsque vous prévoyez d'en avoir un jour le besoin. c2.com, l'un des sites référence à propos de XP nous apprends par ailleurs que YAGNI a été dérivé des paroles d'une des chansons de l'opéra rock Tommy.

Curieusement, la pratique de ne développer quelque chose que lorsqu'on est sure de son utilité semble en contradiction avec les besoins d'un cycle en V, où la phase d'architecture intervient avant la phase de programmation. Ce n'est pas tout à fait faux, mais YAGNI peut aussi être adapté à la phase d'architecture elle même, le but étant de répondre au plus tôt au cahier des charges et de ne pas se perdre dans les méandres d'une architecture lourde, onéreuse, dans le seul but d'être complet et ouvert. Le temps passé à concevoir une solution à un problème n'existant pas est du temps perdu, qui aurait pu être consacré à la conception d'une autre fonction correctement spécifiée.

Specifications et YAGNI sont liés. Souvent, le manque de spécification conduit l'architecte à introduire des solutions trop génériques dont seule une infime partie aura véritablement un intérêt au niveau projet. L'un des exemples les plus communément utilisé simule le dialogue de deux ingénieurs. L'un voit que les specifications nécessitent la sauvegarde et la relecture ultérieure du contenu d'un zone de saisie, et dans le doute, commence à concevoir un système générique de gestion des objets persistants. L'autre lui objecte : "YAGNI ! Tu écris directement dans un fichier texte basique que tu relis ensuite. Pour ta solution, on verra si on en a besoin, mais pas maintenant". C'est d'ailleurs l'un des points qui fait que le dialogue entre l'architecte et celui qui spécifie doit être constant, afin de préciser ce qui doit l'être dans le but d'éviter une solution over-engineered (trop d'architecture) dont on sait qu'elle sont au moins autant dommageable à un projet qu'une solution under-engineered (manque d'architecture).

Bien evidemment, il est difficile de se restreindre - que ce soit au moment de la programmation comme au moment de la conception. Résoudre un problème implique une démarche créative qui peut avoir un effet boule de neige sur la conception - la conception d'un élément entrainant la création d'un autre, et ainsi de suite. Sans s'en rendre compte, on arrive vite à une solution générique mais trop complexe comparée au problème initial. YAGNI nécessite donc de la rigueur et de la discipline dans la recherche de la solution la plus simple. Qui plus est, il est toujours possible de revenir sur le modèle après coup si le besoin de généralisation est évident - ce que la méthodologie XP appelle le refactoring.

En guise de conclusion, pour paraphraser l'excellent article de Charles Miller, Defending YAGNI :

  • je peux concevoir une solution dès maintenant ou le faire plus tard
  • si je le fait maintenant, celà va me prendre X jours
  • si je le fait plus tard, celà necessitera Y jours
  • je n'en ai pas besoin maintenant
  • Ces X jours peuvent être utilisés pour travailler sur quelque chose dont j'ai besoin maintenant
  • Ou alors, ces X jours sont autant de jours gagnés pour délivrer mon produit plus tôt, si je n'étais pas occupé à faire quelque chose dont je n'ai pas besoin
  • si je le fait maintenant et que je me rends compte ensuite que je n'en ai pas besoin, j'ai perdu X jours
  • si je ne le fait pas maintenant et que j'en ai besoin, je ne perd que Y-X jours
  • de plus, le code non utilisé ou le code complexe du à des fonctions qui ne sont pas encore réalisée
    • est une source potentielle de bugs
    • ralentit le developpement
    • rend plus difficile la maintenance

A bien y reflechir, toujours selon Miller, YAGNI nous dit que trop souvent nous surestimons la différence entre X et Y et que nous surestimons aussi la probabilité que la solution conçue soit utilisée plus tard. Le but de YAGNI est donc de nous protéger en tant qu'architectes logiciels, afin de nous éviter de perdre notre temps à concevoir des solutions "au cas où".

Commentaires

1. Le jeudi, juillet 20 2006, 22:27 par Christophe Moustier
Le YAGNI est le contre-pied de l'anticipation. Le cycle en cascade (ou en V) est la conséquence de cette anticipation. On a tous appris que plus la correction d'un défaut était prise en amont, mois cela coûtait cher ; cependant, K. Beck, dans son exposé d'XP précise que ce surcoût est en fait plafonné.
Il appuie aussi sa thèse du "faire quand on en a besoin" en expliquant que 2 semaines pour anticiper un besoin 6 mois en avance aura coûté bien au-delà de 2 semaines d'énergie, car l'usure (celle du banquier, pas du vêtement !) fait qu'en 6 mois, ces 2 semaines auront été valorisés ; et pour peu que l'anticipation soit fausse, c'est plus de 2 semaines d'énergie qui auront été gaspillées.

Cette notion de YAGNI est connexe à la Loi de Pareto. Cette loi "montre" que 80% de l'effort est nécessaire pour réaliser les derniers 20%.
Ces éléments font qu'il est souvent vain de pousser une réalisation jusqu'au bout. C'est ce que vient freiner les développements aux cycles itératifs courts (moins de 8 semaines par itération). En ce sens, j'y trouve une contradiction dans ton paragraphe "semble en contradiction avec les besoins d'un cycle itératif"...

Par ailleurs, tu ajoutes "où la phase d'architecture intervient avant la phase de programmation" et tu mélanges les choux, les chèvres, le loup, etc. En effet, tu peux réaliser plusieurs itérations sur une phase architecturale : le VRAI point marquant du cycle itératif est de LIVRER au client en mettant en oeuvre toute l'énergie nécessaire à une livraison en temps voulu.

Voila...
2. Le jeudi, juillet 20 2006, 23:55 par Emmanuel Deloget

Ah ! Je savais que ta sagacité ne laisserait pas passer une erreur aussi grossière. Bien évidemment, je ne vouslais pas parler de cycle itératif (la phrase n'aurait alors pas beaucoup de sens) mais d'un cycle en V - ce qui me parrait plus sensé. Je corrige immédiatement.

A ma décharge, j'ai écrit ça alors que j'étais en pleine cogitation sur les besoins d'un client potentiel (RUP, cycle itératif, tout ça). Les mots ont glissé tout seul...

E.

3. Le vendredi, septembre 22 2006, 15:29 par Stéphane MORAT

« Le YAGNI est le contre-pied de l'anticipation. »
Pour moi, le YAGNY n’est pas le contre-pied de l’anticipation. C’est un des postula qui permet de justifier l’utilisation de XP comme méthode de développement.

Je pense que la méthodologie XP qui met le développeur au centre du développement, est très utile pour les projets de petites tailles ou les environnements et les technologies changent rapidement et elle s’adapte particulièrement bien aux projets Web. Le refactoring préconisé dans cette méthodologie n’utilise que des patterns niveau conception (design) mais non architecturaux.
Pour ces projets, pas besoin d’architecte logiciel, ou il faudrait définir ce qu’est un architecte.

« Le cycle en cascade (ou en V) est la conséquence de cette anticipation. »
Le cycle en cascade englobe tout les phases du développement logiciel. Il n’a aucun but d’anticipation. Il permet d’effectuer des contrôles stricts à la fin de chaque phase du processus. La conception préliminaire n’a pour but que de satisfaite à la réalisation d’une architecture qui recouvre toutes les exigences. Au contraire, elle ne doit rien anticiper mais juste satisfaire aux exigences. Le principale défaut du cycle en V, à mon sens, est d’être piloté par les exigences fonctionnels et non par les cas d’utilisation.

Le RUP (ou autre processus équivalents), piloté par les cas d’utilisation, est un processus itératif. Il présente une phase d’Elaboration qui permet de définir le modèle de données, ainsi que l’architecture générale de l’application avec en particulier la définition des flots de données, ceci à l’aide d’outils de modélisation. C’est un processus vers lequel les industries se tournent de plus en plus, car, en plus de définir une architecture pérenne, il est centré sur la gestion des risques.

« Cette loi "montre" que 80% de l'effort est nécessaire pour réaliser les derniers 20%»
C’est une loi empirique fondé sur l’observation.
Définition d’empirique : Qui ne s’attache qu’à l’expérience, sans suivre les méthodes, les principes scientifiques.
C’est justement pour échapper à cette loi que nous définissons des méthodes.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet