"A hídon akkor kell átmenni, amikor odaérünk."​ - YAGNI

"You ain't gonna need it." - YAGNI, azaz az egyik elég sűrűn citált szoftverfejlesztési paradigma azt mondja, hogy nem szabad felkészülni elképzelt, nem tisztán látszó/megfogalmazott funkciókra, mert csak fölöslegesen növelik a kódbázist és a komplexitást.

Vannak azonban kivételek, amikor hiába a YAGNI, ha egy ilyen döntéshez érkezünk, igenis az absztraktabb, bonyolultabb megoldást kell választani, mert különben teherautóval érkezünk a kötélhídhoz. Néhány példa következik, amik kis befektetéssel nagyon meg tudnak térülni.

1. Naplózás: bármennyire is fölöslegesnek vagy valószínűtlennek tűnik, hogy bármikor naplófájlokat fogunk böngészni, erre szükség van. A naplófájlok könnyen törölhetők, viszont a nem naplózott események örökre elvesztek.

2. Időpontok: tipikus példa, amikor egy adatbázisrekord egy igaz/hamis tényt rögzít, pl. "aktivált-e felhasználói fiók", azaz az "active" mező true/false. Sokkal több információt hordoz, és csaknem azonos módon kell kódból kezelni, ha ott egy timestamp mezőt használunk. Szintén azonos hozzáadott értéke van: olyan plusz információt rögzítünk, amit később nagyon nehéz kideríteni (mondjuk naplófájlból :)). Szintén praktikus a rekordok létrejöttét egy időbélyeggel automatikusan kitöltődő mezővel kezelni.

3. Verziózás: tömören fogalmazva, lehetőséget ad drasztikus változtatásokra (breaking change) olyan módon, hogy a verziózott elemek képesek egymás mellett élni. Tipikus példa az API, ahol struktúrális változásokat csak úgy lehet bevezetni, hogy sérül a protokoll, viszont ha eleve verziókkal indultunk, akkor a /api/v2 alá elhelyezhető az új/más felépítés. Hasonló megközelítés lehet praktikus konfigurációs fájlok esetében is.

4. Relációs adatbázis: ha egy rendszer a való élet egy részének reflexiójával foglalkozik, elkerülhetetlen, hogy a kezelt elemek valamilyen kapcsolatban legyenek egymással (pont, mint ahogy a való életben is). Ezek adatainak rögzítését a nagy múltra visszatekintő, kiforrott, erre optimalizált relációs adatbázisban a legkézenfekvőbb kezelni. Nem hülyeség, ha ez az adatbáziskezelő amúgy hatékonyan támogatja a dokumentum-alapú tárolási formát is - fordítva viszont eléggé meggyűlhet a bajunk, ha az elemek kapcsolatát akarjuk kiépíteni.

5. Több-az-egyhez kapcsolat: ha felmerülne az az ötlet az ügyfél részéről, hogy "egy projektnek csak egy managere lesz", akkor sokkal egyszerűbb és faktorokkal kisebb költségű arra felkészülni, hogy egy projektnek több managere lehet, mint annak a költsége, hogy később térjünk erre át.

6. Verziókezelés: bármilyen kicsinek és egyszerűnek tűnik valami, mindig megéri végigkövetni a változásokat. Lehet ez akár dokumentációs célból, bizonyítékként, simán csak egy rosszul sikerült próbálkozás megőrzéséért - nem ritkán kiderül, hogy egy rövid kódrészlet abból a működésképtelen kódból lenne jó, mert már egyszer megírtam.

7. Több nyelvű megközelítés: ez nagyban függ a technológiai eszközöktől, de szintén egy nagyon praktikus szempont, főleg mióta a globalizáció a következő sebességbe kapcsolt.

A lényeg, hogy bár a YAGNI egy alapvetően jó megközelítés a legtöbb esetben, nem szabad azt mondani rá, hogy csak ez az egyetlen helyes út. A hands-on tapasztalat sok esetben kialakít bennünk egy olyan "ösztönt", hogy később már magunk is tudni fogjuk, mi az, amivel érdemes kivételt tenni. Ha pedig nem, akkor bővítsük együtt ezt a listát azok számára, akik nem a saját kárukon akarnak tanulni! :)