YAGNI

Cet article est une ébauche concernant l’informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

YAGNI (anglicisme, acronyme anglais de 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[1]. Ron Jeffries recommande par ailleurs : « mettez toujours en œuvre les choses quand vous en avez effectivement besoin, pas lorsque vous prévoyez simplement que vous en aurez besoin »[2].

Justification

Selon ceux qui prônent l'approche YAGNI, la tentation d'écrire du code qui n'est pas nécessaire à l'instant présent, mais qui pourrait l'être dans le futur, entraine les inconvénients suivants :

  • Le temps nécessaire est pris sur l'ajout, le test ou l'amélioration de fonctionnalités immédiatement nécessaires.
  • Les fonctionnalités supplémentaires doivent être debugguées, documentées, et entretenues.
  • Toute nouvelle fonctionnalité impose des contraintes sur ce qui peut être fait dans le futur, donc une fonctionnalité inutile pour l'instant risque la possibilité d'un conflit avec une future fonctionnalité nécessaire.
  • Tant que la fonctionnalité n'est pas réellement nécessaire, il est difficile de définir complètement ce qu'elle doit faire, et comment la tester. Si cette nouvelle fonctionnalité n'est pas correctement définie et testée, elle risque de ne pas fonctionner correctement lorsqu'elle sera un jour nécessaire.
  • Elle entraine l'écriture de code inutilement long, lent ou gaspillant des ressources. Le logiciel grossit et devient plus compliqué.
  • En l'absence de spécifications et d'un contrôle de version, la fonctionnalité peut être inconnue des programmeurs qui pourraient s'en servir.
  • Ajouter une nouvelle fonctionnalité peut suggérer d'autres nouveautés. Si ces fonctionnalités sont réalisées à leur tour, cela peut entrainer un effet boule de neige.

Critiques

Ce principe est souvent l'objet de débats entre programmeurs. En effet, l'ajout de certaines fonctionnalités particulièrement structurantes à un logiciel déjà existant peut, parfois, s’avérer excessivement complexe. Que la présence de cette fonctionnalité ait été anticipée dès la première version du logiciel peut donc, malgré un potentiel surcoût initial, s’avérer in fine bien moins couteux que si elle avait été totalement ignorée. Une analyse fonctionnalité par fonctionnalité est donc généralement nécessaire pour éviter les problèmes que pourrait engendrer une application trop naïve du principe YAGNI.

Notes et références

  1. (en) Lowell Lindstrom; Carmen Zannier; Erdogmus, Hakan, Extreme Programming and Agile Methods : XP/Agile Universe 2004 : 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15-18, etc. (Lecture Notes in Computer Science), Berlin, Springer, , 238 p. (ISBN 978-3-540-22839-4, lire en ligne), p. 121
  2. (en) Ron Jeffries, « You’re NOT gonna need it! » (consulté le )

Voir aussi

v · m
Gestion de la qualité logicielle
Indicateurs de qualité (ISO/CEI 9126)
  • Capacité fonctionnelle (réponse aux exigences)
  • Fiabilité
  • Maintenabilité
  • Performance
  • Portabilité
  • Utilisabilité
Compréhension et contrôle du code source
Tests
Métriques
Remaniements
Principes de programmation
SOLID
Mauvaises pratiques
Antipatterns
Code smells
Voir aussi : Génie logiciel, Érosion de l'architecture logicielle
  • icône décorative Portail de l’informatique
  • icône décorative Portail de la programmation informatique