Accueil🇫🇷Chercher

YAGNI

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].

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.

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.

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

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.