YAGNI signifie que les choses se font quand elles doivent être faites et pas avant. Cela ne signifie pas qu'ils ne sont jamais faits, sauf s'ils ne sont jamais nécessaires. Cela signifie que vous ne faites que ce qui donne au client une valeur commerciale immédiate . Ce que signifie la valeur commerciale immédiate est subjectif pour chaque client et chaque projet.
Dans les deux cas, vous ne pouvez rien perdre avec YAGNI.
Dans l'autre cas, vous perdez du temps à écrire du code qui ne sera jamais utilisé, à écrire des tests pour du code qui ne sera jamais utilisé, et à écrire de la documentation pour du code qui ne sera jamais utilisé, et de la maintenance sur du code qui ne sera jamais utilisé, les gens se demandant ce que fait ce code , et si jamais il est utilisé, ad nauseum.
Exemple
Si je travaille sur un prototype / preuve de concept ou une version 1.0 d'une application, je n'ai pas besoin d'une conception à l'échelle du niveau de Facebook. L' enfer , je ne ai pas besoin d' une conception à l' échelle au niveau de Facebook, jusqu'à ce que je commence à voir que j'ai ce genre de trafic.
Pensez-vous que Zuckerberg a conçu la toute première version de Facebook pour s'adapter à 500 millions d'utilisateurs? Non, il l'a conçu et construit pour faire ce qu'il voulait et pas plus. S'il avait essayé de créer un design en cascade pour 500 millions d'utilisateurs dès le premier jour, Facebook n'aurait probablement jamais été publié.
La façon pratique de faire les choses est de savoir comment il l'a fait. Il a commencé avec PHP et MySQL, et le remaniement et la réécriture selon les besoins en fonction de la valeur commerciale , l'adaptation à des millions d'utilisateurs était d'une valeur commerciale énorme, mais pas au jour 0. Au jour 0, le lancement de quelque chose était la valeur commerciale énorme.
Il avait prévu de repenser et de réécrire. Ce qui est un état d'esprit différent de celui de planifier l'évier de la cuisine et de ne jamais réellement développer ou fournir quoi que ce soit d'utile qui soit complet.
La planification de la fin de vie d'une base de code et d'une réécriture est agile et à l'épreuve du temps. Essayer de trouver un objectif indéfini de "flexibilité" se termine à chaque fois par un échec. Vous concevez sans aucun besoin et perdez du temps, vous pourriez développer ce qui a une valeur commerciale au lieu de rêver de fonctionnalités qui ne seront jamais utilisées.