Aki már csinálta, tudja, hogy mindennek megfelelni szinte lehetetlen, nagy a nyomás az ügyfél, a menedzsment és természetesen a fejlesztők oldaláról is. Mondhatjuk persze, hogy megfelelő előkészítéssel, tervezéssel és egy jó csapattal azért megoldható. Ám tegyük egy pillanatra a kezünket a szívünkre, fordult-e már elő, hogy mindezek ellenére valami mégis közbejött, pár dolog megcsúszott, kidőlt egy csontváz a szekrényből, megváltoztak az igények menet közben? Valószínűleg a válasz igen, sőt lehet, hogy ez nem csak egyszer, elvétve fordult elő, hanem többször, egymásután, vagy akár szinte mindig.
Aztán ha csúszunk, akkor jönnek az egyszerűsítések: nem kell ez a feature, a másikat elég lesz egyszerűbben is megcsinálni, itt-ott egy-két ideiglenes megoldás, automata tesztek helyett elég lesz csak kézzel kipróbálni, vagy majd az ügyfélnél teszteljük... Ezek után, amikor jön a továbbfejlesztés, a csontvázak már előre be vannak építve a rendszerbe, persze lehet majd refaktorálni, rendet rakni, csak ki lesz az, aki hozzá mer nyúlni a kódhoz? Hiszen ami most van, az legalább működik, ne próbáljuk megjavítani azt, ami nincs eltörve, nem?
A legtöbb esetben a probléma nem akkor jelentkezik, amikor valaki megír egy kódot, hanem amikor valaki más – vagy akár az eredeti szerző később – hozzányúl, belejavít, kiegészíti. Ilyenkor kezd el a kód minősége romlani, főleg ha jönnek az új funkciók, az új elvárások és persze az időnyomás, ezek pedig általában mindig kikerülhetetlenek.
Ilyen esetekben a szokásos első reakció, hogy megpróbálunk még részletesebben tervezni, felkészülni még aprólékosabban és még több lehetőségre. Megszorozzuk a fejlesztői becsléseket kettővel, hárommal, ízlés és tapasztalat szerint. A tervezésre, előkészítésre szánt idő tovább nyúlik, a fejlesztés lassul, a határidő csúszik, a végén pedig újra jön az egyszerűsítés – és jó, ha egyáltalán valami működőt lehet az ügyfélnek leszállítani.
Sajnos, végeredményben – legyünk akár megrendelők, vagy szállítók – itt a probléma. Megrendelőként persze kiköthetünk kötbért, de a csúszás akkor is fáj, a továbbfejlesztés lassabb és drágább, azaz nehezebben tudunk reagálni a változó üzleti igényekre, hátrányba kerülhetünk a versenytársakkal szemben, és csak reménykedhetünk, hogy náluk sem jobb a helyzet.
Nehéz ebből az ördögi körből kitörni – aki már átélte, tudja, aki éppen benne van, az keresi a kiutat.
Szerencsére nem vagyunk egyedül, a probléma megoldásán már sokan gondolkoznak és több különböző válasz is született vagy éppen jelenleg is formálódik. Ennek eredményeként jött létre több agilis módszertan: SCRUM, Kanban, eXtream Programing, Pair programing, stb. A lista hosszú. Nem lehet kijelenteni, hogy ezek közül valamelyik a legjobb vagy legbiztosabb, hiszen a szervezetek különbözőek, mint ahogy a feladatok és az elvárások is, nincs csodafegyver, érdemes kipróbálni többet, és kiválasztani a leginkább testhez állót. Egy a fontos: nyitottnak és agilisnak kell lenni.
Mi is végigjártuk a magunk útját, még most is járjuk, sőt talán a legfontosabb felismerés az, hogy ennek az útnak soha sincs vége. Nincs egy cél, ahol megpihenhetünk és hátradőlhetünk, hanem folyamatosan fejlesztenünk kell magunkat, a kollégákat, a módszereket. Rémisztő? Szerintem inkább inspiráló!
Ezen az úton mi is eljutottunk egy módszertaning, amely megtetszett nekünk és jelenleg is alkalmazzuk. Nem csodafegyver ez sem, bár a talpáról a tetejére állított sok mindent a fejlesztésen és a fejekben. Ez a módszertan vagy inkább megközelítés a Test Driven Development (TDD), avagy a tesztelésvezérelt fejlesztés. Hadd meséljek kicsit erről és a mi tapasztalatainkról.
Az iskolában megtanultuk, hogy a szoftverfejlesztésnek három nagyon fontos fázisa van: az első a tervezés, a második a fejlesztés, a harmadik pedig a tesztelés. A TDD gyakorlatilag megfordítja ezt: először tesztelünk, majd fejlesztünk, aztán amikor ezzel is készen vagyunk, akkor megtervezzük, vagy inkább újratervezzük az egészet. Elsőre meredeknek hangzik, nem? Nézzük meg gyorsan, hogyan működik ez a gyakorlatban!
Lényege a TDD-nek, hogy a tesztelés-fejlesztés iterációk gyorsan pörögjenek. Első lépésként az elvárásoknak megfelelően elkészül az első teszteset, amely természetesen egyből hibázik. A fejlesztés részeként pedig egy a cél, kipipálni a tesztesetet, azaz éppen csak annyit fejleszteni, amennyi a tesztesethez szükséges. Ha ez megvan, akkor jöhet a második teszteset, majd az ahhoz tartozó fejlesztés, ahol viszont az első teszteset biztosítja, hogy ne rontsunk el semmit, ami már egyszer működött. Ilyen kis lépésekkel jut el a fejlesztés oda, hogy elkészüljön az alkalmazás az összes elvárásnak és funkciónak megfelelően.
Az biztos, hogy e módszerrel nem fordulhat elő, hogy a tesztesetek lemaradnak a fejlesztés végén, de joggal kérdezheti bárki, hogy hol marad az architektúra megtervezése, illetve nem lesz-e teljesen szedett-vedett a kód? A kérdés jogos, és e ponton jutunk el a tervezés fázishoz. Miután megvannak a tesztesetek és a kód is kész, jöhet a refaktorizáció, avagy a kód és az architektúra rendberakása. A lényegi különbség a TDD esetében, hogy a fejlesztők bármilyen módosítás után a tesztesetekkel egyből ellenőrizhetik, hogy nem törtek-e el valamit, azaz kis kockázattal lehet nagyobb kódmódosításokat is elvégezni. A refaktorizáció a TDD esetében nem egy külön – nagy kockázatú – projekt, hanem a fejlesztés egy folyamatos eszköze, ez garantálja, hogy a kód ne kezdjen el romlani, hanem a folyamatos változások után is megőrizze minőségét.
Amint funkcionálisan elkészül valami és a teszteset működik, egyből jön a kód rendberakása, ezáltal az architektúra folyamatosan közelít az ideálishoz. Nem kell esetleges jövőbeli funkciókra már előre felkészülni, nincs szükség nagy átalakítási projektekre, amikor új igények merülnek fel, és nincsenek feleslegesen előre lefejlesztett modulok, amelyek esetleg majd jók lesznek valamire. Az készül el, amire szükség van, más nem. Cserébe – az igények menet közbeni változtatása esetén – csak a teszteseteket kell módosítani vagy kibővíteni, és a fejlesztés részeként javítani őket. Az architektúrát pedig szintén könnyebb később ehhez hozzáigazítani. A folyamatos refaktorizáció, rendrakás a kulcs a TDD működőképessége szempontjából, gondoskodni kell arról, hogy ez ne maradjon el, tényleg beépüljön az alaprutinba.
A tesztesetek előre való elkészítésének a másik fontos előnye az, hogy a fejlesztőknek már a fejlesztés kezdetén meg kell érteniük a követelményeket. Azzal, hogy tesztelést első helyre helyezzük, egyenrangúvá válik a fejlesztéssel, ez segít csökkenteni a fejlesztő és a tesztelő közötti távolságot, sőt jobban kényszeríti a fejlesztőket a tesztelésre. Nagyon fontos, hogy ezek után az automata tesztek minősége kritikus, azokat úgy kell kezelni, mint a termék saját kódjait.
Nem csodafegyver a TDD, nem old meg minden problémát, de új szemléletet képvisel a fejlesztésben. A változás főleg a napi rutinokban és a fejekben nem megy egyik napról a másikra, a meglévő kódokat is csak lassan lehet megtisztítani, az automata-teszteseteket elkészíteni – az elején befektetést igényel, ami csak a később térül meg. A TDD-nek is megvannak a maga hibái, buktatói, amelyek odafigyelést és energiát igényelnek. A menedzsmentnek és a megrendelőnek is meg kell értenie a módszert, támogatnia kell és nem utolsó sorban kihasználnia a TDD adta lehetőségeket.
