Skip to content

You Ain´t Gonna Need It (YAGNI)

Miért?
Az olyan dolgok, amikre senkinek nincsen szüksége, azok értéktelenek. Ne pazaroljunk rá tehát időt.

A YAGNI elv (You Ain´t Gonna Need It) a szoftverfejlesztés egyik legegyszerűbb – és a DRY elv után leggyakrabban megsértett elve. Ezért a YAGNI nem csak a piros fokozat elején áll, hanem itt, az értékrendszeren keresztül vezető útnak majdnem a végén is.A YAGNI szabály a követelménypontosságból és a termék materialitásának a szoftverfejlesztésben különleges viszonyából alakult ki. A követelmények notorikusan pontatlanok vagy váltakozók, a termék pedig, amiben meg kellene valósulniuk, immateriális. Összehasonlítva a gépészettel vagy az építészettel az anyag végtelenszer rugalmasabb és elvileg viszonylag kevés ráfordítással szinte minden követelményhez hozzá lehet igazítani. Magas illékonyság ill. pontatlanság tehát nagy rugalmasságra talál. Ez elsőre ideálisnak tűnhet.

A gyakorlat azonban azt mutatja, hogy pontosan ebben az arányban rejlik sok projekt sikertelenségének magja. Rövidtávon a figyelve a projektek megpróbálják a legkézenfekvőbbel a helyes dolgot tenni:

  • A pontatlan követelményeket gyakran olyan termékek kompenzálják, melyek megkísérlik a pontatlanságot kompenzálni. A szoftver immaterialitását arra használják, hogy olyan szélesen és rugalmasan implementáljanak, hogy a még ismeretlen vagy elmosódó követelményeket már quasi előresiető engedelmességel kielégítsék.
  • A folyamatosan változó követelmények a termékben a lehető leggyorsabban bevezetésre kerülnek, mert ez az immaterialitásának köszönhetően lehetséges.

Hosszútávon azonban az ilyen viselkedés kontraproduktív:

  • Az előresiető engedelmesség szélességhez és rugalmassághoz vezet, amelyekre nincsen valóban szükség. Olyan feature-öket valósít meg, amelyeket később nem használnak.
  • A szoftver gyors átépítése a változós követelményeknek megfelelően a kód minőségének eróziójához vezet. A szoftver ugyan immateriális és rugalmas – de nem minden szoftverstruktúra továbbfejleszthető vagy csak érthető.

Zavaros és változó követelményszituációk az szoftver alapvető rugalmasságának háttere előtt gyorsan vezetnek felesleges többletköltségekhez és merev kódhoz. Sok olyan projekt, amelyik messze túllépte a költségeit, és még több olyan projekt, amely pár év elteltével karbantarthatatlanná vált, bizonyítja ezt.

A Clean Code fejlesztőknek, mint professzionális szoftverfejlesztőknek nap mint nap ellen kell állniuk az ilyen fejleményeknek. A szoftver tagadhatatlan természete miatt – immateriális és az is marad – ezt a követelményekkel való bánásmódnál lehet megfogni. Ez a YAGNI szabály forrása.

A YAGNI szabály olyan, mint egy éles kés: Aki használja, az egy problémát a közvetlenül szükséges elemek kicsi kockáira vág. A YAGNI szabály szerint csak a kétségtelenül és közvetlenül hasznot hozó dolgok kerülnek implementálásra. Minden egyéb… azt majd később. Ilyen tekintetben a YAGNI kéz a kézben jár a Lean Software Development„dönts a lehető legkésőbb” szabályával.

A YAGNI szabály a szoftverfejlesztés minden síkján és minden fázisában releváns. Bármikor, amikor azt kérdezzük magunktól, hogy „Szükség van-e erre a ráfordításra?” vagy „Szükségünk van erre valóban?” – és jöjjön ez akár egészen elnyomva agyunk leghátsó zugaiból – akkor ez a YAGNI szabály egy használati esete. A következőket mondja: Ha kétségeid vannak, akkor dönts a ráfordítás ellen.

Könnyűnek tűnhet, de nehéz. Innen adódnak a gyakori megszegései. Sok erő létezik, mely a ráfordítás elleni döntésnek ellentmond. „Nem is olyan nagy ráfordítás” vagy „Ha most nem gondolkodunk előre, akkor a jövőben nem fogunk tudni változtatni” ez csak két kézenfenkő magyarázat a ráfordítás megindoklására, akkor is, ha kétségek merülnek fel a hasznosságát illetően. Ez a architektúradöntéseket is érinti (pl. El kellene-e már most kezdeni a megosztott architektúrát, akkor is, ha a mai terhelésnél ez még nem szükséges?) és a lokális döntéseket is (pl. Kell-e már most optimalizálni az algoritmust, akkor is, ha pillanatnyilag nem okoz architektúraproblémákat?).

A megrendelő csak a közvetlen haszonért fizet. Az amit ma nem tud világosan specifikálni, az nem használ neki. Ezt az implementálásnál előre látni akarni, ráfordítást fektet be, haszon generálása nélkül. Amikor a megrendelő később pontosabban tudja, hogy mit is akar, akkor – és nem korábban! – eljött az ideje annak, hogy kielégítsük az akaratát. Amikor azonban egy projekt soron kívűl próbálja ezt az akaratot kielégíteni, akkor azt kockáztatja, hogy a megrendelő holnapi akaratával ennek ellent fog mondani. Egy olyan feature – funkcionális vagy nem funkcionális – amit ma világos követelmény nélkül implementálnak, az a megrendelőt holnap talán már nem is érdekli. Vagy talán már nem lesz neki annyira fontos, mint egy másik feature.

Ez a szoftverfejlesztés számára a következőket jelenti:

  • Kizárólag a világos követelményeket szabad implementálni.
  • A megrendelő priorizálja a világos követelményeit.
  • A világos követelményeket kell a prioritásuk sorrendjében megvalósítani.
  • A fejlesztési folyamatot és a kód struktúráját nagyban és kicsiben úgy kell kialakítani, hogy ne ébredjen félelem a változó és új követelmények megvalósítása iránt.

A Clean Code fejlesztők, mint professzionális fejlesztők a megrendelő felé ezt az eljárást félreérthetetlenül kommunikálják. Ezáltal:

  • szolgáltatásszelleművé válunk, hiszen nem kell elutasítanunk a megrendelő egyetlen világos követelményét sem
  • felelősségteljessé válunk, mert a büdzsét csak a világosan megfogalmazott haszon érdekében használjuk
  • védelmezővé válunk a kóddal szemben, mert megóvjuk a végeredményben szükségtelen dolgokkal történő túlpakolástól.

A YAGNI ezért nem csak egy olyan szabály, amit minden fejlesztőnek be kellene tartania, hanem projekteknek és teameknek a szabálya, tehát szervezeti szinteken. A YAGNI ugyanúgy mindig használandó, mint a DRY. Kétség esetén, ha lehetséges halaszd el a döntést. Különben dönts a ráfordítás ellen. Ez feszültségtől mentesít, salaktalanít és gyors sikerhez vezet.

Published inElvek