66Teknologi

YAGNI

You Aren't Gonna Need It: byg ikke funktionalitet, før du faktisk har brug for den.

Kort fortalt

YAGNI betyder, at man ikke skal implementere noget, bare fordi man måske får brug for det senere. Spekulativ funktionalitet koster nu — og er ofte forkert, når fremtiden kommer.

Hvad betyder princippet?

YAGNI er et kerneprincip i Extreme Programming. Det hænger sammen med iterativ levering: byg det nødvendige, lær af virkeligheden, udvid derefter.

Princippet er ikke anti-arkitektur. Det er anti-gætning. Den bedste forberedelse er ofte klar kode og mulighed for ændring — ikke et katalog af ubrugte features.

Den dyreste kode er den, I vedligeholder uden at have brug for den.

Et konkret eksempel

Et team bygger et komplekst rettighedssystem “til enterprise senere”, mens produktet endnu har ét team og to roller. Måneder bruges på cases, der aldrig kommer. En enklere model ville have været nok — og lettere at erstatte.

En udvikler tilføjer konfigurationsflag til tre fremtidige integrationer. Ingen af dem realiseres. Flagene skaber dog testmatrix og dokumentationsstøj.

Hvornår er princippet nyttigt?

  • Når backlogs fyldes af hypotetiske behov.
  • Når “fremtidssikring” driver kompleksitet.
  • Når man prioriterer MVP og iteration.
  • Når man review’er PR’er med spekulativ scope.

Begrænsninger og kritik

Nogle beslutninger er dyre at udskyde: sikkerhed, compliance, data-modelvalg. YAGNI betyder ikke “tænk aldrig frem”. Det betyder, at spekulativ funktionalitet skal have et konkret behov.

Kombinér med domæneviden: udskyd det reversible; vær mere forsigtig med det irreversible.

Kilder

  1. Extreme Programming-praksis; Ron Jeffries og XP-miljøet — popularisering af YAGNI.
  2. Bemærkning: Princippet er en agil heuristik, ikke en formel ingeniørlov.
  • 14DRY-princippetDon't Repeat Yourself: undgå at den samme viden findes i flere, uafhængige kopier, der kan komme ud af sync.
  • 23Galls lovKomplekse systemer, der virker, er typisk vokset ud af simple systemer, der virkede — de designes sjældent færdige fra scratch.
  • 34KISS-princippetHold løsninger så enkle som muligt — kompleksitet bør være begrundet, ikke standard.
  • 39Loven om utætte abstraktionerAlle ikke-trivielle abstraktioner lækker: før eller siden må man forstå lagene under for at fejlsøge eller bruge dem korrekt.