Skip to content

Kategória: Praktikák

Cserkészszabály

Miért?
Minden foglalkozás egy adott tárggyal azt legalább egy kicsit jobbá teszi. Mindenféle bürokratikus tervezés nélkül. Alapvető kiindulással a magasabb minőségért.

A Clean Code fejlesztők értékrendszerét nem lehet egyszerre bevezetni. Időre van szükség hozzá. Mivel egy Clean Code fejlesztő ritkán van a zöld mezőben és még ritkábban egyedül, ezért nehéz az elveket a teljes kódbázisra értelmezni. Ezért úgy gondoljuk, fontos, hogy ne állítsunk magunk elé túl magas célokat. Sokkal realisztikusabb és motiválóbb kis lépéseket megcélozni – viszont folyamatosakat.Ezért számunkra a Clean Code fejlesztés alapjához hozzá tartozik a cserkészszabály. Megtalálható a Clean Codeban és a következőképpen hangzik: Mindig jobb állapotban hagyj egy helyet, mint ahogyan találkoztál vele.

A szoftverfejlesztésre alkalmazva ez azt jelenti, hogy: A Clean Code fejlesztők a kódot midig „jobb állapotban” hagyják, mint ahogyan találkoztak vele. Az elvégzett munka után a kód jobban megegyezik a Clean Code fejlesztés értékrendszerével, mint előtte.

Hogy ehhez a Clean Code fejlesztőnek mit kellett tennie, az a szituációtól / a kódtól függ – és természetesen a fokozattól is függ, amelyiken a fejlesztő dolgozik. A piros fokozaton a Clean Code fejlesztő figyel pl. arra, hogy olyan kód, amely még nem volt benne a verziókezelő repository-jában, az bekerüljön oda. És figyel arra, hogy mindenféle ismétlést – tehát a DRY-elv megsértését – kiküszöböljön.

Ahol a Clean Code fejlesztő a CCD-értékrendszer értelmében szuboptimalitást tapasztal, ott mindig igyekszik jobbítani. Kis lépésekben. És természetesen igyekszik elejétől fogva elkerülni a szuboptimalitásokat. Mindig a fokozatának megfelelően.

Ez az alapelv a Clean Code fejlesztő fejlődésének elején áll emlékezve a Broken Windows Theoriera. Annak alapján ugyanis a minőség romlása általános értelemben apróságokkal kezdődik, melyeket elég hosszú ideig nem vettek figyelembe.

Amennyiben azonban a Clean Code fejlesztő a cserkészszabály szerint dolgozik, akkor nem is jut el a „Broken Windows”-ig – és a meglévők, egyik a másik után, kijavításra kerülnek. „Szakadásokat és egyenetlenségeket” a kódban a cserkészszabály a CCD-értékrendszer alapján konzekvensen bezár, hogy ne tudjanak további lerakodások összegyűlni. Ezáltal proaktívan a kóderózió ellen hat. Ezt annyira alapvetőnek ítéljük, hogy felvettük a piros fokozatba.

Root Cause Analysis

Miért?
A tünetek kezelése ugyan gyors javulást okoz, de hosszú távon több ráfordításhoz vezet. Aki ehelyett a problémák felülete alá tekint, az végeredményben hatékonyabban dolgozik.

A Clean Code fejlesztő első napjától fogva annak a szabálynak kellene érvényesnek lennie, hogy problémák esetén a gond valódi gyökerét kell megkeresni. Clean Code fejlesztők nem elégednek meg a tüneti kezeléssel. Példa: Az adatok rendezése a memóriában túl lassú. A felületi kezelés az volna, hogy az egyes utasításokat, utasításblokkokat gyorsítjuk fel. Talán megpróbálkozunk unsafe kóddal, talán párhuzamosítással. Egy behatóbb problémaelemzés azonban azt mutatta volna ki, hogy egy szuboptimális algoritmus a gond gyökere. A nehezen érthető optimalizálást az alsóbb absztrakciós síkon tehát meg lehet úszni. Egy jobb algoritmus a tisztább megoldás.

A probléma gyökerének elemzésével tehát nagy szolgálatot teszünk az érthetőségnek és a ráfordításnak. Mert a probléma gyökerének ismerete esetén a megtisztítás általában kevésbé ráfordításigényes, mint egy tüneti kezelés. Amikor tehát a Clean Code fejlesztő egy problémára bukkan, akkor először megáll, hogy esélyt adjon magának arra, hogy a tünetek mögé tudjon tekinteni.

A Root Cause Analysis „Five Why’s” néven is ismert. Ez a fogalom a Toyota Productions Systems (TPS) terminológiájából származik. Az alapötlet: kérdezd meg legalább ötször, hogy „Miért?”.

Használjunk verziókövető rendszert

Miért?
A félelem egy működő rendszer megrongálásától megbénítja a szoftverfejlesztést. Egy verziókezelővel ez a félelem alaptalan. A fejlesztés gyorsan és bátran mehet tovább.

Minden Clean Code fejlesztő számára elengedhetetlen alapfeltétel, hogy a kódját egy verziókövető rendszer védelme alá helyezze. Hogy ez most Mercurial, Git, Subversion, VSS, TFS vagy Vault, az nem játszik szerepet. Mi úgy gondoljuk, hogy ma nem volna szabad semmilyen munkát végezni a kódon anélkül, hogy azt egy verziókövető rendszerben ápolnánk. Ennek az oka nagyon egyszerű: A verziókövető rendszer megszabadít a félelmektől. És a CCD-értékrendszer elveinek és praktikáinak alkalmazásához szükséges az, hogy ne féljünk.

A verziókövető rendszer elveszi azt a félelmet, hogy valamit rosszul csinálunk vagy tönkre teszünk. Ha a kód egy verziókövető rendszerben van, akkor minden Clean Code fejlesztő tetszése szerint változtathatja meg azt, anélkül, hogy félnie kelljen attól, hogy egy elért állapotot lerombol. Semmi sem vész el. A verziókövető rendszer olyan mint egy időgép a kód számára.

Ezáltal a verziókövető rendszer a lehető legjobb alap bármilyen tanuláshoz. Mert a tanulás azt jelenti, hogy az ember hibázhat. A verziókövető rendszerrel, mint biztonsági hálóval bármilyen hibát megengedhetünk magunknak. Ezért: Az első feltétele a belépésnek a Clean Code fejlesztésbe a verziókövető rendszer folyamatos használata.

Ahol ez egy projektben nem lehetséges, ott úgy tekintjük, hogy a Clean Code fejlesztés alapjai hiányoznak. De azt sem értenénk meg, hogy miért ne lehetne egy verziókövető rendszert használni. Ehhez nincsen szükség anyagi befektetésre és a betanulási idő az egyszerű funkciókba minimális. A Clean Code fejlesztés nem írja elő egy bizonyos verziókövető rendszer használatát, hanem csak azt, hogy egyet használni kell.

Lásd az eszközök alatt.

Egyszerű refaktorálási minták használata

Miért?
Egyszerű a kód javítása, ha az ember ismer tipikus javító lépéseket. A felhasználásuk forgatókönyve érzékennyé teszi az embert saját kódjának gyenge pontjaira. Mint elfogadott minta erősíti annak bátorságát, hogy alkalmazzuk őket.

Többé-kevéssé nagy beavatkozásokra van szükség ahhoz, hogy a kódot jobb állapotban hagyjuk magunk után, mint ahogyan találtuk. Ezeket a Clean Code fejlesztő a verziókövető rendszernek köszönhetően bátran végre tudja hajtani. Igen, de hogyan lehet a munkát lehetőleg egyszerűvé tenni?

A kulcsszó a „refaktorálás”. Martin Fowler a refaktorálás/refactoringot hasonló című könyvében alapvető technikának nevezte a kód minőségének emelése szempontjából. Ebben a könyvében meghatároz egy sor olyan kódváltoztatási mintát, amellyel „code smells”, tehát szuboptimális struktúrákat vagy éppen elvek megsértését lehet megszüntetni.

A piros fokozathoz legfőképpen az eljárás kiemelése (extract method) refaktorálás releváns ahhoz, hogy megfeleljünk a DRY-elvnek. Ezt a Clean Code fejlesztő annak érdekében használja, hogy a többszörösen előforduló kódot kiemelje egy eljárásba, melyet aztán az ismétlődések helyén lehet meghívni.

Mint második refaktorálási módszert a piros fokozaton az átnevezést kellene használni, ahol szükséges. Ez illik a cserkészszabályhoz, hiszen az egyik leggyakoribb „tisztátlanság” a forráskódban a kriptikus nevek használata.

A refaktorálást meg lehet csinálni kézzel is, de van hozzá eszköztámogatás is. A modern IDE-k, mint a Visual Studio, néhány refaktorálási mintát rendelkezésünkre bocsájtanak. A további eszközöket az eszközök tartalmazza.

“A „Refactoring” ugyanúgy a kötelező olvasmányokhoz tartozik minden Clean Code fejlesztő számára a piros fokozattól kezdve, mint a „Tiszta kód” (Clean Code).

Mindennapi reflektálás

Miért?
Reflektálás nélkül nincsen javulás, haladás, tanulás. De csak akkor, ha a reflektálást előre betervezik, csak akkor jut rá idő a mindennapi üzletmenetben.

A Clean Code fejlesztés középpontjában a személyes fejlődés áll. Tehát változásról van szó: A CCD-értékrendszernek minden nappal egyre jobban meg kell jelennie a Clean Code fejlesztők projektjeinek mindennapjaiban. A Clean Code fejlesztés cserkészszabályának alkalmazása önmagára.

Egy ilyen változási úton azonban, különösen egyedül, nehéz haladni. Hogyan maradjunk meg ezen a pályán? Hogyan lehet mérni az előrehaladást?

Anélkül, hogy egy ellenőrző rendszert akarnánk bevezetni, úgy gondoljuk, hogy ehhez két dolog tartozik:

  1. Tervezés kis lépésekben
  2. Reflektálás minden lépés után

A Clean Code fejlesztőknek a projektvezetés előírása nélkül is úgy kellene beosztaniuk a munkájukat, hogy az olyan feladatokból álljon, amit egy nap alatt el lehet végezni. Csak így lehet minden nap estéjén mérleget vonni. Ezt fontosnak tartjuk ahhoz, hogy esténként a munkát ne vigyük magunkkal haza. Ott ugyanis semmi keresnivalója sincsen, mert ez a lazítás ideje.

Az ilyen apró lépésekből tervezett napi munka nem csak kielégítőbb, mert minden nap dönteni lehet a sikerről illetve sikertelenségről. Annak csak a lehetősége, hogy este döntsünk arról, hogy Elvégeztem-e minden feladatomat? Hogyan végeztem el a feladataimat? – már lehetővé teszi a reflektálást a Clean Code fejlesztők értékrendszerének a betartásáról.

Ahhoz, hogy konzekvensen Clean Code fejlesztővé váljunk, a fejlesztőnek minden szinten, minden nap után el kell tudnia számolni azzal, hogy az értékrendszer rá vonatkozó fokozatához tartozó összes aspektusát betartotta-e. A piros fokozat számára ez pl. a következő kérdéseket jelenti: Valóban minden kódrészletet a verziókövető rendszerben tartom? Konzekvensen használtam a DRY-elvet? Általánosan jobb állapotban hagytam hátra a kódot, mint ahogyan találkoztam vele?

Ha ezek közül a kérdések közül egyre csak nehezen tudunk igennel válaszolni vagy nemmel kell válaszolnunk, az sem baj. A legerősebb igyekezet mellett sem sikerül mindig az ember akaratát a gyakorlatba áthelyezni.

Ennek ellenére, vagy éppen emiatt azonban a következőket kell figyelembe venni:

  • A Clean Code fejlesztő vagy addig végzi az utójavításokat, míg a napi munkájával kapcsolatban nem vesz már észre elvsérüléseket,
  • vagy felveszi a felfedezett elvmegsértést a másnapi teendőinek a listájára.

A reflektálásban a Clean Code Developer karkötő lehet egy segítség. Tudjuk, hogy nem mindenki hord szívesen színes szilikon karkötőt. Akinek ezzel nincsen gondja, az használhatja a karkötőt a személyes reflektálásának keretében. Amennyiben a Clean Code fejlesztő az elv megsértését nem tudja vagy akarja megtisztítani vagy a másnapi teendői közé felvenni, akkor vegye át a karkötőt a másik karjára. Ezzel teszi világossá, hogy elismeri a különbséget egy fokozaton teendők és a teljesített munkája között. Ezt ne értsük félre, ne tekintsük vereségnek és semmiképpen ne tekintsük „vezeklésnek”. Ez inkább csak a tanulási folyamat egy tapintható támogatása.

Ha a Clean Code fejlesztőnek 21 napon át nem kellett átvennie a karkötőt egyik kezéről a másikra, akkor tovább léphet a következő fokozatra. A piros fokozat esetében ez a narancs fokozat.