DRY, KISS és YAGNI elvek

aug 11, 2021
admin

Ez a három elv minden fejlesztőnek fontos, mert a tiszta kódról szól. Ebben a cikkben meg fogjuk érteni, hogy mit jelent mindegyik.

DRY elv

A DDRY a Don’t Repeat Yourself (Ne ismételd magad) rövidítése. A ‘The Pragmatic Programmer’ című könyvben a DRY-nak ezt a definícióját olvashatjuk:

Minden tudásnak egyetlen, egyértelmű, hiteles reprezentációval kell rendelkeznie egy rendszeren belül.

Ez azt jelenti, hogy nem szabad duplikált kódot használni. Egy olyan kódot, amely csak egy helyen van, könnyebb karbantartani, mert ha valamit meg kell változtatni a kódban, akkor csak egy helyen kell változtatni. Emellett, ha ugyanaz a kód két vagy több helyen van, akkor nagy az esélye annak, hogy ez a kód idővel eltérővé válik, és ha ez megtörténik, akkor könnyen hibákat lehet bevinni a rendszerbe. A duplikált kód emellett bonyolultabbá és szükségtelenül nagyobbá teszi a kódot.

Nem szabad kétértelmű kódot írnia. Az osztályaidnak, a változóidnak, a függvényeidnek konkrét nevük kell, hogy legyen, és a nevüknek meg kell egyeznie a felelősségükkel. Ha van egy függvényed, tudnod kell, hogy mit csinál a függvény, ha csak a nevét olvasod, anélkül, hogy a benne lévő kódot kellene elolvasnod.

A ‘The Pragmatic Programmer’ című könyvben azt is láthatjuk, hogy:

A DDRY a tudás, a szándék megkettőzéséről szól. Arról szól, hogy ugyanazt a dolgot
két különböző helyen, esetleg két teljesen különböző módon fejezzük ki

Ez azt jelenti, hogy nem csak a copy and past kódról szól – igen, ez is benne van -, hanem túlmutat ezen. Hanem arról is, hogy különböző kódok csinálják ugyanazt a dolgot. Lehet, hogy két vagy több helyen is lehet különböző kódod, de ugyanazt a dolgot különböző módon csinálják, ezt is kerülni kell.

KISS elv

A KISS a Keep It Simple, Stupid rövidítése. Ez az elv arról szól, hogy a kódod legyen egyszerű. Kerülni kell a felesleges bonyolultságot. Egy egyszerű kódot könnyebb karbantartani és könnyebb megérteni.

Ezt az elvet alkalmazhatod a kód tervezésénél és megvalósításánál. Ki kell küszöbölnie a duplikált kódot, el kell távolítania a felesleges funkciókat, ne használjon felesleges változókat és metódusokat, olyan neveket használjon a változóknak és metódusoknak, amelyeknek van értelme és megfelelnek a feladataiknak, és mindig, amikor csak lehet, kövesse a kódfejlesztés ismert szabványait. Szintén el kell különítenie az osztályok feladatait és a projekt rétegeinek feladatait.

Néha nem kell valami újat implementálnia az igényeihez, egyszerűen kihasználhatja az Ön által használt programozási nyelv funkcióit. Ehhez jó, ha ismeri annak a programozási nyelvnek a jellemzőit, amellyel dolgozik.

Ha olyan kódban dolgozik, amelyet már implementált, és lát valamit, ami nem szükséges vagy egyszerűbb lehetne, érdemes megfontolni a refaktorálást.

YAGNI-elv

YAGNI jelentése You Ain’t Gonna Need It. Ez egy elv az Extreme Programming (XP) szoftverfejlesztési módszertanból. Ez az elv azt mondja ki, hogy nem szabad olyan funkciókat létrehozni, amelyekre nincs igazán szükség.

Ez az elv hasonlít a KISS elvhez, ha egyszer mindkettő az egyszerűbb megoldásra törekszik. A különbség közöttük az, hogy a YAGNI a felesleges funkciók és logikák eltávolítására, a KISS pedig a komplexitásra koncentrál.

Ron Jeffries, az XP egyik társalapítója egyszer azt mondta:

Mindig akkor valósíts meg dolgokat, amikor valóban szükséged van rájuk, soha akkor, amikor csak előre látod, hogy szükséged lesz rájuk.

Ez azt jelenti, hogy ne csak azért valósíts meg funkciókat, mert úgy gondolod, hogy egyszer szükséged lehet rá, hanem akkor valósítsd meg, amikor valóban szükséged van rá. Ha így teszel, elkerülöd, hogy olyan implementációkkal tölts időt, amelyekre nem is volt szükség, és talán soha nem is fogod használni őket.

Következtetés

Az alábbi elvek követése lehetővé teszi, hogy jobb kódot írj. Ne feledje, hogy egy tiszta kódot könnyebb főzni, könnyebb megérteni, és biztosan időt takarít meg, amikor változtatni vagy implementálni kell valamit. Kerülje a duplikált kód használatát, próbálja a kódot a lehető legegyszerűbbé tenni, és csak akkor implementáljon funkciókat, ha az valóban szükséges.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.