Skip to content

Hónap: 2016 December

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.

Bevezetés

A Clean Code fejlesztők fokozatosan fejlesztik magukat egy fokozat-rendszerben. A tulajdonképpeni munka a piros fokozaton kezdődik. Mi van azonban akkor, ha az ember érdeklődik a Clean Code fejlesztés iránt, de még nem tudja, hogy kezdjen neki? Mi van akkor, ha valaki motivált, de szervezési akadályok vannak a projektben?

Ahhoz, hogy Clean Code fejlesztői érdeklődését „igazolja”, ehhez a piros fokozat elé még egy továbbit helyeztünk, a feketét. A fekete fokozat szintjén a Clean Code fejlesztés iránt érdeklődő egy fekete karkötőt hord, hogy „kereső”-nek mutassa magát. Napi munkájában azonban nem a Clean Code fejlesztők értékrendszerének értelmében dolgozik.

A fekete fokozat karkötője csak az érdeklődését jelzi, és emlékezteti arra, hogy teremtse meg a feltételeit a piros fokozaton dolgozásnak. Ezért a fekete karkötőket minden korlátozás nélkül lehet szétosztani. Vírusos reklámfelületei a Clean Code fejlesztésnek.

Tovább a piros fokozatra.