Jött számos visszajelzés a Tiszta kód oktatása című cikkemre. A legtöbb javaslat egy-egy odavetett mozaikszó vagy kifejtendő szabály volt. Ezeket fejtem ki ebben a bejegyzésben és egészítem ki az én értelmezéseimmel.
Boy Scout Rule
A kiscserkészek tudják, hogy a tábort olyan tisztán, vagy még tisztábban kell otthagyni, mint ahogy találtuk. Nem véletlenül kezdem én is ezzel, hisz az életben jóval kevesebb a zöldmezős, éppen induló projekt. Sokkal jellemzőbb a már meglévő kódbázis karbantartása, bővítése. Ezért fontos, hogy ezzel a szabállyal mindenképpen ismertessük meg a tanulókat. Ez az amikor arról beszéltem, hogy egy adott ismeretanyag bevezetése céljából bemutatott kódot nyugodtan refaktoráljunk. Kérdezzük meg, hogy jók-e a változónevek, függvénynevek. Kérjük meg őket, hogy ajánljanak jobban érthetőbb elnevezéseket. Bátorítsuk őket. Ez az ő kódjuk lesz, ebből ők fognak tanulni. Tegyük rutinná a kód átnézést (CodeReview-t). Aki jó ötletet ad, azt díjazzuk. (Nem feltétlen jeggyel, lehet ez egy sima badge is, ami nem kerül semmibe)
KISS
A mozaikszó angol eredetie: Keep It Stupid Simple vagy Simple Stupid. Ezt szabadon úgy szoktam fordítani, hogy törekedjünk a lehető legegyszerűbb megoldásra. Ezt nagyon jó lehet szemléltetni, amikor a tesztvezérelt fejlesztést (TDD) mutatjuk be a diákoknak. Azt a módszert, amikor először megírjuk a tesztet, utána az implementációt, majd refaktorálunk. Ilyenkor ugyanis mindig a lehető legegyszerűbb implementációt alkotjuk meg, ami még kielégíti a tesztet. És itt tényleg a legegyszerűbb megvalósításra kell gondolni. Pl. Írjunk egy olyan függvényt, ami összead két egész számot. Az első tesztünk az lesz, hogy ha ez a függvény nullát és nullát kap, akkor az eredmény is nulla lesz. Ilyenkor az implementációnk a kapott értékektől függetlenül egy nullával tér vissza. Igen, nem számol semmit, csak egy “return 0” és semmi más. Ha most azt gondolnád, hogy ez hülyeség, akkor már meg is találtad, hogy mi a szerepe a stupid szónak a KISS-ban.
Hosszabban kifejtve ez a hozzáállás fogja biztosítani azt, hogy megfelelő mennyiségű és minőségű tesztet írjunk. Természetesen nem kell minden egyes esetben törekedni arra, hogy átverjük a teszteket, hisz a simple szó arra sarkall majd minket, hogy ha már bonyolultabb lenne átverni a teszteket, akkor inkább már a valós üzleti logikát implementáljuk majd.
YAGNI
Jelentése “You aren’t gonna need it” amit “(Egész biztosan) Nem lesz rá szükséged”-nek fordítanék. Ez a szabály arra utal, hogy ne készítsünk “majd egyszer jó lesz” kódokat. Ez a szabály segít rövidre zárni az olyan beszélgetéseket, amikor feltesszük magunknak a kérdést, hogy “Biztos kell ez?”. Ilyenkor nem engedjük meg magunknak azt a luxust, hogy azt mondhassuk, hogy “hát szerintem ez majd kell, amikor…”. Sőt azt a luxust se engedjük meg magunkat, hogy ezen egyáltalán elgondolkodjunk, mert a válasz egyértelmű: YAGNI
Ez egy egyfajta mentális rövidzár, vagy ha úgy tetszik póráz a zabolátlanul ugra-bugráló elmének.
A jó hír az, ha a KISS-t tartjuk, akkor YAGNI is meglesz. :)
Occam’s razor / Occam borotvája
“A tétel lényege az, hogy ha van két elmélet, amely ugyanazt a tényt magyarázza, akkor azt kell választani, mely a kevesebb (tudományosan nem bizonyítható) feltételezést tartalmazza, vagyis a legkevesebb hipotézisre épít.” írja a Wikipedia. Enpassant pedig a következőt emeli ki részletes írásában: “két megoldás közül azt érdemes választani, amelyik az egyszerűbb”
Ha jobban elszeretnél még mélyedni az egyszerűségbe, akkor ajánlom Edward De Bono “Simplicity - A zseniálisan egyszerű” c. könyvét, ami nem fejlesztésről, hanem általános gondolkodásról szól.
DRY
“Don’t repeat yourself” magyarul “ne ismételd magad”, vagyis kerüljük a duplikációt. Sokan ezt a kód duplikáció tilalmának gondolják, de én inkább az üzleti logika implementációjának többszöri előfordulásának elkerüléseként szeretem használni ezt a pontot. Mi a különbség? Álljon itt egy példa:
Egyszer egy webáruház kódját néztem át. A kód egy igazi csemege volt egy olyan embernek, mint én aki a kód régészet megszállott híve. Az árazási logika tizenhét helyen volt implementálva a kódban. Az ár megjelenítésével együtt, ami így tizenhét különböző kódot eredményezet. Nem lehetett azt mondani, hogy kopipészt lett volna. Látszott, hogy egy-egy változás, egy-egy újabb kedvezmény, hogyan állította újabb és újabb kihívás elé a fejlesztőt. Látszott hogyan fogyott el a szufla, és maradt benn pár változó a különböző helyeken azzal a felkiáltással, hogy na jó én ezt nem fogom mindenhol módosítani. Ezt kísérte természetesen a különböző random helyekre lehullajtott globális változó nullázások, melyeknél szinte hallottam az összeszorított fogak közül kisistergő “na b@&# ez már most már biztos jó lesz” mondatokat és a nap végén kiszakadó boldog sóhajt: “MŰXIK”. Aztán másnap kezdődik előről a dolog, hisz ilyenkor nem csak a logikát, hanem a végtelen hibajavításokat is ismételjük.
Separation of concerns / Szétválasztás elve
A vége az lett, hogy az árazási logikát szétválasztottam a megjelenítési logikákból. Így kaptam egy árazási logikát és tizenhét különböző megjelenítési logikát. Természetesen “jó el is rontottam” az átszervezést, hisz így a törzsvásárlói kedvezmény azoknál a termékeknél is megjelent, amik több variációban voltak kaphatóak. Addig ugyanis, a korábbi fejlesztő elmondása alapján ez lehetetlen volt. Mindent összefoglalva, maga a DRY nem teszi feltétlenül tisztává a kódunkat, ha csak a kódra koncentrálunk és nem a kód által megvalósított logikára. Amiket azonosítanunk kell, majd szétválasztani így kerülve el azok ismétlését.
Miért?
Többször láttam már olyan fejlesztőt, aki kifejtette, hogy nem érdekli miért is kell kódolnia, csak mondják el mit kell lekódolni és aztán hagyják békén. Az ilyen munkatársakkal mindig nehezen ment a közös munka. Egyrészt sokkal egyszerűbb és gyorsabb volt lekódolni a dolgokat, mint részletes mindenre kiterjedő specifikációt írni. Másrészt én hiszek abba, hogy egy párbeszéd során a különböző látásmódok miatt értékesebb megoldás születik a végén mintha egyedül csinálnám. Szóval minél jobban érti az üzleti igényt a fejlesztő annál jobb alkalmazás készül és annál tisztább tud maradni a kód. Ezzel a véleményemmel szerencsére nem vagyok egyedül. Sági-Kazár Márk is a következőket fogalmazta meg:
Akkor azt mondanám, hogy a legfontosabb, hogy a fejlesztő minél jobban értse a businesst és a terméket. A gányolások szerintem leginkább abból adódnak, hogy jön valami igény, ami üzletileg lehet értelmes, de a fejlesztőknek derült égből villamcsapás, nem értik, nem találják a helyét és begányolják valahova. Tudom, nem feltétlenül “technika”, de szerintem fontos.
Hamarosan jön a folytatás (S.O.L.I.D., Guard clause/code/statement, stb.), addig se tartsd magadba amit mondani szeretnél és oszd meg velem a véleményedet!