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

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.

Voir aussi

• Principe KISS
• Ne vous répétez pas
• Méthode MoSCoW
• Extreme programming