Szokatlan szoftverfejlesztési kifejezések
A szoftverfejlesztés tele van vicces és furcsa szakszavakkal. Ebben a cikkben ezekből szemezgetünk kategóriákra bontva.
Tervezési klasszikusok
DRY
A „Don’t repeat yourself” (Ne ismételd magad) kifejezésből képzett mozaikszó, ami azt hivatott kifejezni, hogy ha lehetőség van rá, akkor ne ismételjük a mintákat és a kódot. Ha van két metódus, ami egy picit tér el egymástól, akkor szervezzük ki a közös részt egy külön metódusba. Ugyanez igaz osztályokra. Ha az implementáció 60%-a megegyezik két osztály esetén, akkor vezessünk be egy őst, ami a közös részeket tartalmazza. A DRY kód ellentéte a WET, ami szintén egy mozaikszó, a „write every time”, „we enjoy typing” vagy „waste everyone’s time” kifejezések egyikére utal.
KISS
A „Keep it simple, stupid” (Tartsd egyszerűen, bután) kifejezésből képzett mozaikszó. Eredetileg a 1960-as években bukkant fel a kifejezés az amerikai hadsereg háza táján. Azt hivatott kifejezni, hogy a legtöbb rendszer akkor működik megbízhatóan, ha nincs túlkomplikálva. Szoftverfejlesztésben ez úgy értelmezendő, hogy ha valami megoldható egyszerűen, akkor ne vezessünk be bonyolult absztrakciót, törekedjünk a kód olvashatóságára és könnyen érthetőségére, valamint kerüljük a túl hosszú metódusokat és a több felelősséggel rendelkező osztályokat.
YAGNI
A „You aren’t gonna need it” (Nem lesz rá szükséged) kifejezésből képzett mozaikszó. Az extrém programozás egyik alapelve, ami azt mondja ki, hogy nem kell funkcionalitásokat készíteni, amíg nem bizonyosodik be, hogy azokra valóban szükség van. Ron Jeffries, az extrém programozás társalapítója így vélekedett: „Mindig implementáld a dolgokat, amelyekre ténylegesen szükséged van, azokat viszont ne, amelyekről csak sejted, hogy szükséged lehet rájuk”.1
Kódolási kifejezések
Spaghetti Code
Leginkább procedurális nyelvek mellékterméke, de objektumorientált és funkcionális nyelvek esetén is produkálható. Tipikusan az a kód, aminek se eleje se vége, mint a spagettinek. A spagetti kód karbantarthatósága a nulla felé közelít: nehéz benne a hibakeresés és nehezen is bővíthető. Általában a tervezés hiányára, vagy nem megfelelő minőségére utal.
Jenga code
Olyan kódrészlet, amelynek a módosítása eltörheti az egész szoftver működését. Szintén a tervezés hiányának vagy nem megfelelő minőségének a mellékterméke.
Pokémon exception handling
Egy olyan try – catch blokk, amiben a catch minden típusú kivételt elkap. Nevét a Pokémon sorozat főcímzenéjéből kapta: „Gotta Catch ‘Em All” 2 Egy szoftver akkor jó, ha csak egyetlenegy darab ilyen blokk van az egész programban, egyfajta utolsó védelmi bástyaként. Tehát ne csináljunk olyan metódusokat, amelyek csak úgy elkapnak és elnyelnek naplózás nélkül bármilyen kivételt, mert nagyon meg tudjuk nehezíteni a hibák megtalálását, illetve biztonsági réseket is elfedhetünk vele.
Rambo coding
Az a fajta kódolási stílus, amikor minimális előretervezés nélkül nekiülünk kódot gyártani és menet közben találjuk ki a részleteket lesz, ami lesz alapon. Ennek általában a vége egy hatalmas káosz, mint ahogy Rambo után maradni szokott. Hasznos akkor tud lenni, ha gyors prototípust kell alkotni, ami nem kerül végleges termékbe. Általában a Rambo kódolás végterméke a spagetti vagy Jenga kód.
Guerrilla coding
Olyan kódolási tevékenység végzése, aminek semmi nyoma nincs a feladatok között. Pl. egy új funkció fejlesztése közben találunk egy hibát, amit nem dokumentálunk, csak kijavítunk szépen csendben. Ezzel a probléma az, hogy nem biztos, hogy az a hibásnak vélt működés valóban hiba. Kifejezetten káros tud lenni, főleg csapatos fejlesztés közben. A kommunikáció nem megfelelő minőségére vagy csapatbeli, menedzsmentbeli problémákra utalhat.
Hibák
Heisenbug
A Heisenberg-féle határozatlansági elv3 után kapta a nevét. Olyan hibákra használatos, amelyek eltűnnek, vagy megváltoztatják a működésüket, ha megpróbáljuk megkeresni őket debug során. Tipikusan ebbe a kategóriába tartoznak a szál- és versenyhelyzet kezelési hibák: egy rendszer teljesen másként működhet Release konfigurációban, mint mondjuk Debug környezetben.
Higs buggson
Nevét a Higgs-bozonról4 kapta. Olyan hiba, amelynek a létezését a kód olvasása és egyéb külső behatások alapján sejtjük, tudjuk, de előhozni, vagy reprodukálni a hibát nagyon nehéz.
Hindenbug
A Hindenburg katasztrófáról5 kapta nevét. Olyan hiba, amely katasztrofális következményekkel jár.
Dinamikusan típusos nyelvek szépségei
Duck typing
A dinamikusan típusos nyelvek szépsége és átka egyben, hogy nem tudunk interfészeket definiálni a komponensekhez, ezért menet közben kell eldöntenünk, hogy egy objektum megfelel-e a kritériumoknak. A kifejezés a nevét onnan kapta, hogy ha hápog, mint egy kacsa, akkor valószínűleg egy kacsa. Ez gyakorlatban azt jelenti, hogy egy osztály használata előtt meg kell bizonyosodunk, hogy rendelkezik egy adott metódussal. Ha igen, akkor meg tudjuk hívni és bízunk abban, hogy azt csinálja, mint amire gondolunk.
Duck Punching
Addig ütjük, amíg nem hápog vagy nem úgy hápog, mint ahogy mi szeretnénk. Nem csak dinamikusan típusos nyelvek esetén használt, de leggyakrabban itt fordul elő. A kifejezés azt a folyamatot írja le, amikor van egy metódusunk, ami visszaad adatot valamilyen formában, de az nekünk nem megfelelő, vagy nem felhasználható, ezért addig konvertálgatjuk, amíg nekünk nem lesz jó. Persze nem pozitív értelemben, mert az ilyen kódrészletek általában nem arról híresek, hogy komolyabb átgondolás eredményeként születtek volna és általában még a minimális hibakezeléstől is mentesek.
Stringly Typed
Az olyan dinamikusan típusos nyelvek gúnyneve, amelyek rendelkeznek === operátorral. Egyfajta szójáték a Strongly Typed (erősen típusos) után. Az olyan nyelvek, ahol a === operátor létezik, ott a string típus egyfajta joker típus és az értelmező szerint a 1 == „1” egy és ugyanaz. Ennek megvannak az előnyei, de a hátrányai is, különösen akkor, ha tudatosan kódot építünk erre a fajta működésre.
Monkey patch
A Monkey patch egy olyan kódrészlet, ami futásidőben módosítja vagy teljesen felülírja a futó program egyes részeit. Tételezzük fel, hogy van egy kódrészletünk, ami erősen épít a beépített sqrt függvényre, ami kivételt dob negatív számok esetén. Monkey patch-el ez úgy orvosolható, hogy készítünk egy saját Sqrt függvényt, ami negatív számok esetén kivétel helyett mondjuk NaN-t ad vissza, majd a rendszerbe épített sqrt-t felülírjuk a saját megoldásunkkal, ezáltal nem kell átnéznünk egy tonna kódot és lecserélnünk a hívásokat, mert a gyári függvényt cseréltük le. Egyfelől zseniális, hogy meg lehet csinálni, másrészről pedig egy borzalmas megoldás, ha ténylegesen ezt tesszük.
+1 kacsa : Ruber duck debugging
Akkor tud kifejezetten hasznos lenni, ha van egy hiba a kódunkban és nagyon nem jövünk rá az okára. Ebben az esetben a hangos gondolkodás tud segíteni, de magunkban beszélni minimum fura. Ezért fogunk egy gumikacsát és neki magyarázzuk el a program működését. A folyamat közben pedig valószínűleg rájövünk a logikai buktatóra, ami a hibát okozza.
Nyereményjáték
Ha még csak most ismerkedsz a szoftverfejlesztéssel, vagy hülyén néznek rád a lakótársak debuggolás közben, hogy magadban beszélsz, akkor itt a remek lehetőség, hogy szerezz magadnak egy LVL 99-es minden nyelven is profi debuggoló kacsa társat, aki a tudása mellett a sármjával is elkápráztat. 🦆
Részletekért keresd a C# Tutorial Facebook oldalát. 🦆🦆
