05 óra

Együttműködés a verziókövető rendszer segítségével

Verziókövető rendszerek

A szoftverek verziószámozása a számítógépes szoftverek egyedi állapotainak kategorizálása a fejlesztés és a kiadás során. A verzióazonosító általában egy szó, egy szám vagy mindkettő. Például az 1.0-ás verziót általában egy program kezdeti kiadásának jelölésére használják. Nincs ipari szabvány arra vonatkozóan, hogy a verziószámot hogyan kell formázni.

A verzióinformációk a verziószámon kívül az alábbiak fontos adatokat tartalmazzák:

• Szerző: Ki hozta létre az adott verziót?
• A változás tárgya: Mely modulon, forráson történt a változás?
• A változás oka: Miért történt a módosítás? (commit message)
• A változás ideje: Mikor történt a változás?

A verziókövető rendszerek megjelenése előtt a verzióinformációkat közvetlenül a forráskódot tartalmazó fájlba, illetőleg a hozzá mellékelt dokumentációba manuálisan írták bele. Ez a dokumentációs tevékenység gyakran elmaradt, ami jelentős nehézséget okozott az eltérő verziójú modulok integrációja során, vagy abban az esetben, ha egy forráskódon többen is dolgoztak. Míg kisebb méretű rendszerek és fejlesztői csapatok esetében megoldható volt a verziómenedzsment, egy nagyobb rendszer, vagy egy diverzifikált fejlesztői team esetén a hatékony verziómenedzsment hiánya jelentősen fékezte a fejlesztést. A verziókövető rendszerekre hamar igény jelentkezett.

A verziókövető rendszerek feladata a szoftververziók menedzsmentjének, a verzióinformációk egységes kezelésének biztosítása, a fejlesztési ágak felügyelete és kezelése. Lehetővé teszik a szoftver korábbi verzióinak elérését, a verziók közötti különbségek nyilvántartását, a fejlesztés során adódó konfliktusok kezelését.

A verziókezelő rendszerek lehetnek központosítottak vagy elosztottak. A két architektúra közötti különbségeket mutatja az alábbi ábra:

Git

A Git egy ingyenes és nyílt forráskódú, elosztott verziókezelő rendszer, amelyet arra terveztek, hogy a kis projektektől a nagyon nagy projektekig mindent gyorsan és hatékonyan kezeljen.

A Gitről két dolgot el lehet mondani. Egyrészt könnyű megtanulni az egyszerűbb műveleteket, másrészt az elosztott tárolásból fakadó előnyök kihasználása, főleg a junior fejlesztőknek, gyakran zavart okoz és eredményezhet adatvesztést.

Git Hell

A szakirodalomban Git Hell néven hivatkoznak azokra a sokszor adatvesztéssel járó esetekre, amelyek főleg a kezdeti időszakban a kevésbé tapasztalt felhasználók elszenvedtek a Git használata közben. A problémákat a helytelen konfiguráció, és az alkalmazott eszközök rosszul tervezett interfésze okozta, de nem szabad elfeledkezni arról sem, hogy kezdetben a dokumentáció is szegényes, nem kifejezetten felhasználóbarát stílusban íródott, ami nem segített a parancssor megfelelő használatának elsajátításában. Szerencsére az említett problémákat mára orvosolták, és a dokumentációra sem lehet panaszunk. Mindazonáltal a Git egy erőteljes eszköz, a parancsok nem kellő körültekintő használata okozhat még kellemetlenségeket. Mielőtt egy általunk nem ismert parancsot használnánk, előtte minden esetben tájékozódjunk annak működéséről és a helyes használatról!

A Git helytelen használatából adódó problémák nem igazolják a projektmunkában bekövetkező csúszásokat

A tananyagban ismertetett parancsok és eljárások biztonságosan alkalmazhatók. Amennyiben valami kockázat adódik, azt megfelelő módon jelezzük. Ennek ellenére előfordulhat, hogy olyan parancsot kell használnunk, amely módosítja a history-t, amire maga a Git is épül. Ilyen esetben fontos utánajárni, hogy miként kell az adott parancsot használni, illetőleg annak is, hogy az adott problémát nem lehet-e kevésbé kockázatos eszközökkel megoldani. A dokumentáció ebben segít, de bármilyen kétség esetén kérdezzük meg a gyakorlatvezetőt! Ha egy parancs helytelen használata miatt adatvesztést szenvedünk el, erre nem tudunk hivatkozni, a gyakorlatvezetők ezt nem fogják indokként elfogadni abban az esetben, ha a projekt megcsúszik.

Minden parancs használatát megelőzően kérdezz és gondolkodj!

• git status
  • https://git-scm.com/docs/git-status
  • working copy aktuális állapota
• git log
  • https://git-scm.com/docs/git-log
  • Commit log lekérdezése
• git show
  • https://git-scm.com/docs/git-show
  • Künlöböző objektumok megjelenítése
  • tag, tree, commit, …

Mi az a working copy?

A working copy vagy munkapéldány a helyi Git tárhely elnevezése. Lényegében egy könyvtár, amely a projekt összes állományát tartalmazza egy rejtett .git könyvtárral együtt. A .git könyvtárban tárolja a Git az összes információt a projektedről, annak előzményeiről, a commitokról, branchekről és a konfigurációról.

Mit nevezünk repositorynak?

A repository (raktár) egy olyan tárolóhely, ahol szoftvercsomagokat tárolnak. Gyakran tartalmaz egy tartalomjegyzéket is, valamint metaadatokat. A Git esetében a repository egy teljes értékű munkamásolat, amely tartalmazza a teljes verziótörténetet és a revíziókövetési lehetőséget. Ez a munkamásolat nem függ a hálózat elérésétől vagy központi szervertől.

Commit

Ha a cheat sheeten lévő ábrára tekintünk, akkor láthatjuk, hogy a Git környezetben végzett munkát több szakaszra oszthatjuk. Mikor szerkesztjük a forrásfájlokat, ez a változás a Git számára még nem látható, ha ekkor kiadjuk a git status parancsot, akkor jelzi is számunkra, hogy az érintett fájlok nem kerültek még un. stage állapotba. A munka végeztével tehát ki kell adnunk a git add filename parancsot, vagy ha minden változást a Git tudomására szeretnénk hozni, akkor a git add . parancsot. Ebbben az állapotban a Git indexelni fogja a módosított fájlokat, azaz tudni fogja, hogy milyen módosításokat végeztünk rajta. Ebből az állapotból visszalépni a git reset paranccsal lehet, ami törli az aktuális indexet.

A stage állapot csak annyit jelent, hogy a Git követi a változásokat, de ekkor még a módosított fájlokban történő változásokról nem készül mentés. Ha pillanatfelvételt szeretnénk készíteni az aktuális állapotról a local repositoryba, akkor azt a git commit -m "Commit message" paranccsal tehetjük meg. A pillanatfelvételek megőrzésre kerülnek, ami a repository history-ban is látható lesz. A pillanatfelvételek azonosítót is kapnak, amelyek segítségével az így elmentett aktuális állapotokra bármikor vissza lehet állni.

Mi az a stage állapot?

A Git-nek, mint a legtöbb keretrendszernek van egy sajátos nyelvezete, amely első hallásra zavarónak tűnhet. Magyarra fordítani ezt a kifejezést nem is lehet (színpad), de az angol nyelvű felhasználóknak sem intuitív. Gondoljunk erre az állapotra úgy, hogy ezzel jelezzük a Git számára, hogy már dolgoztunk annyit, hogy lehetővé tegyük számára a változáskövetést és a későbbi pillanatfelvételek elkészítését.

Miként működik a verziókövetés a Git-ben?

A Git és más verziókövető rendszerek közötti fő különbség az, ahogyan a Git az adatokat kezeli. A legtöbb más rendszer az információkat fájlalapú változások listájaként tárolja. Ezek a rendszerek (CVS, Subversion,stb.) az általuk tárolt információra úgy gondolnak, mint fájlok halmazára és az egyes fájlokban az idő múlásával végrehajtott változtatásokra (ezt szokták delta-alapú verziókezelésnek nevezni). A Git ezzel szemben egy miniatűr fájlrendszer pillanatfelvételeinek sorozataként kezeli az adatokat. Minden alkalommal, mikor elmented a projekted pillanatnyi állapotát, a Git gyakorlatilag készít egy képet arról, hogy az összes fájlod hogyan néz ki abban a pillanatban, és tárol egy hivatkozást erre a pillanatfelvételre. A hatékonyság érdekében, ha a fájlok nem változtak, a Git nem tárolja újra a fájlt, csak egy hivatkozást az előző, azonos fájlra, amit már előzőleg tárolásra került.

Ha meggondoltuk magunkat a pillanatfelvételt illetően, akkor a git reset commit_azonosito paranccsal visszatérhetünk egy az azonosítóval jelzett korábbi állapotba.

A reset parancs

A git reset a HEAD pointert (ami az aktuális állapotra mutat) mozdítja el egy már meglévő állapotba. Ekkor az adott állapotot követő változások nem lesznek láthatóak, ami adatvesztéshez vezethet, ugyanis ha a két állapot között történtek (esetleg más által készített) változások, a visszaállított állapotban ez nem fog látszódni, így könnyen felülírhatjuk azokat.

A reset körültekintő használata

Csak a helyi repositoryban létező utolsó commitról történő visszalépés biztonságos.

Amennyiben a legutolsó pillanatfelvételt (már meglévő commit) ki szeretnénk cserélni, úgy erre is van lehetőség, a git commit --amend parancs segítségével.

A már rögzített változásokat a távoli repository-ba a git push paranccsal tölthetjük fel. A távoli repository-ból a változásokat a git pull paranccsal tölthetjük le.

Commit messages

A commit egyik fontos eleme az üzenet, amelyet csatolunk hozzá. Mivel egy fejlesztés csapatmunkában történik, az egyes változásokat a többi csapattag felé kommunikálni kell. Ennek platformja a commit message. Fontos, hogy a commit üzenetekben tisztán kommunikáljuk azt, hogy milyen változásokat és miért végeztünk el a forráson. A jól alkalmazott commit üzenetek segítik a többi résztvevőt a változások követésében, azok megértésében, ezáltal várhatóan a merge confliktusok száma is csökken. A megfelelően alkalmazott üzenetek abban is segítséget nyújtanak, hogy a későbbiek során is gyorsan naprakész információt szerezzünk a szoftverről, annak evolúciójáról, ami nagymértékben segíti a további fejlesztést, vagy a refaktorálást.

Ami triviálisnak tűnik nekünk, másoknak nem feltétlenül az

Sok commit üzenet nagyon szűkszavúan tálalja a változásokat, gyakran alkalmaznak olyan rövidítéseket, szlenget, vagy a fejlesztői csapat által ismert tényeket, amelyek nem szabványosak, csak szokványok, vagy éppen az adott fejlesztésre jellemzőek. Ezeket, bár a csapattagok ismerhetik, egy új fejlesztő biztosan nem fogja megérteni. Idővel változik a csapat összetétele is, és a projektek is mások lesznek. Ha a csapat később visszatér egy korábbi fejlesztéshez, az akkor használt szleng egy része feledésbe is merülhet. Kerüljük el az ilyen helyzeteket!

Mire gondolt a költő?

Biztosan felmerült már mindenkiben irodalom órán, hogy honnan tudhatja egy versből, hogy mire is gondolt a költő, amikor a verset írta. Erre a kérdésre pedig választ lehet találni, hiszen megismerhető a vers teljes kontextusa, és bár a versek tele vannak metaforikus, allegorikus kifejezésekkel, a kontextus alapján mégis megfejthetők.

De mire gondolt a "költő" az alábbi (angol) commit üzenetek írása közben?

• “I hope it is done finally!”
• "Clean"
• "WIP"
• "done"
• "Placeholder commit"
• "VM-XXX"
• "x.commit"

Kommunikációs silók

A szervezeti kultúrában kommunikációs siló néven ismerik azt a problémát, amely abból fakad, hogy az eltérő szervezeti egységek által kialakított szervezeti kultúrákban sajátos jelentése alakul ki bizonyos kifejezéseknek. Ezek a jelentésbeli eltérések megnehezítik a kommunikációt a szervezeti egységek között, hiszen az egyes szavaknak eltérő vagy többletjelentése nem lesz nyilvánvaló a másik fél számára. A silók által jelentett probléma az egyik fő oka annak is, ha egy fejlesztői csapat és az üzlet képviselői között nehezen zajlik az egyeztetés, vagy a követelmények összegyűjtése. Hasonló jelenség egy adott szakmai szegmensben is létezik, a különböző fejlesztői csapatok által használt szavak jelentése idővel szétválhat, és szét is válik az egyes csapatok, között.

Coneventional commits

A Conventional Commits specifikáció a commit üzenetek létrehozására szánt egyszerűsített konvenció. Olyan szabályrendszert biztosít, ami megkönnyíti az automatizált eszközök írását, mivel a commit üzenetekben leírt funkciókat, javításokat és változásokat egyértelműen írja le.

A konvenció szerint a commit üzenetek formátuma az alábbi:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Példa conventional commit üzenetekre:

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

A típus <type> olyan elemek halmaza, amely a commit létrehozásának szándékát jelölik. Ezek a kifejezések az alábbiak lehetnek:

• fix: bug javítása a kódbázisban
• feat: új feature létrehozását jelölik a kódbázisban
• egyéb típusok: build:, chore:, ci:, docs:, style:, refactor:, perf:, test:

A lábléc (footer) esetén a leggyakrabban használt kifejezés a BREAKING CHANGE:, vagy ! használata a type után, ami az API változást jelöli.

A változások okainak kommunikálására a továbbiakban is a description szakasz szolgál, amelyet a fejlesztőnek kell kitöltenie.

Branching model

A branch (ág) egy fejlesztési ág, amely függetlenül menedzselhető a többi fejlesztési ágtól. Technikailag a branch nem más, mint egy mutató, ami az adott fejlesztési ág kezdőpontját meghatározó commit-ra mutat.

HEAD

A HEAD a jelenlegi ág aktuális commitjára mutató különleges hivatkozás a Git-ben. Amikor ágak között váltasz a git checkout paranccsal, a HEAD változik, hogy az új ág végére mutasson. Tehát a HEAD a jelenlegi ág aktuális commitjára mutat, és minden egyes repository-ban lokálisan eltérő lehet, így minden fejlesztőnek saját HEAD-je van.

Új branch létrehozását a git checkout -b feature paranccsal tudjuk megvalósítani, ahol a feature az új branch neve.

Ha a master ágba szeretnénk a feature branchben lévő fejlesztésünket integrálni, akkor ezt a merge segítségével tudjuk megtenni a következő módon:

git checkout master
git merge --no-ff feature

Branchet a következőképpen törölhetünk (miután a fejlesztésünket a fő ágba mergeltük): git branch -d feature.

Mi is az --no-ff?

Ez a kapcsoló megakadályozza a git merge gyors előremozgását (fast forward), ha észleli, hogy az aktuális HEAD őse az összefűzni kívánt commit őse is egyben. A gyors előremozgás azt jelenti, hogy a Git egyszerűen áthelyezi a branch mutatóját az érkező commitra és ezáltal nem képez merge commitot. A kapcsoló használatával biztosítható, hogy a merge commitok mindig létrejöjjenek.

Egy fejlesztés során gyakran adódik olyan helyzet, amikor ugyanazon fájl ugyanazon sorát többen módosítják, vagy ha egy fejlesztő töröl egy fájlt, a másik meg módosítja azt. Ez konfliktushelyzetet eredményez, amelynek során a merge folyamat megáll. Ilyen esetben a következőket tehetjük:

• Használjuk a git status parancsot, hogy megtudjuk, mely fájlok tartalmaznak konfliktusokat.
• Nyissuk meg a konfliktusos fájlokat egy szövegszerkesztőben, és keressük meg a konfliktusokat jelölő részeket (pl. <<<<<<< HEAD, =======, >>>>>>> branch-name).
• Válasszuk ki, hogy melyik változatot szeretnénk megtartani, és távolítsuk el a konfliktusjelölő részeket (a fenti példában látható).
• Mentsük el a fájlt.
• Futtassuk a git add parancsot a konfliktusos fájlok hozzáadásához.
• A git commit -m "...." paranccsal készítsük el az új commitot.

A konfliktusok kezeléséről itt olvashatsz részletesen.

Merge conflict

A merge conflict (összefűzési konfliktus) olyan helyzet, amikor a Git két különálló ágban módosításokat végez ugyanazon fájl ugyanazon sorában, vagy amikor egy fájlt az egyik ág töröl, míg a másikban módosítja.

A branching modell meghatározza, hogy mikor és hogyan hoznak létre fejlesztők különböző ágakat a kódváltozások kezelésére. Például a git-flow egy ilyen elterjedt branching modell, amelyet sok szoftvercsapat használ. Ebben a modellben általában két fő ág van: a master és a develop ág. A master ág tartalmazza a stabil, kiadott verziókat, míg a develop ágon zajlik a fejlesztés. Emellett további ágakat is létrehozhatnak a különböző funkciók vagy hibajavítások kezelésére.

Branching modell kiválasztása

Fontos megjegyezni, hogy mindig a saját kontextusodat és csapatod igényeit vedd figyelembe, amikor kiválasztod a megfelelő branching modellt a projektedhez.

A leggyakrabban használt modell a git-flow, amely a következő ágakat definiálja:

• master
• develop
• feature
• release
• Hotfix

A git-flow szoftveres támogatással is rendelkezik, amelyet saját felelősségre használhatunk.

Navigálás a branchek között, parancsok összefoglalása

1. Branch létrehozása
   • Először hozzunk létre egy új branchet a jelenlegi branchből. Legyen a jelenlegi branch a master. Az új branch neve legyen new_branch, amelyet a következőképpen tudunk létrehozni: git checkout -b new_branch
   • Ezzel a paranccsal létrehoztad a new_branch nevű ágat, amely a master ágból ágazik ki.
2. Váltás a branchek között
   • Ha a master branchen állsz és szeretnél a new_branch ágra váltani, akkor a következő paranccsal teheted ezt meg: git checkout new_branch
3. Branchek listázása
4. Ha szeretnéd látni az összes létező branchet, azt az alábbi parancs segítségével teheted meg: git branch
5. A fenti parancs megmutatja a jelenlegi és az összes többi fejlesztési ágat.
6. Munka a branchen
   • Miután a kívánt branchen vagy, végezd el a módosításokat, commitokat és egyéb Git műveleteket.

Figyelj arra, hogy a munkádat mentsd el!

Fontos, hogy a branchek közötti váltás során ne felejtsd el elmenteni a munkádat, hogy ne veszítsd el a változtatásaidat.

Kidolgozott példa

1. Hozzunk létre egy motto.txt nevű fájlt a projekt gyökérkönyvtárban!
   • A fájl létrehozásához tetszőleges szövegszerkesztő használható, például a notepad.exe.
2. Fogalmazzuk meg és írjuk bele az imént létrehozott fájlba a saját motivációnkat arról, hogy miért is szeretnénk szoftverfejlesztők lenni, mi az oka annak, hogy ezt a pályát választottuk.
3. Mentsük el a munkánkat!
4. Vizsgáljuk meg a git státuszt! A létrehozott fájl nem része a stage állapotnak, ezért azt a git azt megjelöli egy new file címkével ellátva alapértelmezetten piros színnel.
   • A státusz a git status parancs segítségével tekinthetjük meg.
5. Commitoljuk a változásokat, majd vizsgáljuk meg ismételten a státuszt. Használjunk szabályos commit üzenetet!
   • Először stage állapotra kell hozni a változásokat: git add motto.txt
   • Commit git commit -m "My commit message"
   • git status
6. Az egyik csapattag pusholja a változásokat a GitLabra.
   • git push

Kódminőség biztosítása a fejlesztői környezet segítségével

A minőség és kódminőség

A minőségnek nincs standard definíciója, ugyanis a meghatározás függ attól a kontextustól, amelyben a minőségről beszélünk. A fogalom valamilyen dolognak, folyamatnak, vagy szolgáltatásnak funkciójával, illetőleg rendeltetésével kapcsolatos szintjére (jellemzően magas szintre) utal. Azt méri, hogy a dolog, folyamat, vagy szolgáltatás mennyire felel meg az előírásoknak vagy követelményeknek, és mennyire elégíti ki a felhasználók vagy érdekeltek igényeit és elvárásait.

A szoftverminőséget termékalapú megközelítésben a termék objektív és mérhető paraméterei alapján értékelhetjük. Ezek a jellemzők a funkcionalitás, megbízhatóság, hatékonyság, karbantarthatóság és hordozhatóság kategóriáiba sorolhatók (ISO/IEC 25010:2011).

A szoftver forráskódjának minősége számos szempontot ölel fel a szoftverfejlesztés területén. A fontosabb szempontok a következők:

• Kód tisztasága és olvashatósága (tiszta kód elvek)
  • Kód strukttúrája, formázása dokumentáltsága
  • Változók, függvények, metódusok, osztályok neveinek érthetősége.
• Hatékonyság és teljesítmény
  • A kód futási sebessége és memóriahasználata
  • Algoritmusok hatékonysága
• Tesztelhetőség és hibajavítás
  • Könnyű tesztelhetőség
  • Hibák gyors azonosítása és javítása
• Biztonság és sebezhetőség
  • A kód ellenállóképessége a támadásokkal szemben
  • Sebezhetőségek minimalizálása
• Modularitás és újrafelhasználhatóság
  • A kód felosztása kisebb, önálló részekre
  • A modulok újrafelhasználása más projekteken

Minőség mérése, metrikák

A forráskód minőségi jellemzőinek mérésére olyan platformok használhatók (SonarQube, SourceMeter), amelyek a forráskódból mérhető, számolható mérőszámok (metrikák) alapján szolgáltatnak objektív képet a forráskód jellemzőiről.

Forráskód metrikák

• Méret metrikák
  • Sorok száma: Lines Of Code (LOC), Logical Lines Of Code(LLOC)
  • Nyelvi elemek száma: number of namespaces(NNS), number of packages (NPKG), number of classes (NCL), number of structures (NST), number of interfaces (NIN), number of attributes (NA), number of methods (NM)
• Komplexitás metrikák
  • McCabe: McCabe(P) = elágazási pontok száma + 1
  • WMC komplexitás: Weighted Methods per Class, amely az osztály metódusainak súlyából számolt összeg. A súly lehet a McCabe komplexitás, de az utasítások száma és az LOC is.
• Öröklődés alapú metrikák
  • Öröklési mélység (szint): Depth of Inheritance Tree (DIP)
  • Number of Children (NOC), Number of Descendants (NOD), Number of Parents (NOP), Number of Ancestors (NOA)
• Kohéziós metrikák: azt mérik, hogy egy osztály metódusai mennyire szorosan függenek össze egymással
  • Lack of Cohesion On Methods (LCOM, LCOM5)
• Csatolás metrikák: azt mérik, hogy az egyes elemek mennyire kapcsolódnak egymáshoz
  • Coupling Between Object classes (CBO), Response For a Class (RFC, amely azon metódusok számát jelenti, amelyeket egy osztály meg tud hívni válaszul egy kapott üzenetre), Number of Outgoing Invocations (NOI), Coupling Between Object classes Inverse (CBOI), Number of Incoming Invocations (NII)
• Dokumentációs metrikák
  • Comment Lines of Code (CLOC), Comment Density (CD), Documentation Lines of Code (DLOC), Public Documented API (PDA), Public Undocumented API (PUA), Total API Documentation (TAD)

Bad smell

A szoftverek minőségét nagymértékben meghatározza az implementációs minta, amelyet a fejlesztő használ a fejlesztési feladat megoldása érdekében. Az egyes implementációk között találhatók olyanok, amelyek önmagukban nem hibás megoldások, de magukban rejtik annak a lehetőségét, hogy egy későbbi hiba forrásai legyenek. Ezeket a hibák például akkor kerülnek elő, ha valamilyen módosítást hajtunk végre a kód más részén és elfelejtjük módosítani a vele szorosan kapcsolódó részeket. A hibalehetőség onnan ered, hogy ezeket az implementációkat nehéz áttekinteni, megérteni, a fejlesztő könnyen átsiklik bizonyos részletek felett. Az ilyen kódrészleteket, implementációs megoldásokat bad smelleknek (code smell) nevezzük.

Bad Smell

Néhány tipikus eset, amely problematikusnak számít a szoftverfejlesztésben:

• Data Class
• Feature Envy
• Large Class
• Lazy Class
• Long Method
• Long Parameter List
• Temporary Field

Klónok

A kód olyan részei, amely más kódrészekből vett másolatokat tartlamaznak. Több lemásolt kódrészletet (clone instance) tekintünk egy klónosztálynak (clone class).

A copy&paste megoldások azért okozhatnak problémát, mert amennyiben egy módosítást szeretnénk kivitelezni, úgy azt minden másolaton (amit jellemzően nem tartunk nyilván) át kell vezetni.

A klónok számának és komplexitásának mérésére saját metrika rendszert definiáltak.

Nem minden fent említett antiminta példány jelent problémát

Vannak olyan esetek, amikor egy-egy általánosan problémásnak számító kódrészletet mégsem tekintünk annak. Ilyen esetek azok, amikor kódgenerátorokkal készítünk el kódrészleteket, például a felhasználói felületet. Amennyiben ezeket tudatosan alkalmazzuk, a minőség vizsgálatában alkalmazott audit eszközök scope-ját megszoríthatjuk, hogy az érintett kódrészleteket hagyja ki a vizsgálatból.

Szabálysértések

Szabálysértéseknek a kódban található kódolási hibákat nevezzük. Ezek a kódrészletek nem minden esetben okoznak egyből hibát, de potenciális hibaforrások. Ellentétben a fent ismertetett esetekkel (bad smell, klónok), esetükben nem a szoftverben végzett változások okoznak hibákat, hanem az érintett kódrészlet önmagában potenciális hibaforrás. Például nem ellenőrzött input, paraméterek használata, helytelen hibakezelési sorrend, nem használt kódrészletek a programban, névfeloldás ütközések, stb.

A szabálysértések lehetnek:

• Blokkolók (blocker)
• Kritikusak (Critical)
• Jelentősek (Major)
• Alacsony jelentőségűek (Minor)
• Információk (Info)

Szabálysértést vizsgáló eszközök

A Java környezethez található toolok közül hármat mutatunk be, amelyek mind az IntelliJ IDEA, mind az Eclipse esetében használhatók. Ezek a toolok a következők:

• SpotBugs, amely a FindBugs leágazása közel 400 hiba detektálására alkalmas (pl. inicializálási problémák, erőforráshasználati problémák, hatékonyság, sérülékenységet okozó kódrészletek, stb.).
• PMD, amely olyan hibás programozói gyakorlatok azonosítására alkalmas, mint az üres catch blokkok, nem hsznált változók, felesleges objektum definíciók, stb.
• Checkstyle, amely a forráskód a kódolási standardoknak történő megfelelését vizsgálja, mint például a helyes tabulálás, zárójelek használata, kommentek használata, névkonvenciók, méretezések, stb.

IntelliJ esetében a következő elemzőket telepítjük:

• SpotBugs telepítése:

  • Navigáljunk a következő oldalra: JetBrains Marketplace SpotBugs és kattintsunk a GET nyomógombra.
  • Válasszuk ki az IntelliJ verziót (community, ultimate)
  • Válasszuk ki a plugin verziót és kattintsunk a download linkre.
  • Az IntelliJ felületen belül nyissuk meg a beállítások menüt. (CTRL-ALT-S)
  • Kattintsunk a plugins menüre.
  • A fogaskerék ikonra kattintva keressük meg az Install plugin from disk menüpontot.
  • A dialógusban keressük meg a letöltött plugint és kattintsunk rá. (spotbugs-idea-1.2.5.zip)
  • Indítsuk újra a keretrendszert.

  

• PMD telepítése:

  • A link a következő: PMD plugin
  • Navigáljunk a fenti linkre és kattintsunk a GET nyomógombra.
  • Válasszuk ki az IntelliJ verziót (community, ultimate)
  • Válasszuk ki a plugin verziót és kattintsunk a download linkre.
  • Az IntelliJ felületen belül nyissuk meg a beállítások menüt. (CTRL-ALT-S)
  • Kattintsunk a plugins menüre.
  • A fogaskerék ikonra kattintva keressük meg az Install plugin from disk menüpontot.
  • A dialógusban keressük meg a letöltött plugint és kattintsunk rá. (PMDPlugin-1.8.26.zip)
  • Indítsuk újra a keretrendszert.

• Checkstyle telepítése:

  • A kövektkező linken érhetjük el: Checkstyle Intellij Plugin
  • Navigáljunk a fenti linkre és kattintsunk a GET nyomógombra.
  • Válasszuk ki az IntelliJ verziót (community, ultimate)
  • Válasszuk ki a plugin verziót és kattintsunk a download linkre.
  • Az IntelliJ felületen belül nyissuk meg a beállítások menüt. (CTRL-ALT-S)
  • Kattintsunk a plugins menüre.
  • A fogaskerék ikonra kattintva keressük meg az Install plugin from disk menüpontot.
  • A dialógusban keressük meg a letöltött plugint és kattintsunk rá. (CheckStyle-IDEA-5.83.0.zip)
  • Indítsuk újra a keretrendszert.

Az Eclipse-ben a következőképpen kell telepíteni:

• SpotBugs telepítése:
  • Help -> Eclipse Marketplace
  • Find: spotbugs; SpotBugs Eclipse plugin 3.1.5 ->Go
• PMD telepítése:
  • Help -> Eclipse Marketplace
  • Find: checkstyle; pmd-eclipse-plugin 4.28.0 ->Go
• Checkstyle telepítése:
  • Help -> Eclipse Marketplace
  • Find: pmd; Checkstyle Plug-in 8.44.0 ->Go

Az elemzők használata

Az összes elemző elindítható a projekt kontext menüjéből az érintett objektumon állva a ProjectExplorer ablakban.

Az eredmények a kódban és külön ablakban is megjelennek, utóbbiakat megfelelő menüből tudjuk bekapcsolni (ha nem jelennek meg automatikusan): Window -> Show View -> Other ...

Elemző toolok konfigurációja

A statikus elemző eszközök megfelelő konfigurációja biztosítja, hogy az általunk végzett elemzés a projekt szempontjai szerint történje. Az ilyen eszközök egyrészt nagy mennyiségű hibát képesek jelenteni, ami adott esetben kontraproduktív lehet. (10 hibát a fejlesztő szívesen átnéz, de ha 10.000 hibát teszünk elé egyszerre, bele sem fog kezdeni.) Konfiguráljuk ezért úgy az eszközöket, hogy csak a fontosabb hibákat mutassa.

De mik is a fontosabb hibák?

Ez egyén, szervezet és helyzet függő. A konkrét bug-okra, lehetséges meghibásodásokra utaló warningokat általában fontosabbnak tartjuk, míg a formai hibákat kevésbé. Hosszútávon ugyanakkor lehet, hogy a rosszul formázott kód karbanatartása nagyobb költséggel jár, tehát a kapcsolódó találatok szintén fontosnak minősíthetők.

Az elemző toolok konfigurációit az alábbiak szerint módosíthatjuk:

• CheckStyle
  • File -> Settings
    
  • Paraméterezése az XML file szerkesztésével lehetséges (általában a checkstíyle.xml a konfigurációs fájl neve, de ez változhat). A szabályok finomhangolása (pl. moximális sorméret megadása) is ebben a fájlban történik.
• SpotBugs
  • File -> Settings
    
  • Szabályok bővítése pluginok útján lehetséges.
• PMD
  • File -> Settings
    
  • A szabálygyűjtemények között egy alap szabálygyűjteményt is definiáltak a fejlesztők, amely a futtatható csomag része.
  • Az alapvető szabályok mellett van támogatás egyéb technológiákra is (JSP, JSF, JUnit...)
  • Új szabályok írhaók Java-ban és/vagy XPath segítségével

Az Eclipse esetén a következő elérési utakon módosíthatjuk a beállításokat:

• SpotBugs
  • Projekt kontext menü -> Properties -> SpotBugs
  • Configure Workspace Settings
• CheckStyle
  • Window menü -> Preferences -> CheckStyle
  • New or Copy -> Configure...
• PMD
  • Window menü -> Preferences -> PMD -> Rule Configuration