Skip to content

Kategória: Praktikák

Continuous Integration

Miért?
A szoftvergyártás automatizálása és centralizálása produktívabbá tesz és csökkenti a kiszállításkori hibák veszélyét.

Gyakran a szoftverkomponensek integrációját időben hátra tolják és fáradságosan, hibára hajlamosan „kézzel” hajtják végre. De tulajdonképpen a szoftvernek minden időpontban teljesen futásképesnek kell lennie. A Continuous Integration-nel egy olyan folyamatot jelölnek, amely gondoskodik arról, hogy változtatások bevitele után a teljes kód leforduljon és tesztelődjön.A Continuous Integration folyamat főképpen team-eknek fontos, mert gondoskodik arról, hogy változtatások megtétele utána a teljes kód lefordul és tesztelődik, nem csak az a rész, amelyen a fejlesztő éppen dolgozott. Az automatizált teszteket mindegyik fejlesztőnek végre kell hajtania, mielőtt felvinné a változtatásait a központi verziókezelőbe. Ezen a Continuous Integration nem változtat semmit. Ahhoz hogy biztosítva legyen, hogy a tesztek mindenképpen lefussanak és a hibákat idejekorán észlelni lehessen, a Continuous Integration szerveren mindenképpen le kell futniuk. Ez nem szabadítja fel a fejlesztőt azalól, hogy a teszteket minden commit előtt végrehajtsa, hiszen a verziókezelőbe bevitt hibás kód a teljes team-et hátráltatja, sőt előfordulhat, hogy további team-eket is. Így a Continuous Integration folyamat arról gondoskodik, hogy team-eken átívelően a hibákat a lehető legkorábban felismerjük.

A Continuous Integration folyamathoz számos szoftvereszköz áll rendelkezésre. A folyamatos buildelésen és tesztelésen kívül, ami azonnal megtörténik, amint változtatások kerülnek a verziókövető rendszerbe, a Continuous Integration hosszabban futó folyamatokat, mint pl. adatbázistesztet is, automatizálhatóvá tesz. Ezeket pl. csak éjszakánként hajtja végre. A zöld fokozaton csak a buildelési és teszt folyamatokat kell figyelembe venni. A szoftver folyamatos setup-ja és kiszállítása csak később, a kék fokozaton történik.

Martin Fowler egy nagyon jó cikket írt erről a témáról: http://www.martinfowler.com/articles/continuousIntegration.html

Lásd az eszközök alatt.

Statikus kódanalízis (metrikák)

Miért?
A bizalom jó, de az ellenőrzés jobb – és minél jobban automatizálva van, annál könnyebb.

Hogyan határozható meg egy kódrészlet minősége, pl. egy osztályé vagy egy komponensé? Elegendő az, ha a megrendelői követelményeknek funkcionálisan eleget tesz? Elegendő az, hogy elég gyors és eléggé skálázható? Az automatikus tesztek és végül a megrendelő tesztjei fognak erről felvilágosítást nyújtani. Az ilyen követelménynek való megfelelések nélkül a szoftvernek természetesen nincsen releváns minősége. Ha nem használ a megrendelőnek, minden további kérdés feleslegessé válik.A másik oldalon viszont nem elegendő, minden széleskörben elterjedt feltételezéssel ellentétben, a követelményeknek való megfelelés. A jó minőség nem csupán a funkcionalitásból és pl. a performanciából áll. Mert a funkcionális és nem funkcionális követelmények mellett van egy általában kimondatlan, rejtett követelmény: A megrendelők általában azt akarják, hogy a szoftver ne csak ma feleljen meg a követelményeknek, hanem holnap és holnapután is. A megrendelők befektetésvédelmet szeretnének továbbfejleszthetőség által.

A megrendelők számára ez a követelmény általában implicit. Azt hiszik, hogy ez magától értetődő, hogy egy immateriális termék, mint egy szoftver kvázi a végtelenségig fejleszhető és gombnyomásra az új követelményekhez igazítható. Gyakran azok a vezetők is ezt hiszik, akik nem a szoftverfejlesztésből kerülnek ki. Sőt még maguk a szoftverfejlesztők is!

Nem is lehetne nagyobb a félreértés a szoftverek körül. A továbbfejleszthetőség sem a szoftverfejlesztők által mindenképpen követett célok értelmében magától értetődő, sem pedig nem adódik valamiből kvázi magától. A továbbfejleszthetőség sokkal inkább kemény munka eredménye, melyet folyamatosan egyéb értékekkel szemben kell mérlegelni.

Amikor egyéb követelménynek való megfelelést csak (automatizált) tesztekkel lehet megállapítani, hogyan állunk akkor a továbbfejleszthetőséggel? Lehet a kód minőségét a túlélőképessége tekintetében automatikusan is mérni? Részben. Nem minden aspektusát lehet annak automatikusan ellenőrizni, ami a szoftvert továbbfejleszhetővé teszi. Például, hogy a szoftver nyitott-e a bővítésre az Add-In koncepció szerint, azt nem lehet automatikusan felismerni.

Mégis vannak metrikák, melyek értéke egy szoftver számára „kiszámítható”. Eszközök segítenek ebben. Ezeket az eszközöket tehát minden szoftverprojektben be kellene vetni.

  • Ezek az eszközök képesek a régebbi kódot státusz quo-nak használni, és ez alapján egy alapvonalat meghatározni, amivel a kód további fejlesztését (javítását) össze lehet hasonlítani.
  • Az új kódnál, amit a továbbfejleszthetőség szempontjából terveztek, a statikus kódanalízis azt mutatja meg, hogy a tervezés ideális állapotát elérte-e.

A Clean Code fejlesztő nem elégszik meg azzal, hogy automatizáltan tesztelje a kódot. Az egyik szemünk mindig a továbbfejleszthetőségen van, mert tudjuk, hogy a megrendelő ebben ugyanannyira érdekelt – mindegy, hogy explicit mondta-e vagy sem.

Lásd az eszközök alatt.

Inversion of Control Container

Miért?
Csak azt lehet könnyen konfigurálni, ami nincsen szorosan bedrótozva.

Már a sárga fokozaton megismerkedett a Clean Code fejlesztő a Dependency Inversion Principle-lel. Akkor még a függőséget „kézzel” oldottuk föl. A következő logikus lépés abból áll, hogy a függőségek feloldását automatizáljuk. Ehhez két eljárás áll rendelkezésre:

  • Locator
  • Container

Mindkettő egy úgynevezett Inversion of Control Container-t (IoC konténer) használ. A konténer használata előtt a használt osztályokat el kell helyezni a konténerben. Ezek után a konténer az elhelyezett osztályokból példányokat tud adni. A Locatornál ez explicit történik. Ennek az az előnye, hogy a függőségeket nem kell mind az osztály konstruktorában felsorolni. A keresztmetszeti feladatoknál, mint pl. a loggolás, ez egy általánosan elfogadott eljárás. Azonban a függőségeket rendszerint a konstruktor paraméterében sorolják fel. Ennek az az előnye, hogy minden függőség láthatóvá válik. Így a konténer képes arra, hogy a függőségeket implicit feloldja azáltal, hogy minden szükséges objektumot rekurzív példányosít.

Az IoC konténerek akkor válnak különösen fontossá, amikor az osztályok száma nő. Ha megszívleljük a Separation of Concernst, akkor sok kis osztály keletkezik átlátható feladatokkal. Ezeknek az osztálypéldányoknak összeállítása ennek megfelelően válik költségessé. Éppen itt lép akcióba az IoC konténer, segít a példányosításban és összeköti a sok kis objektumot.

Az IoC konténernek egy további előnye az a tény, hogy meg lehet határozni a konfigurációban egy objektum életciklusát. Amennyiben a futásidőben egy objektumnak csak egyetlen egy példánya létezhet (Singleton), akkor a konténert utasítani lehet, hogy mindig ugyanazt a példány adja vissza. Más életciklusokat is támogat, mint pl. egy példány session-önként.

Ahhoz, hogy a Locator használatakor ne egy bizonyos IoC konténer függőségbe csöppenjünk, lehet a Microsoft Common Service Locator-t (lásd eszközök) használni. Ez egy egységesített interfészt kínál a használatos IoC konténerekhez.

Egy ilyen IoC konténer mechanizmusának megértéséhez hasznos lehet az, hogy egyszer ezt a funkcionalitást magunk implementáljuk. Nem kell a teljes konténert implementálni, elég az alapfunkcióját.

Lásd az eszközök alatt.

A tapasztalatok továbbadása

Miért?
Aki továbbadja a tudását, az nem csak másoknak segít, hanem magának is.

A professzionális munkához természetesen aktuális tudás tartozik. Ez természetesen nem azt jelenti, hogy valakinek mindent kell tudnia a szoftverfejlesztésről vagy csak a .NET platformról. Az aktuális tudás az ember speciális területére vonatkozik – bármi légyen is az. Ezért a többi fokozat praktikáinak része a rendszeres információfelvétel a különböző médiumokból.

Több okból azonban egy ilyenfajta információgyűjtés a „tanulás”-éremnek csak az egyik oldala. A másik az információ továbbadása, a tudás megosztása. Az igazi professzionalitáshoz szerintünk nem csak a „kutatás”, hanem az „oktatás” is hozzá tartozik. Hiszen csak az „oktatás”-sal történik meg a tárgy valódi reflektálása és átlátása.

Az, hogy használjuk azt, amit hallottunk/olvastunk, az csak az egyik oldal. Természetesen felmerülnek megértési hiányosságok. Egy tárgy tanulmányozása azonban az erőfeszítés oka miatt természetesen korlátozott. Aki csak annyit kutat, amennyire egy technogiához/koncepcióhoz éppen szüksége van, az nem merül le túl mélyre.

Egészen másképpen van ez, ha a tanulás a továbbadás jegyében történik. Aki nem mindig csak magának, hanem mindig másoknak is tanul, az mélyebben sajátítja el a dolgokat. Ez akkor válik világossá, amikor az ember megpróbál (állítólag) megtanult dolgokat másoknak átadni. Ha erre nem vagyunk tekintettel a tanulás során, akkor gyorsan olyan kérdések merülnek fel, amelyeket soha sem tettünk fel magunknak. Másoknak mindig egészen más perspektívájuk van.

Ezért gondoljuk úgy, hogy csak az tanul valóban alaposan, aki újra és újra kiteszi magát a továbbadásnak és a tudás megosztásának. Csak aki a megtanultakat nem csupán használja, hanem saját szavaival megfogalmazza egy publikum számára, veszi észre ebben a folyamatban, hogy milyen mély is valójában az ő saját tudása. Mert, ha a „tanulók”-nál gyűlnek a kérdőjelek, akkor valami még nem egészen kerek.

Erre természetesen egy valódi publikum a legalkalmasabb. Minden Clean Code fejlesztőnek rendszeresen kellene keresni a lehetőséget, hogy a tudását szóban továbbadja (pl. rendezvényeken, kollégák körében vagy fórumokon). A közvetlen visszajelzésben biztos lehet. Ennek alternatívájaként vagy kiegészítéseként az írásos kompetencia-megnyilvánulások is megfelelők. Egy blogot 5 perc alatt össze lehet rakni és a szakmai folyóiratok folyamatosan keresik a szerzőket. Az ilyen helyeken ugyan nem annyira közvetlen a visszajelzés, de az írásos megfogalmazása az ismereteinknek nagyon jó gyakorlat.

A Clean Code fejlesztők a zöld fokozattól tehát már nem csak „passzívan” tanulnak, hanem „aktívan” is a tudásuk továbbadásával prezentációkban vagy írásos szövegekben. Ez lehet, hogy szokatlan – de talán a Continuous Integration is szokatlan. Mindenesetre az aktív tudás átadása jó gyakorlat a saját kompetenciáink továbbmélyítésére. „Tégy jót és beszélj róla” 😉

Magától értetődő, hogy a tanítás használ a hallgatóknak/olvasóknak is. Mások előnye nem annyira motiváló, mint a saját előnyünk. Ezért hangsúlyozzuk itt a tudásátadás hasznát a Clean Code fejlesztő számára.

A hibák mérése

Miért?
Csak az tudja úgy megváltoztatni az eljárását, hogy csökkenjen a hibarátája, aki tudja, hogy mennyi hiba lép fel.

A szoftverfejlesztés alatt hibák lépnek fel. Ezek minden fázisban előfordulnak: rosszul értett vagy nem elég világosan megfogalmazott követelmények ugyanúgy hibához vezetnek, mint a hibás implementálás. A végén minden olyasmi hiba, ami ahhoz vezet, hogy a megrendelő olyan szoftvert kap, ami nem felel meg az ő követelményeinek. Az iteratív eljárás és a reflektálás két elem a folyamat javításához vezető úton. Egy olyan mérési értékre van szükségünk, amiből a jobbrafordulás lemérhető, ahhoz, hogy felismerjük, valóban állt-e be javulás.A hibák mérése megszámlálással vagy időszakítással történhet. Amíg a mérési módszer összehasonlítható adatokkal szolgál, addig nem a precizitás lesz előtérben. A több iteráción átívelő fejlődési tendenciának leolvashatónak kell lennie. Továbbá nem az a lényeg, hogy egy adott hibának a felelősét megtaláljuk. Végülis mindegy, hogy ki okozta a hibát, amíg a team tanul belőle és javít a folyamatán.

Mely hibákat kell mérni? Nem azokat a hibákat, amelyek a fejlesztés alatt lépnek fel. Ezeket nem lehet elkerülni, és remélhetőleg oda vezetnek, hogy az iteráció végén egy hibamentes termék kerül kiszállításra. Sokkal inkább azokról a hibákról van itt szó, melyeket az iteráció után a megrendelő ill. a helyettese (pl. product owner vagy a terméktámogatás) jelez. Ezek azok a hibák, amelyek az új követelmények megvalósítását akadályozzák. A mérendő hibák tehát azok, amelyek akkor lépnek fel, amikor az ember azt hiszi, hogy nem is volna szabad létezniük. 😉 Team-től függően kell meghatározni, hogy a folyamatban a team mikor éri el ezt a pontot és kezd szitkozódni, mert már megint egy hiba gátolja az egyéb munkák elvégzését.