Fejlesztési alapelvek

A szoftverfejlesztés történelme során megfogalmazódott pár elv, tanács, amelyek nagymértékben hozzá tudnak ahhoz járulni, hogy karbantartható kódot készítsünk. Egy működő kód nem sokat ér, ha nincs aki értené, hogy hogyan is működik és biztonsággal hozzá merne nyúlni. A tapasztalat pedig az, hogy előbb-utóbb hozzá kell nyúlni, mert az igények változni fognak.

Éppen ezért a szoftverfejlesztés történelme során megfogalmazódott pár elv, amelyek követése segít abban, hogy karbantartható kódot írjunk. Fontos megjegyezni, hogy ezek inkább ajánlások és nem feltétel nélkül követendő törvények vagy szabályok, mert bármelyik megszegésére létezik nyomós indok.

DRY

Az egyik ilyen tervezési elv a DRY, ami a Don’t Repeat Yourself szavakat rövidíti és arról szól, hogy ne ismételjük magunkat. Ez az elv arról szólna, hogy a szoftver bővítése során a hasonló részeket használjuk újra, emeljük közös komponensbe ahelyett, hogy lemásolnánk és adaptálnánk őket. A másolással az a baj, hogy a kód összes okos megoldása mellett az összes hibáját is másolja az újak bevezetése mellett. A sok másolást, ismétlődő részeket tartalmazó kódbázist WET-nek nevezi a szakirodalom, ami a Write Everything Twice szavakból (mindent kétszer írunk meg) jön. Egy ilyen kódbázisban egy hiba kijavítása nem egyszerű, mivel a másolások számától függően N alkalommal kell ezt megtennünk.

A DRY elv követését segíti, ha a közös részeket például örökléssel egy ősosztályba szervezzük, vagy metódus szinten a közös részeket egy segéd metódusba kiemeljük, amit aztán újrahasználunk.

Van amikor a D.R.Y helyett jobb megoldás, ha a kiinduló kód inkább a W.E.T elvet követi. Tipikusan ez agilis fejlesztés során tud jól jönni, amikor a követelmények változhatnak, nem teljesen egyértelműek és kőbevésettek. Ilyen esetekben, amikor nem tudjuk, hogy mit hoz majd a jövő és nem látjuk előre, milyen hatásai lehetnek a kért változtatásoknak jobb, ha W.E.T megoldással állunk neki egy adott funkciónak. Azonban arra törekedjünk, hogy a megoldás ne sokáig maradjon a termékben. Amint a követelmények egyértelművé válnak, írjuk át a kódot úgy, hogy a DRY elvet kövesse.

KISS

A KISS mozaikszó eredetileg nem a szoftverfejlesztés világából jön. Az eredete a haditengerészethez és a katonasághoz köthető és a Keep It Simple Stupid szavak rövidítése és talán úgy fordítható, hogy törekedjünk az egyszerűségre, mivel az egyszerű megoldások általában jobbak. A hadseregnél ez azért fogalmazódott meg, mert stresszhelyzetben egy bonyolult berendezés üzemeltetése igencsak nehéz feladat, illetve nem javítható egyszerűen. Ugyanez igaz a kódra és a programokra is. Egy bonyolultan használható szoftver nem lesz a felhasználók kedvence, illetve minél több bonyolult megoldás van benne, annál nehezebben lesz karbantartható és nagyobb az esélye, hogy egy módosítás nem várt következményekkel járhat. A KISS elv nem követésére véleményem szerint a Quake III fast inverse square root kódja ékes példa:

float q_rsqrt(float number)
{
  long i;
  float x2, y;
  const float threehalfs = 1.5F;

  x2 = number * 0.5F;
  y  = number;
  i  = * ( long * ) &y;                       // evil floating point bit level hacking
  i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
  y  = * ( float * ) &i;
  y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
  // y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed
  return y;
}

A kód működésében zseniális és a maga idejében a leggyorsabb megoldás¹ volt a problémára, ez vitathatatlan, de mivel külön Wikipedia szócikk magyarázza a működését² és közel fél órán keresztül magyarázza valaki a YouTube-on, hogy miért működik a kód³, az számomra ékes példája annak, hogy ez sok minden, de nem egyszerű.

A fenti pár soros kódrészlet azt is szemlélteti egyébként, hogy a bonyolult és összetett problémák általában összetett megoldást fognak igényelni, valamint az olvasható és a gyors kód kifejezések általában egymás ellentettjei.

YAGNI

A YAGNI a You Ain’t Gona Need It kifejezés rövidítése, ami annyit jelent, hogy nem lesz rá szükséged. Ez azt jelenti, hogy ha a feladatunk egy egyszerű konzol alkalmazás implementálása egy adott probléma megoldására, ami 1x fordul elő, akkor ne bonyolítsuk túl feleslegesen az implementációt mintákkal és szofisztikált megoldások hegyével, mert valószínűleg többet számít, hogy gyorsan megoldja a problémát az alkalmazás ahelyett, hogy mennyire jól lett megírva.

Röviden: ne gondoljuk túl a követelményeket. Ha valami nem egyértelmű, akkor kérdezzünk rá kétszer, háromszor is inkább, mint hogy feltételezések alapján olyasmit is bele gondoljunk az elvárások közé, amire nincs és nem is lesz szükség.

A YAGNI elv igaz a kommentelt kód részletekre is. Fejlesztés közben okés, hogy a kódot ideiglenesen kommentekkel kikapcsoljuk, de ez ne maradjon a kódban, mert csak felesleges vizuális zaj és ha nincs tovább rá szükség, akkor valószínűleg a jövőben sem lesz rá szükség, vagy ha mégis, akkor ott a verziókezelő, amiből vissza lehet állítani a kódot.