Architecture logicielle & Développement

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ù".