Skip to content

Kategória: Praktikák

Issue Tracking

Miért?
Csak azt nem felejti el az ember, amit felír, és csak azt fogja tudni hatékonyan delegálni és nyomon követni.

Minden „issue” strukturált menedzselése már csak azért is szükséges, hogy semmi ne tűnjön el. Csak akkor lehet a pontokat priorizálni illetve sorrendbe rakni, ha van lehetőség a pontok áttekintésére. Ehhez nincsen feltétlen szükség kifinomult eszközökre, egy tábla papír cetlikkel is megteszi. És legfőképpen nem az eszköznek kellene itt az előtérben lennie, hanem magának a tevékenységnek.

Lásd az eszközök alatt.

Automatizált integrációs tesztek

Miért?
Az integrációs tesztek gondoskodnak arról, hogy a kód azt tegye, amit tennie kell. Ezt a rendszeres tevékenységet nem automatizálni időpocsékolás volna.

A legalapvetőbb feltételét a kód megváltoztatásának már a piros fokozaton lefektettük a verziókövető rendszer használatával. Aggodalom nélkül változtathatunk a kódon, egész fájlokat vagy könyvárakat törölhetünk le, a verziókövető rendszerből mindezt újra ki lehet venni.Amikor csak változtatásokat eszközölünk a kódon, mindig biztosnak kell lennünk abban, hogy semmit sem rontottunk el. És erre a biztonságra csak akkor tehetünk szert, ha a változtatások után teszteljük, hogy az alkalmazás úgy viselkedik-e, mint előtte. Ezeket a teszteket minden változtatás után kézzel végrehajtani nem volna megoldható, automatizálnunk kell azt. A szoftverfejlesztés egyik nagy baja a félelem attól, hogy valami fölött elsiklik a figyelmünk, hogy egy részletre nem terjed ki a figyelmünk, és ezáltal hibát okozunk olyan kódban, ami előzőleg működött. És ennél még az sem játszik szerepet, hogy a változtatások ahhoz vezetnek-e hogy javítjuk a kódot (refaktorálunk) vagy új követelményeknek megfelelően bővítettük azt. Addig amíg nem vagyunk biztosak benne, hogy a minden úgy működik, ahogyan előtte, addig marad a félelem. Ez ahhoz vezet, hogy kétség esetén a kódot úgy hagyjuk, ahogyan van, hiszen az működik. A szükséges refaktorálásokat elmulasztják a hibázás miatti félelemből.

Ahhoz, hogy a már futó projektekben (un. Brownfield projetekeben, ellentétben a Greenfield „zöldmezős”) meg tudjuk teremteni a biztonsági hálót, olyan eljárásokra van szükség, amiket a meglévő kódra lehet alkalmazni. Ehhez alkalmasak az automatizált integrációs tesztek. Vagy a felhasználói felületen kezdjük ezt el, és végig tesztelünk az alkalmazást összes rétegen keresztül, vagy lejjebb kezdjük el. Mindkét esetben több funkcionális egység összjátékát teszteljük.

Tehát mielőtt változtatásokat eszközölnénk a kódon, az érintett kódterületek lefedésére integrációs teszteket hozunk létre. Persze ebben a folyamatban használhatunk olyan eszközöket, mint a WatiN, UI Automation stb. Kívánatosak volnának persze a unit tesztek is, amelyek az egyes funkcionális egységeket elszigetelten tesztelik. Ehhez azonban a kódnak bizonyos feltételeknek kell megfelelnie, melyek vélhetően nem mindig adottak: a kódnak tekintettel kell lennie a Single Responsibility-elvre. Ellenkező esetben az egyes funkcionális egységek (komponensek, osztályok, eljárások) között olyan nagyok lesznek a függőségek, hogy nem lehet őket elszigetelten tesztelni. A távlati cél természetesen egy olyan kódbázis, amelyen lehetségesek a unit tesztek. Sőt, a jövőben a teszteket az implementálás előtt fogjuk létrehozni (Test first). De ahhoz, hogy a refaktorálással odáig el tudjunk jutni, először integrációs tesztekre van szükség, hogy biztosra mehessünk, az alkalmazás még mindig úgy viselkedik, mint a refaktorálás előtt.

Lásd az Eszközök alatt.

Olvasni, olvasni, olvasni

Miért?
A olvasás műveltté tesz!

Az olvasás műveltté tesz – mi meg vagyunk győződve arról, hogy ez szoftverfejlesztőkre is igaz. A szoftverfejlesztés továbbra is fejlődik. A nagy fejlődési lépések mellett, mint a procedurális programozás, objektumorientált programozás, funkcionális programozás, aspektusorientált programozás stb. folyamatosan vannak előrelépések kisebb területeken, amivel a szoftverfejlesztőknek foglalkozniuk kell. Vannak például technikák, mint a Dependency Injection vagy a Object Relational Mapper. De ezekben a technikákban is vannak fejlődési lépések, mint például a Domain Specific Languages (DSLs) a konfigurálás az XML alapú konfigurálással szemben. A szoftverfejlesztés technikai aspektusain kívül a folyamatot is fejlesztik. Így általánossá vált az a felismerés, hogy a vízesésmodell nem működik, és különböző agilis módszereket fejlesztettek ki. Mindezt a Clean Code fejlesztőnek szem előtt kell tartania.

Ezért azt javasoljuk, hogy évente legalább 6 szakkönyvet olvassunk el. Továbbá rendszeresen kellene periodikákat olvasni, ami alatt szakmai folyóiratokat és blogokat is értünk.

Javaslatokat az irodalomjegyzékben találhatunk.

Review-k

Miért?
Négy szem többet lát, mint kettő. Amikor egy fejlesztő elmagyarázza a kódját egy másik fejlesztőnek, akkor általában olyan részletek merülnek fel, amelyekre eddig nem fordított figyelmet.

A review-k ezért kétféle formában fordulnak elő: mint folyamatos páros programozás (pair programing) és mint önálló folyamatelem a code review. A cél mindkét esetben ugyanaz: a kódot véleményezze egy másik fejlesztő is. Ezzel el lehet kerülni az „üzemi rövidlátást”. Már az a tény, hogy egy fejlesztő a kódját bemutatja és a másiknak és elmagyarázza azt, már ez is aha élményekhez vezet.Általában más fejlesztőkkel való beszélgetések során derül ki egy kódbázisról, hogy hol találhatók az erősségei és gyengeségei. Éppen a folyamatos javítások folyamata követeli meg, hogy más fejlesztők meglátásaival szembesüljünk és azokat megvitassuk.

Természetesen nem csak a forráskód alkalmas review-k alapjául. Ezek kedvező lehetőséget teremtenek arra, hogy minden fejlesztési tevékenység eredményét megvizsgáljuk, amennyiben ezek írásos formában rögzítésre kerülnek. A teljesen informális review-k, mint a páros programozás (pair programing) vagy a második személy általi véleményezés mellet van a formális review egy review eljárással és a megfelelő szerepekkel. További ismert fajtái a review-nak a Walkthrough, technikai review, peer review és az inspekció.

A review-k kiegészítik a dinamikus teszteket, mint az automatizált unit teszteket és az automatizált integrációs teszteket a sárga fokozatból ill. a narancs fokozatból. Ezekkel a tesztekkel szemben a review-k nagyon is alkalmasak arra, hogy hibákat fedezzünk fel a követelmények között. Ha a fejlesztési folyamatban idejekorán szerepelnek, akkor nagyon korán fel lehet ismerni az ilyen hibákat. És minél korábban találunk meg hibákat, annál költségkímélőbb a kijavításuk.