delZubu blog

Épp lezártam egy kéthetes .net oktatást. Kicsit másfajta munka volt ez, mint a szokásos fejlesztés, és persze nem is volt meg az a rutinom, úgyhogy több energiát kellett beleölni, de azt hiszem, sikerült többé-kevésbé jól teljesíteni. Legalábbis a tanulók eljutottak arra a szintre, hogy önállóan képesek legyenek projekten működni, és ez is volt a cél.

Mondjuk hogy tényleg elérték-e ezt a szintet, az majd csak a következő pár hétben derül ki, de én bizakodó vagyok.

Milyen tapasztalatokat szereztem? Mik azok, amikkel az egyszeri konzulens szembe fog kerülni, ha ilyen feladatot kap, mitől jó az oktatás?

• Felkészülés – az óra minőségét elsősorban az határozza meg, hogy az előadó mennyire érti az anyagot (persze, az előadó személye, rutinja is fontos, de azt jelen esetben konstansnak tekinthetjük). Amikor például ASP.NET webszervizeket adtam elő, és demózás közben is mindig pontosan tudtam, mi történik (miért nem működik a kód hirtelen), a felmerülő kérdésekre azonnal, csuklóból tudtam mondani a választ, az jobb előadás volt, mint mikor együtt bogarásztuk a masterpage-k rejtelmeit, és közben tudtam, hogy csak a rutinomra számíthatunk, hiszen csak előző este olvastam át részletesen az anyagot.
• Segédanyagok – a tanulók szeretik, ha nem kell jegyzetelni, és neadjisten kinyomtatva megkapják az előadás slide-jait. Ehhez persze kellenek slide-k, meg kell csinálni őket. Lehet utálni a pptx-et, de az a tapasztalat, hogy jobban értik, hogy miről beszélek éppen, ha a kontextust nagy, kék háttérre vetítem.
• Kód, kód, kód – mivel fejlesztőknek tartottam az oktatást, nagyon sok technikát csak akkor értettek meg igaziból, ha végigpróbálták. Belefutottak hibákba, átírták, megnézték, mi nem működik máshogy, alternatívákat kerestek. Az előadás jó "pihenőidő" volt, de a tényleges tudás úgy tűnt, hogy olyankor rögzül, ha be is írják a fejlesztőkörnyezetbe. Azért tartottam előadásokat bevezetőnek, az általános anyagokról, vagy összefoglalónak, de leginkább az működött, ha a kivetítőn írtam a kódot, magyaráztam közben, és a tanulók is próbálták velem párhuzamosan.
• Idő – úgy tűnik, hogy a minőségi pptx készítés nálam háromszoros időszorzóval tud működni – ha tudom, miről fog szólni. Azaz egy óra előadásra három óra alatt tudok felkészülni. Ami jó, de mondjuk két hétre nem volt másfél hónapom, tehát valahol húzni kellett. Megtanultam gyorsan feldobni a slide-okat – nem lettek olyan csicsásak, nem írtam tele a notes-t, hogy miről kell beszélni, de kiindulásnak jó lett. Volt, hogy inkább táblánál beszéltem, vagy csak a kódot magyaráztam. A lelkiismeretem kicsit bizsereg ilyenkor, hogy nem tudtam mindenhez anyagot adni, de az infó végül is átment.

A feladatoknál nagyon nem érdemes egymásra építeni, legalábbis eleinte. Próbálkoztam vele, hogy egy egyszerű ügyfélnyilvántartót építünk majd fel (Customer osztály, Group, stb), de látszott, hogy akik valamelyik feladatot nem tudták jól megcsinálni, azok végérvényesen elcsúsztak, a későbbi feladatoknál már esélyük sem volt behozni a lemaradást. Úgyhogy jobban bejöttek a kis típuspéldák. Aztán a végén persze csináltunk egy nagy alkalmazást, ahol minden réteget megírtunk, hogy lássák, hogy áll össze a sok megismert dolog egy működő egésszé, de menet közben jobb volt a példákat minél jobban elkülöníteni.

Persze az oktatásban nem tudtam megtagadni önmagam, nem csak a keretrendszerről meséltem, hanem kódolási trükkökről, a visual studio-ról, refactoringról és oo tervezésről, és igen, még a SOA-ról is. Remélem, ezek az információk is valahol hasznosak lesznek, nem csak az idealista elképzelésemet tükrözik (amit a túl jó projektjeim miatt általánosnak képzelek). De ezek a kötetlen fejlesztői sztorizgatások, a ki hogyan csinálná jellegű beszélgetések néha jól fellazították az egész napos hajtást. Legalábbis nekem.

Végül pár feladat, amit végignéztünk:

• Hozz létre customergroup és customer osztályokat. A customer egyszerre csak egy group-hoz tartozhasson, írj kódot ami biztosítja ezt. Unit tesztből ellenőrizd.
• Implementáld a customer-en az INotifyPropertyChanged interfészt. Lőjj a customergroup-ból saját eseményt ha új customer-t vettek fel.
• Írj olyan osztályt, ami egy adott streamwriter-re ki tudja írni mezőnként a customer-t. Válaszd külön ezt a viselkedést interfészbe, és factory method-dal döntsd el a konkrét implementációt. A kiiratásnál a formázást szabályozó culture információkat lehessen megadni.
• Adott az adatbázisban a Customer tábla, olvasd be a tartalmát. A CustomerInsert tárolt eljárás segítségével szúrj be egy ügyfelet. (ez cseles feladat volt, a név oszlopra titokban unique constraintet raktam, és mikor demózták, mindenkinek elszállt). A rendelkezésre álló eszközök segítségével (MSDN, Reflector) derítsd ki a hiba okát, és kezeld le.

Stb. Két hétbe azért jó sokminden belefért...

Kicsit leálltam a blogolással, épp lakást vettem, és a költözéssel telik a szabadidőm. De mára sikerült elérni, hogy az összes dobozt kibontottam, elvileg már "csak" a berendezésvásárlás és a pakolás marad.

Utána jöhetnek újra az írások.

Olvastam a IV. Architektúra Fórum programját, az előadások nagy részében kacsint felénk az "Agilis" szó. Ettől rájöttem, hogy kell írnom egy provokatív anti-cikket, kifejezetten vitaindító céllal. Divatos ugyanis isteníteni az agilis módszereket, és hogy őszinte legyek, szimpatizálok is a megközelítéssel, de ettől függetlenül sajna élőhalott utópiának tartom, ami a gyakorlatban - legalábbis az én, zömében itthon szerzett tapasztalataim alapján - nemigen használható.

"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan" (Manifesto for Agile Software Development)

Ennél nagyobb igazságot nagyon régen írtak le, ugye? Valóban, megragadták azokat az értékeket, amelyeket minden fejlesztőnek magáénak kellene vallania. Csak ez olyan, mint a "minimum 90% coverage", az "OOP-ben nem írjuk le azt, hogy case, arra való a polimorfizmus", meg a "nem dolgozom hétvégén, az az idő a családé". Bármilyen szép is, a gyakorlatban legtöbbször alkalmazhatatlan.

Az agilisek első fontos tanítása, hogy a projekt sikere a résztvevőkön múlik, nem a folyamaton. Ez kb. annyira triviális, mintha azt mondanánk: a középkorban gályával hajóztak. Ha magasan motivált zsenik a kollégák, akkor nem kell milestone review dokumentumot gyártani, fölös korlátozni a kreativitásukat, és valószínűbb a siker, mint mikor közepesen motivált, középszerű fejlesztőket próbálunk mindenféle iteratív vagy vízesésmodellben terelgetni.

Naná. Csakhogy az agilisek gyakran elfelejtik, hogy az emberek legtöbbje az átlagot közelíti. A legtöbb kolléga - a junior fejlesztők, az alvállalkozók, még az ügyfél is - a tucatmunkást fogja reprezentálni, nem pedig a fentiekben elvárt magasan motivált zsenit. És nekünk velük is kell dolgozni, a módszertannak, illetve a fejlesztési módszereknek pedig abban kell segíteniük, hogy velük, átlagos kollégákkal is sikeres legyen a projekt. Erre pedig igenis jó módszer tud lenni a megfelelő pillanatban ellenőrzött teljesítés, a sok review ciklus, a szerződésbe és rendszertervbe foglalt előregondolkodás, a tapasztalatra és szakmai tudásra felépített projektszervezet.

Egy másik rafinéria, amiről nem nagyon találunk cikkeket, mikor az agilis módszereket dícsérik, az iteratív fejlesztésre és az ügyfél bevonására vonatkozik, azaz hogy ne kőbevésett igényeket próbáljunk implementálni, hanem annyira rugalmasan építsük a szoftvert, hogy csak egy-két hétre előre tervezünk, azalatt csak nem térünk el túlságosan az elképzeléstől. A helyzet azért leggyakraban az, hogy a megrendelő viszonylag határozott igényekkel érkezik, tudja, hogy mit akar megoldatni a projekttel - most ezt vagy egyben kezeljük a projekt elején, vagy darabonként, menet közben – az agilis módszerek ezt a megközelítést preferálják. Ekkor viszont nem garantálja semmi, hogy a "nagy képpel" tisztában leszünk, elveszhetünk a részletekben, architektúra nélkül vagy szétesik a projekt, vagy az erőforrások nagy része az állandó redesignre, refactoringra, összetákolára megy el, teljesen feleslegesen.

Ráadáaul a ráadás kérdés, az árazás, amiről abszolut senki nem szokott beszélni. Általában a projekt elején az ügyfél meg szokta kérdezni, mennyibe fog kerülni – sőt, ez gyakran befolyásolja a döntését is. Hogy mondunk árat, ha nem tudjuk, mi a pontos (és teljes) követelmény? Hogy mondunk árat, ha tudjuk, hogy a követelményeket teljesen rugalmasan kezeljük menet közben, jönni fognak be újak, kiesnek a régiek? Mit csinálunk, ha elfogy a pénz, pedig még nem vagyunk készen, nem oldottuk meg az ügyfél eredei problémáját? Mi lesz akkor, ha az ügyfél lobogtatja az aláírt szerződést, mikor mi is vállaltuk, hogy adott keretből megoldást adunk az adott problémáról? Erről az agilitás hősei el szoktak felejteni beszélni. Pedig a megrendelés teljesítésére általában szerződés szokott születni, amibe ezeket illik legalábbis megemlíteni.

Persze ha time and material alapon finanszírozzák a fejlesztést, akkor akár működhet is. Ez esetben meg a megrendelőnek nincs semmi jogalapja számonkérni a haladás hiányát, mérni sem tudja az ütemét (a project velocity azrét elég technikai mérőszám, nem mutatja, hogy a szerződés teljesítése, a nagy probléma megoldás hol áll) - egyszer egy agilis munkámon a szponzor ezt úgy jellemezte: "Olyan volt, mint a rafting. Ott is tudom, hogy le fogok jutni a zúgón - de hogy hogyan, és milyen állapotban leszek a végére, az előre láthatatlan". Vajon ezt az élményt várja a megrendelő egy profi beszállítótól?

A harmadik cseles kérdés ez a dokumentációs dolog. Azt már említettem, hogy célszerűnek tartom a top-down tervezést az igények megismerése után, mert így a magasszintű igényekre tudunk fókuszálni, nem pedig az egyes feature-k sajátosságaiban veszünk el. Viszont a magas szintű döntéseket - és úgy általában, a döntéseket - érdemes időben perzisztálni. Ami jelenleg dokumentálást jelent.

Majd ha kitalálják az agy közvetlen merevlemezre dumpolását, akkor megússzuk, jelenleg sajna papírra, de legalábbis szövegszerkesztőbe kell írni ezeket a dolgokat. Mindenki utálja. Én is. Mondjuk annak örülhetünk, hogy van UML és Word, az ókori egyiptomban még márványba kellett volna vésnünk a kövspecet hieroglif írással, az még fájdalmasabb lenne. Viszont ha jól megfogjuk az ismeretek lényegét, akkor a dokumentáció segíthet, mikor két év múlva kapunk egy továbbfejlesztési igényt, vagy valakinek meg kell mutatni a rendszer domain modelljét, neadjisten az üzenetek formátumát és lehetséges szekvenciáit.

Akármilyen jól működik egy szoftver, követelményleírás, architektúraterv és tesztjegyzőkönyv nélkül csak egy összetákolt labilis kaka, az a véleményem.

És az utolsó ellenérv (hetvenhét van még, de elzárom magam), a javasolt fejlesztési módszerek kérdése. Erősen arra agitálnak bennünket, hogy a top-down tervezést felejtsük el, az architektúrát ne tervezzük, hanem evolválódjon, előre specifikált programstruktúra helyett refactoringgal, menet közben alakítsuk ki a véglegest.

Ezzel a probléma az, hogy ha már ketten dolgoznak azonos kóddarabon, és az egyik csak úgy refactorál, akkor a másiknak hirtelen utána kell húznia a munkáját. Tehát kizökken a gondolkodásból, belemegy valami merging-be, ellenőrzi a változást az unit teszteken, stb. Irgalmatlan költsége tud lenni egy ilyen nem tervezett kódváltoztatásnak, saját bőrömön is sokszor éreztem már. Célszerű tehát olyan felületeket húzni a kódba, amik nem fognak nagyon változni. Ehhez persze tervezés kell, méghozzá előre tervezés, aminek az eredménye a programon belüli struktúrák – úgymond az architektúra - rögzítése.

Persze a refactoringnak is meg van a szerepe, néha szükséges jó. Csak ilyenkor a hatásait, költségeit, hasznosságát fel kell mérni, erőforrást számítani rá, és csak akkor belevágni, ha kifizetődik. Döntést kell hozni. Méghozzá olyan szinten, ahol ez a döntés meghozható, az esetleges tradeoff-ok ismertek. És ez nem az egyes fejlesztő szintje, tehát van helye a vezetőfejlesztő (architect) szerepkörnek.

Összegzés

Ha mindent végiggondolunk, azért azt be kell látnunk: nagyon szépek az elvek, és nagyon fontos problémákra irányítják rá a figyelmünket. Rettentő jó ötleteket lehet belőle meríteni - fontos, hogy a projekten mindannyian ismerjük a többiek véleményét, problémáit, fontos, hogy ne papírhalmot gyártsunk hanem megoldást, irgalmatlanul lényeg, hogy az ügyfél igényeit elégítsük ki, és ne egy aláírásra mutogassunk, és hogy ne féljünk a változástól, hanem tanuljuk meg kezelni, mert úgyis jönni fog. Az agilis módszertanok – XP, Scrum, stb – diszciplináit felhasználva a saját projektjeinken tényleges értéket hoznak, tehát nem jó elutasítani, figyelmen kívül hagyni őket.

Csak ezek a javasolt módszerek sajnos egy álomvilágból érkeznek, Martin Fowler, Kent Beck, Alistair Cockburn és a többiek elit klubjából, akik sajnos elfelejtik, hogy nem mindenki dolgozhat együtt kizárólag földönkívüli intelligenciával bíró, hiperaktívvá motivált géniuszokkal. Sőt, jellemzően nem ilyenekkel dolgozunk együtt, nem ilyenek vagyunk mi sem. Ezért aztán a projektmódszertanokat nem jó száz százalékig erre az előfeltevésre építeni, hasznosabb inkább, ha a szokásos iteratív modellbe engedjük beszivárogni ezeket az elveket – a csapattól, problémától, ügyfélkörnyezettől függő mértékben.

Technorati-címkék: agile,methodology,development