A Test Driven Development (Design) módszert

Programozás

éles fejlesztéseknél használom és jónak tartom,
15% (37 szavazat)
éles fejlesztéseknél használom és megfelelőnek tartom,
8% (19 szavazat)
éles fejlesztéseknél használom és rossznak tartom,
0% (1 szavazat)
hobbi fejlesztéseknél használom és jónak tartom,
4% (11 szavazat)
hobbi fejlesztéseknél használom és megfelelőnek tartom,
2% (5 szavazat)
hobbi fejlesztéseknél használom és rossznak tartom,
0% (0 szavazat)
az elvét ismerem és jónak tartom,
12% (30 szavazat)
az elvét ismerem és megfelelőnek tartom,
15% (36 szavazat)
az elvét ismerem és rossznak tartom.
6% (16 szavazat)
Nem szavazok.
37% (92 szavazat)
Összes szavazat: 247

( joco01 v | 2018. 02. 27., k – 19:52 )

Bugfixeknél jó szokás, hogy előbb írunk tesztet, utána javítjuk a kódot, az is beleszámít?

Hogy tudna egy javítás egy már tesztelt esetet eltörni és úgy bekerülni a kódba?

Nekem ez itt kicsit oximoron.

Már a code review-ig sem jutna el a pull request, hiszen akkor azt a tesztet el fogja törni az új "megoldás".

Ahogy megnyomja a gombot, hogy szeretné a branch-et integrálni és lefut rá a teszt, már jön is rá a böszme nagy jelzés, hogy a melyik teszteket töri el. Már feltéve, hogy kellően lusta volt és a PR feladása előtt ezt nem tette meg saját maga a devdesk-jén.

Nem.

Azt írta tesztelt a megoldás, amit eltörne a fiktív change.

Ha nem volt rá teszt írva, akkor az hogyan lenne tesztelt?

szerk.: "csak" az "alapműködésre" írta, hogy nincsenek tesztek. Jelentsen az "alapműködés" bármit is.
Mindenesetre a kérdés szempontjából irreleváns, mert a kérdés arra vonatkozott, hogy egy már tesztelt viselkedést törne el a change.

hunyadym kolléga írta:
"bugfixnél használom, feature fejlesztésnél csak nagyon ritkán."

Ebből nekem az jött le, hogy nincs rá automatizált teszt.

Én írtam:
"...egy bug javítás egy korábban már átgondolt és tesztelt megoldást nem ront el?"

Itt pedig azt feltételeztem, hogy azért a fejlesztő tesztelte, amit megcsinált, csak nem írt rá automatizálható tesztet, hanem mondjuk debugolt, vagy bármilyen más módszert használt, hogy meggyőződjön róla, hogy megfelelően működik a kódja.

De lehet, hogy túlgondoltam és csak megírta a kódot, ami egyszerűen jól működött. A bugfix szükségességéig...

( mgabor v | 2018. 02. 27., k – 19:55 )

Olyan jó volt régen, nem volt ennyi bullshit szó mindenre. Ha értelmesen átgondoltan fejlesztettél, azt nem hívták kanban-nak meg scrumnak. Ha felismerted a veszteséget egy folyamatban akkor nem voltál lean manager. Ha tudtál értelmesen kommunikálni az ügyféllel és még fejlesztőként is jó voltál akkor nem hívták agilis szoftverfejlesztésnek. Ahhh.... mindegy, ez csak kibukott belőlem.

-1.

Egy szó: scale (skála? :)).

Exponenciálisan növekszik a fejlesztők száma, a szoftverek száma, a szoftverek mérete, a fejlesztőeszközök száma, stb. Újabb és újabb módszertanok nélkül egyre kezelhetetlenebbé válna minden. Muszáj újítani, és évről évre lesznek még új buzzwork-ök ezután is. És ennek eredménye is van: a dolgok egyre könnyebben kezelhetőek, egyre hatékonyabb a fejlesztés, egyre több bevétele van az IT cégeknek, egyre újabb területeket tudunk meghódítani (csak egy példát mondok: AlphaGo). Ettől olyan izgalmas az informatika.

(Amúgy persze vannak gyengébb vadhajtások, ez a fejlődés velejárója, de az évek során ezek majd kihalnak.)

meg sajnos exponenciálisan növekszenek a kódméretek, anélkül, hogy exponenciálisan növekednének egy alkalmazás képességei.
Mintha valami olyan lenne hogy "a falhasználók majd megszokják a kis hibákat, együttélhetnek a nagyobb hibákkal, a kódméret meg azért nőtt, hogy biztonságosabb legyen a program."
A fejlesztési módszerek száma is exponenciálisan növekszik, csak kár, hogy ez nem látszik a végtermék minőségén.
Régebben egy program verziószámnövekedése hozott új funkciókat, ma már csak a kódméret nő, meg a felhasználói felületet zagyválják össze, rosszabb esetben még funciók is tűnnek el egy programból. Ez lenne a fejlődés útja?

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Hibák mindig is voltak, lesznek, de nézz szét egy kicsit jobban.

Az Android több millió sor, 10 éve jelent meg, rengeteg újítást hozott, és csak tippelek, hogy több százmillió sornyi appot írtak rá.

A ZFS kb. 10 éves, és olyanokat lehet megcsinálni vele, amiről korábban nem is álmodtak a rendszergazdák, és még biztos nagy karriert fog befutni az OpenZFS révén.

A felhők is kb. 10 éve indultak útnak (AWS-től számolom). Nézd meg, milyen szolgáltatásokat tudnak nyújtani, mennyire skálázódnak, és mennyibe kerülnek. Egy teljesen új iparág lett, és felfogni se lehet, mi minden épül már rájuk.

Több millió sornyi kód születhetett csak az utóbbi pár évben gépi tanulással kapcsolatban. Eszméletlen dolgokat meg tudnak már csinálni az AI-k (nálam továbbra is az AlphaGo az etalon, de vannak még jó dolgok).

És még sorolhatnám naphosszat, hogy mennyire fejlődik minden. Ha te csak annyit látsz a fejlődésből, hogy összezagyválnak egy felhasználói felületet, hát az sajnos egy teljesen eltorzult világkép.

+1
Éppen azt akartam írni, hogy mostanában az informatika nagyon közgazdaságtani kifejezésekkel összecsengő módszer-elnevezéseket takar, sőt inkább több köze van a közgazdaságtanhoz. Kellett bevezetni a informatikus-közgazdász szakokat! Tényleg döbbenettel állok a jelenség előtt: nem elég programozni, hálózatot tervezni-építeni, biztonsági megoldásokhoz érteni, ezek jogi hátteréhez érteni, már az első billentyű leütése előtt mindenféle barom tanulmányba bele kell vinni az IT szereplőit, ergo elvárandó, hogy azokhoz is értsenek. A specializált területeken elvárható, hogy más szakmákba is belelásson az ott dolgozó informatikus, de általánosságban az effektív munkától vonja el az energiát. Önmagában a naprakészség minden új-régi tanulmány, módszer tekintetében is többlet terhelést okoz. Ha a mai elvárt (!) szupermen státuszt meg akarná közelíteni a szakmájában az informatikus, akkor még fajsúlyosabb a dolog: Amíg a mérnökök, technikusok flipchartot lesik, ki fog kódolni, tervezni, építeni? A szakmunkás, a betanított-, vagy segédmunkás?

(Bocs' a szavazás felvetőjétől, hogy ennyire beoffoltam: kiszakadt belőlem.)

-1

Ez minden szakmára igaz, rengeteg új dolgot találnak ki és azokat, hogy lehessen hivatkozni rájuk, el kell nevezni. A matematikában, fizikában is hasonlóan sok új kifejezés születik, ráadásul ott eleve nagyobb alapokról indultak, mert kicsit régebbiek.
Nem tudom hány matematikust, fizikust, ... hallottál buzzwordözni, bullshitelni, mert megjelent egy új kifejezés.

Számomra az igazi bullshit szavak azok, amik minden újdonságra ugyanolyan negatív kifejezést használnak, pl. buzzword, bullshit, hype, trendy, ...

Sokkal jobban tetszenek a népszerű, felkapott, divatos, modern, ... szavak.

Attól, hogy valami új, lehet jó is, meg lehet rossz is.
Ez a szavazás is kicsit azt hivatott eldönteni, hogy inkább jó vagy inkább rossznak gondolják a fejlesztők.

Az eddigi szavazás állásán az látszik, hogy akik használják, azok szerint kifejezetten jó. Akik nem használják, azok szerint már rosszabb a helyzet, de azok szerint is inkább jó.

A bejegyzésből nekem úgy tűnik h nálad nem ment át a scrum üzenet.
Ezzel nem vagy egyedül, rengeteg scrum-nak nevezett projektet látok ami valójában nem az, a csalódást mégis könnyebb egy buzzwordhöz társítani.
Ami biztos: a scrum rettentően nem az egyéni fejlesztésről, az átgondoltan fejlesztésről szól.

--
Gábriel Ákos

"Ezzel nem vagy egyedül, rengeteg scrum-nak nevezett projektet látok ami valójában nem az, a csalódást mégis könnyebb egy buzzwordhöz társítani."

Én tegnap láttam egy komplexebb feladatról beszállítói árajánlatot, ahol kidomborították, hogy agilis módszertan szerint fejlesztenek, az árajánlat pedig úgy nézett ki, hogy 1 storypoint = 8000 forint + áfa, ránézésre egy storypoint ~ egy emberóra és volt a lista végén 10 százaléknyi storypoint tartalék. Ilyenkor mire tudsz gondolni?

A scrum guide nem tartalmaz semmilyen információt a gazdasági résszel (árazással) kapcsolatban.
A PO trainingen volt erről néhány gondolat, hogy na de akkor mégiscsak hogyan kell árazni.

Igazából pont ez az 1SP = x Ft árazás öli meg az egészet alapjaiban (ezt már volt alkalmam tapasztalni).

Kétféle módszert gondolok működni, ebből csak az elsőt próbáltam eddig:

- T&M alapon szerződni kapacitásra: ekkor tulképp a stakeholderek viselik a kockázatot. Nyilván lehet akár változtatni a Ft/órán, tapasztalatok alapján. (ez működött)
- fix áron szerződni, scope-ra. Ekkor a PO viszi a kockázatot, neki kell rutinszerűen megalkudni a scope change-ekről (ez amúgy is feladata, csak itt az ár is bejátszik)

Egy dolgot nem szabad tenni: a pénzkérdés nem szabad hogy leszivárogjon a developer team szintre (estimation, stb...)

--
Gábriel Ákos

Az elso mukodik, persze.

A masodikat nem szivesen csinalnam fejlesztokent, beszallitokent.

Ha fix ar van fix scope-ra, akkor hol van rugalmassag? Az idoben vagy a csapat letszamaban, ami mindketto az en zsebembol jon. Ez pont az a megkozelites, amit a tradicionalis projekteknel szokas, es ami nagyon sokszor nem mukodik.

Maga a fix scope gaz, mert nem ad lehetoseget, hogy a valtozasokhoz alkalmazkodjek a fejlesztes.

Szerintem ha a megrendelo talalja ki, hogy min dolgozzon a csapat, akkor kizarolag az mukodik, hogy az emberek idejet fizetik meg.
Lehet time and material hatarozatlan ideju, meg lehet fix aras, fix ideju megbizas, ahol amikor vege a penznek, akkor derul ki, hogy mi fert bele es mi nem.

Mas megkozelites csak akkor mukodik, ha pl. egy ceg sajat maga fejleszt sajat otlet alapjan es a termeket arusitja, nem a fejlesztest.

Amugy a Story Point inflation egy letezo problema, ha meg penzt is tarsitunk hozza, csak felgyorsitjuk a folyamatot.

Alternativakent, a Story Point merese helyett a Business Value mereset javasolnam, es ez alapjan fizetni. Igy megvan az is, hogy a leszallitott ertekert fizet az ugyfel, nem csak az elcsocsozott idoert, ugyanakkor megmarad a rugalmassag is. De fejlesztokent, beszallitokent csak akkor mennek bele ilyen modellbe, ha 1) latnam azt, hogy lesznek magas erteku BLIk, nem csak ertektelen vackok ES mukodik az, hogy azon dolgozik a team, ami magas business value-t ad (aminek egyebkent is alapnak kellene lennie).

A fix áron szerződni scope-ra azt akarja jelenteni h az elején mondok egy összeget amiből szerintem az elején ismert scope kijön.
PO-ként azon tudok alkudni hogy x dolgot y-ra becserélhet a stakeholder.

Ha a PO nemet mond, akkor "nem lett mondva", ezen nincs vita, ezt a szerződésbe is bele kell írni.
Scope bővítés lehet, az persze plusz pénz (és plusz sprint).

Fél évnél rövidebb időre így mondjuk biztosan nem szerződnék.
Ez azért sokat elbír, benézést is.

--
Gábriel Ákos

Ez OK.

Szoval akkor megsem fix a scope.

De akkor mi fix? A teljes product backlog story pointok osszege? Ami a velocity-vel elosztva egy becslest ad a sprintek szamara. Vagyis akkor nem a scope a fix, hanem adott kapacitast vesz az ugyfel.

Mukodhet ez, de tovabbra is tartanek a story point inflaciotol.

( prion | 2018. 02. 27., k – 21:07 )

Érdekes lenne erről olvasni, olyanoktól, akik ezt használják. Hogy néz ki a munkafolyamat és kik vesznek részt.

Szvsz a TDD néhány lépését mindenki feltalálta már valamilyen formában. Valszeg már akkor, amikor a basic előtt pötyögött.

Emberünk ül a gép előtt. "Működik? Nem. És így? Nem. És amúgy? Igen. Fasza, mi a következő feladat?"

A nagy többség úgy programozik, hogy próbálgatja a lehetséges megoldásokat, és amikor talált egyet akkor örül.

A TDD szerintem ennek a folyamatnak a részletes, gép által ismételhető leírása.

Azaz ha a fenti "Működik?" elé odarakod, hogy "Szeretném, hogy a cucc így és így viselkedjen, ezekre a paraméterekre" és ezt a mini specifikációt le is kódolod első lépésként, akkor TDD-zel.

Vagyis a projectnek egy idő után lesz egy jó hosszú specifikáció-gyűjteménye, ami minden buildkor ellenőrizve van. Gép által, nem pedig egy demotivált fejlesztő/tesztelő által.

Az meg hogy unit teszt/integrációs teszt ebből a szempontból lényegtelen.

Azt szokták mondani hogy ezeket a mini-specifikációkat (teszteket) és magát a kódot ne ugyanaz az ember írja. Ezáltal nem lesz a tesztekbe olyan beleértve, ami a kód (objektum) belső működése. Ez az, amit még nem láttam hosszútávon működni. :)

Kent Beck, aki megalkotta a TDD-t valami ilyesmit mondott, hogyan merült fel az ötlet:
~"Vannak magától értetődő dolgok, azok természetesek és sok embernek eszébe jutnak, azokkal nem érdemes foglalkozni; és vannak nem magától értetődők, amiket az ember elsőre hülyeségnek tart, na ezekkel érdemes foglalkozni és alaposabban utánanézni."

Milliónyian megírták már róla a tapasztalatokat. Nálunk pl. vannak unit és integrációs tesztek, automatikusan futnak és addig nem is lehet a master ágra bemergelni semmit, amíg az adott PR-hez tartozó tesztek le nem futnak.

Igen, egyik oldalról plusz munka a tesztek megírása, karbantartása. Viszont egyrészt rákényszerít arra, hogy előre végiggondold a feladatot és felderítsd az összes esetet, másrészt ad egy visszajelzést, hogy azt teljesíted-e. Viszont ez a kevésbé fontos része. A fontosabb része az, hogy biztosítja, hogy a kódod később is azt fogja csinálni, amit szeretnél és különösen igaz ez, hogy ha a kódon mások is dolgoznak vagy mások veszik át - akár évekkel később. Ilyenkor nagyon sokat számít az, hogy van valami, ami rácsap az ember kezére, hogy az a módosítás nem lesz jó, mert eltör máshol dolgokat - amik nem biztos, hogy manuális teszteléssel kijönne, mert nem tudod végigtesztelni kézzel mindig az egész rendszert.

Nyilván lehet retardált módjára is kezelni, pl. mikor előírásszerűen kell x %-nyi code coverage, olyankor születnek a haszontalan tesztek.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( Hevi v | 2018. 02. 27., k – 21:55 )

Microservice eseten a unit tesztet, ezaltal a TDD-t feleslegesnek, sot, hatekonytalannak, kartekonynak tartom, BDD es mockolt kulso dependenciak a megfelelo megoldas.

Igazából nem csak microservice esetén igaz ez, de szinte bármilyen rendszerben ha a kód jól van strukturálva, single responsibility tényleg single responsibility, akkor a unit tesztek 90%-a triviális lesz, tehát igazából értelmetlen.
Persze igazából a TDD nem feltétlenül unit tesztet jelent, de igazán én még nem láttam olyat, hogy nem azt jelentette volna.

Lehet, hogy te olyan szerencses vagy, hogy nem kellett dolgoznod "legacy" rendszereken. Ezek fo jellemzoje a tesztek hianya, es altalaban nem megfeleloen strukturaltak. Ahhoz, hogy uj funkciot adj hozza egy ilyn szoftverhez, vagy kijavits egy hibat, elobb kellenek tesztek, hogy mi az aktualis viselkedes, nehogy a valtoztatas elrontson valamit.

Namarmost, ezek a tesztek nagy valoszinuseggel nem unit tesztek lesznek, hanem inkabb rendszer tesztek, foleg, ha a tesztelendo osztalyokat nem tudod peldanyositani a fuggosegek miatt. Szoval ahhoz, hogy tudj irni unit teszteket, refaktorizalni kellene a kodot, ami viszont meglevo tesztek nelkul hazardjatek.

Javaslom Michael Feathers konyvet: "Working Effectively with Legacy Code".

Pedig az a TDD lenyege, hogy eloszor (unit) tesztet irsz, es utana a kodot (hogy "a piros zoldre valtson" - ez egy pszichologiai jutalmazasi effekt). Az atyauristen agile-szent profeta mr. Unclebob szerint az idealis ido, ami teszt/kod iras valtas kozben eltelik, az masodpercekben (!) merheto. Ez kizarolag unit teszteles eseten lehetseges.

Volt mar szo rola, de az ismetles sosem art:
https://rbcs-us.com/site/assets/files/1187/why-most-unit-testing-is-was…
https://rbcs-us.com/site/assets/files/1191/segue.pdf

TL;DR: sok problema van a TDD-vel, meg ugy altalaban a unit tesztek eroltetesevel mindenre, de talan a legfontosabb tanulsag ez: mibol gondolod, hogy a teszt irasakor okosabb vagy, mint a kod irasakor?

A legegyszerubb fuggvenyek eseten is nagyon konnyu olyan unit teszteket irni, amelyek tokeletes lefedettseget adnak, megsem mutatjak ki a legegyszerubb hibakat sem. Es akkor meg nem is beszeltunk a mock-erdovel korulvett, a kodnal nagysagrendekkel hosszabb es bonyolultabb teszttel rendelkezo fugvenyekrol/osztalyokrol, amelyek tenylegesen nem tesztelnek semmit, viszont 10-szeresere novelik a fejlesztes koltseget.

Csak azert, mert TDD-zel meg unit teszteket irsz, meg ugyanugy gondolkodnod kell, ezt azonban a TDD igyekszik egy nagyon korlatolt mederbe terelni. Szamos problema van meg vele, akit erdekel, olvassa el a fenti cikkeket.

Mi az, amit TDD helyett erdemes (lenne) hasznalni: peldaul QuickCheck-alapu generalt teszteket, es termeszetesen magasabb szintu, business use-case-eket lefedo, lehetoleg end-to-end teszteket, amelyek lehetnek automatizaltak, de lehetnek akar manualisak is (nem mindig eri meg automatizalni - ez is egy tipikus TDD hiba).

A test drivenség egyik nagy előnye, hogy már úgy írja meg a kódot, hogy azt tesztelni lehessen. Ha ez a gondolkodásmód
vezeti a fejlesztést, akkor nagy gond nem lehet. A többivel egyetértek (mock erdő, de minek, végtelen mennyiségű triviális
unit teszt, ahelyett, hogy integrációs tesztek lennének, mindent automatizálni akarnak, közben meg kézzel századannyi időből
meglenne stb.)

2 agile principle-t erzek ide tartozonak:

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Ha a takarekossag erdekeben a csapat feladja a technical excellence reszt, es pl. nem fed le automatikus tesztekkel mindent, amit kell, akkor a constant pace csak egy alom lesz.

Ezért is nagyon kevés a "valódi" Agile projekt. Mert legtöbbször a budget fix. Ha a budget fix, akkor meg a feature-ök száma korlátos.
Mert azt mondod, hogy automatizálod a tesztet. És? Mit bizonyít az? Valójában semmit. Ha majd matematikai helyességbizonyítás, meg modelhelyességbizonyítás
megvolt, akkor beszélhetünk.

Ja, hogy erre mindenki hangosan felkiált, hogy "Maaargit, normáááális?". Persze, és igaza is van. Mert egy budget-en belül dolgozunk.

És még egy dolog, oké, hogy van automatizált teszted. De mit is tesztelünk? Unit tesztek? Integrációs tesztek? Acceptance tesztek? Performance
teszt? A topicban leírták, hogy hiába írtak unit teszteket, tök zöld volt, mégis bukott a valódi futásnál. Nesze neked technical excellence.

Az elmult 7 evben csak olyan projekteken dolgoztam, ahol vagy time and material alapon ment, vagy egyszeruen allokaltak elegendo penzt mindig a kovetkezo negyed evre.

Ez mind valodi agile projekt volt.

A maradek resze a hozzaszolasnak szerintem nem arrol szol, hogy van-e valodi Agile projekt.

Ha engem kerdeznel, en automatizaltan tesztelnem, hogy nincs-e regresszio. En csupan ezt probalnam bizonyitani.
Ha egy valtozas eltori a korabban mukodo funkciokat, annak ki kell derulnie, mert ha nem, akkor senki nem mer majd hozzanyulni a kodhoz, nem lesz refaktoralas, es a hiba javitas vagy barmi letezo dolog megvaltoztatasa baromi rizikos es sokkal hosszabb lesz.

Ha a takarekossag erdekeben a csapat feladja a technical excellence reszt, es pl. nem fed le automatikus tesztekkel mindent, amit kell, akkor a constant pace csak egy alom lesz.

Nem csak az automatikus teszt a lényeges elem, hogy "technical excellence" legyen a kód, hanem még a jó tervezés, amit elősegít a TDD, és a folyamatos refaktorálás, ami szintén a TDD fontos eleme.

TDD nélkül is lehet jól tervezett a kód, megfelelően refaktorált és automatikus tesztekkel megfelelően lefedet; illetve TDD-vel is lehet rosszul tervezett a kód, rosszul refaktorált és automatikus tesztekkel rosszul lefedett.
Ez az egyéni képességeken, tudáson és tapasztalatokon is múlik.

Egyébként egyetértek, ha nem eléggé "technical excellence" a kód, akkor a folyamatos haladás csak álom lesz és egyre lassul majd a fejlesztés, módosítás.

Lehet gond is belolle. Mint mindennel ezzel is tul lehet esni a lo tuloldalara. Reviewoltam olyan kodot ahol a csavo egy fuggvenybe kivulrol passzolt be egy referenciat egy `Time` osztalyra, ami egy absztrakt interface-t implementalt es igazabol csak annyit csinalt, hogy visszateritette az idot... ahelyett, hogy siman meghivta volna a `std::chrono::steady_clock::now()` ot. Mindezt azert mert "maskepp nem lehet tesztelni". Es lehetetlen volt meggyozni hogy ez mar tul van minden hataron.

Amugy nekem ez a bajom ezekkel a divat metodikakkal. Olyan emberek akik nem akarnak gondolkozni vallasosan kovetik oket es a kod minosege pedig szenved tolle. Persze lehet, hogy ha nem divatos metodikakat kovetnenek akkor meg csak siman szar kodot irnanak.

Az a tapasztalatom, hogy ahol ertelmes emberek dolgoznak, ott mindegy, hogy milyen metodikat hasznalnak, vagy minek hivjak amit csinalnak (ha hivjak valaminek egyaltalan) a vegeredmeny minosegi termek es kod lesz. Ahol meg kevesbe ertelmes emberek dolgoznak, ott hasznalhatsz akarmit a vegeredmeny megse lesz olyan jo. Ennyi.
--
:wq

Miert kene sleep a tesztbe maskepp? Az alternativa az lett volna, hogy a kimenetnel egy hibahatarral osszehasonlitja az idot egy masik `now()` hivassal ami teljesen jo lett volna. Szerintem ez massziv tulbonyolitasa volt a dolognak csak azert, hogy "rendesen" le lehessen tesztelni.
Magyaran az amugy 3-4 soros fuggveny tesztelhetosege miatt hozzaadott a kodbazishoz:
* Uj interfeszt ami sehol mashol nem volt hasznalva.
* Egy konret megvalositasat az interfesznek ami sehol mashol nem volt hasznalva.
* Egy plusz virtualis hivast es egy plusz heap memoriafoglalast (tudom premature optimization de akkor is).
* Egy objektum eletciklus problemat.

Az ironia az, hogy a sok hozzadott bonyolultsag miatt az eles kodban az egesz osszeomlott SEGFAULT-al de meg jo, hogy a unittestek mind zoldek voltak.
Az en fogalmaim szerint ez masszivan a lo tuloldalara eses kategoria es a KISS elvek sarba taposasa.
--
:wq

Valósidejű rendszerhez egyszer csináltam ilyen időgyorsító alrendszert, hogy lehessen percek alatt lefutó dolgokat másodpercen belül tesztelni. Nagyon büszke voltam magamra, hogy milyen jól sikerült.

Aztán egy céges vacsin találkoztam a fejlesztővel, aki átvette tőlem a rendszer fejlesztését... :-)

Alapvetően sok mindennel egyetértek.

mibol gondolod, hogy a teszt irasakor okosabb vagy, mint a kod irasakor?

Nem vagy okosabb, épp ezért a tesztben azt írod le, hogy milyen bemenetre milyen kimenetet vársz, röviden a követelményeket a kóddal szemben. Ezután a kódnak ezeknek a követelményeknek kell megfelelnie.
/Ez olyasmi, mint tervezésnél a követelmény specifikáció, majd utána az azon a követelményeken alapuló tervezés./

Épp ezért jó, hogy előbb írod a tesztet, mert még nem tudod, hogyan lesz megvalósítva, így nem is fog a megvalósításra épülni, vagy más néven, nem az implementációt teszteled.

Ahogy irtam, nem sajat tapasztalat, de amit olvastam, az pont azt mondta, hogy ne unit tesztet irjon az ember TDD-vel, hanem mukodest teszteljen.

Szoval en azt szurtem le belole, hogy nem egy osztaly tagfuggvenyeit kell tesztelnie egyenkent (en kb. ilyesminek kepzelem el a unit teszteket), hanem az osztaly mukodeset adott szituacioban, ami akar tobb metodus hivast is tartalmaz.

De lehet, hogy felreertem a unit test fogalmat, ha igy van, nyugodtan javitsatok ki!

Igen, csak itt jön be az, hogy unit teszt esetén kell mögé valami mock, hogy valóban csak azt az egy részt teszteld, amit akarsz, különben már átlép(het)sz integrációs határokat. Pl. oké, hogy az üzleti logikád kinyúl adatokért valahova, de teszten ne nyúljon már egy másik servicehez vagy DB-hez.

Másik oldalról meg ami fontos - főleg microservice világban - az az integrációs tesztek, amikor pont az egyes servicek közti interakciót teszteled.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Milyen toolokkal csinálsz BDD-t?

Ha Cucumber vagy derivátumaival, akkor az a BDD gyakorlatilag TDD, csak a teszteseteket business közeli nyelven (Gherkin) fogalmazod meg, és "valaki" az egyes stepeket kézzel végrehajtható kóddá alakítja (ideális esetben ezek a step definíciók projektek között sharelhetők, de ez nagyon ritka és megvan a saját költsége).

Vagy másra gondolsz BDD alatt?

Illetve hogyan csinálsz úgy (értelmesen) TDD-t, hogy nem mockolhatók a külső dependencyk?

( pintergreg | 2018. 02. 28., sze – 06:23 )

Önmagában a tesztet előbb megközelítés támogatandó, de a szigorú (definíció szerinti) TDD-t alkalmatlannak tartom értelmes munkára(, bár egyszer érdemes kipróbálni). A BDD körül kezd értelme lenni a dolognak.
______________
"If you immediately know the candlelight is fire, the meal was cooked a long time ago."

( _Franko_ v | 2018. 02. 28., sze – 07:50 )

Én mostanában mindenhol a Hype Driven Development módszertant látom... :)

( _Franko_ v | 2018. 02. 28., sze – 07:50 )

Én mostanában mindenhol a Hype Driven Development módszertant látom... :)

( flimo | 2018. 02. 28., sze – 12:16 )

Nem követem a TDD-szentírást, még nem vagyok olyan öreg, hogy olyanokra írjak tesztet, hogy vajon megírtam-e már a függvényt, amit meg akartam. A happy path-ra írok általában egy blackbox-szerű* tesztet, hogy ne kézzel kelljen hajtani, meg egy-két hiba lekezelésére. Ha pedig kész az implementáció mutation testing futtatással megnézem, hogy milyen ágak maradtak ki, ha üzletileg értelmes egy mutation megölése, akkor pedig eldöntöm, hogy integrációs vagy unit tesztben érdemes-e lefedni.

Konkrét esettől függ, ez lehet unit, integrációs vagy bdd teszt is.

( ironcat | 2018. 02. 28., sze – 18:39 )

Megkönnyítené a megítélést, ha tudnánk, hogy David 8 szoftverének fejlesztésénél alkalmazták-e a módszert. Mert ha igen, akkor nem érdemes vele foglalkozni.

( janoszen v | 2018. 03. 01., cs – 06:26 )

Miután egyre többet kisérletezem mostanában mindenféle minőségbiztosítási módszeren, az alakult ki bennem, hogy:

- az integrációs tesztek megmondják, hogy szar van a palacsintában.
- az egységtesztek (modul/osztály tesztelése izolációban) megmondják hogy hol.
- a TDD leginkább abban segít, hogy ne hagyj ki teszteseteket és legyen teszted a nem happy case-re is (pl. amikor a usernek nincs joga valamire) és ez megvéd a későbbi regresszióktól.
- Ha az ember kisebb projektben végez ügyfélmunkát, gyakran előfordul hogy éles kódot és teszteket is ki kell dobni, így ez esetben csak integrációs tesztek írása hatékonyabb tud lenni.
- A van teszt jobb mint a nincs teszt, a módszer kevésbé fontos mint az hogy egyáltalán legyen egy megbízható módszer hogy megmondjam hogy a program működik-e.

Subject to change, a válaszokban jöhetnek az ellenvélemények.

--
Pásztor János

( enpassant v | 2018. 03. 01., cs – 07:44 )

A hozzászólások során nagyon sok tévhit felmerült a TDD-vel kapcsolatban és a tesztek jóságával / hiábavalóságával kapcsolatban.

Ezért úgy gondolom, hogy érdemes elolvasni Farkas Gábor "A TDD (Test Driven Development) világa" című, három részes cikksorozatát, különösen a II. részt: Gyakori tévhitek.

Egy példa a cikkből:

1. tévhit: A unit tesztek fő feladata a kód helyességének ellenőrzése

A valóságban a szoftvertesztelés különböző fajtái csak nagyon kevés bugot képesek felfedni (kb. a hibák 20%-át). Összevetve ezt az automatizált teszteléshez szükséges plusz munkával, eléggé kérdéses lenne annak megtérülése.

Az igazság ezzel szemben az, hogy az automatizált unit tesztek és a TDD elsődleges célja a refaktorálás elősegítése. ...

Itt fel van cserélve az ok és az okozat.
Nem a unit teszt nem segít a refaktorálásban, hanem ha mockolással az implementációhoz kötöd az nem segít.
Ajánlom figyelmedbe a "Mock & Stub, avagy hogyan tesztelünk rosszul tervezett kódot" blogomat.

Ha előbb írod meg a tesztet és utána az implementációt, akkor hogyan tudod előre ahhoz kötni?

Hogy is segit a unit-teszt ha nem a helyesseget teszteli? Tapasztalatom szerint a TDD-szerinti unit-tesztek sokszor inkabb hatraljak a refaktoralast mivel nem eleg, hogy az adott osztalyt es minden klienst refaktoralni kell meg a tomenytelen unit-tesztet is at kell irni. Nagy reszuket ki kell dobni egybol a tobbit meg lehet jol atirni, hogy a mockerdobol kivagd azokat a reszeket amiket az uj megvalositas mar nem hiv.
Szerintem sokkal tobb ertelme van az olyan teszteknek amik az osztalyt mint egeszet tesztelik az elvart funkcionalitas szempontjabol. Ilyenekbol eleg egy par es igazabol sokkal tobb erteket adnak.

A masik kedvencem, hogy a unit-tesztek a kod dokumentaciojakent is szolgalnak. Hat kozsonom szepen, olvassa mas a unit teszteket en 100-bol 100 esetben valasztanam inkabb egy Doxygen generalta API doksit de meg a magat a kodot is hamarabb nekiallok elolvasni mint a teszteket.

En egy jo ideig nagy rajongoja voltam a TDD-nek, bar hogy oszinte legyek eleg keveset hasznaltam nap-mint-nap, de minel tobbet hasznaltam annal inkabb kiabrandultam belolle. Unit teszteket mai napig irok minden kodhoz amihez lehet es erdemes de utollag es a "szerzodesekre" osszpontositva, nem tesztelem a metodusokat izolacioban, sot az osztalyokat se. Ha egy osztaly behuzza a fel projektet, am legyen, legalabb az integracio is le van tesztelve, ugy is igy lesz hasznalva.

Akkor irom elore a tesztet amikor egy hibat javitok, ilyenkor megirom elore a reprodukalot (ha lehet) es utanna javitom.
--
:wq

Nem, ennek így kellene történnie. Többnyire nálunk így is van*.

(* Nyilván van, amikor refactoring keretén belül valamihez jobban hozzányúlunk és a tesztekhez is hozzá kell nyúlni, illetve a másik tészta, mikor egy interfacet állunk neki refactorálni, de ezek speciálisabb esetek és ritkábbak is.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Harom eset van:
* Csak egy metodus vagy osztaly belso mukedese kerul modositasra.
* Egy osztaly publikus metodusai is modosulnak.
* Egy absztrakt interfesz is modosul.

En az utobbi ket esetre gondoltam, amikor azt mondtam, hogy "interfesz" modosul. Az utobbi nagyon ritka de azert megtortenik, ilyenkor altalaban a kodbazis nagy reszet frissiteni kell.
--
:wq

( uid_7086 | 2018. 03. 01., cs – 07:59 )

Quis custodiet ipsos custodes? Ki teszteli a tesztelőket? :)
Mióta először próbáltam unit tesztet írni, azóta érdekelne. A teszteket nem kell tesztelni? És ha kell, a tesztek tesztjét? :)

Egy fokkal komolyabban: GUI-t is lehet automatizálva tesztelni? Mondjuk ha az a feladat, hogy egy piros, egy zöld és egy kék karikának kell megjelennie egy ablakban előre megadott méretben és pozíción (illetve ablak helyett a megfelelő grafikus objektumon), az ilyet hogy lehet tesztelni azon kívül, hogy megnézem?

Mióta először próbáltam unit tesztet írni, azóta érdekelne. A teszteket nem kell tesztelni?

Nem, azokat nem kell. Mérések alapján az igaz, hogy ugyanannyi teszt kód sorban kb. annyi hiba van, mint ugyanannyi kód sorban.

Egy fokkal komolyabban: GUI-t is lehet automatizálva tesztelni?

Igen, ezekre is vannak toolok, pl. a Selenium.

Letezik mutation testing, ami megmondja, milyen esetek felett siklik at a teszt.
https://en.wikipedia.org/wiki/Mutation_testing

Ha TDD-zel, akkor a teszt-production kod egyutt no, es emiatt nincs szukseg "tesztelni a tesztet", mivel a red/green/refactor-ban a red fazis bizonyitja, hogy a teszt kod kepes kiszurni a hibat.

Interaktiv GUI-t mindenkepp szemmel kell teszteni, de ezt lehet elore definialt, helyileg eloallitott adatokon (hogy ne kelljen adatbazisban turkalni).
User experience egyertelmuen nem tesztelheto automatikusan :)

Ha arrol van szo, hogy egy display engine-t probalsz tesztelni, akkor megoldhato a kep renderelese es egy masik keppel valo osszehasonlitasa. Az elterest kepes vagy szamban meghatarozni (pixel, szin, fenyero, stb.), es egy threshold-ot beallitani, hogy mik az elfogadott elteresek.
---
Lambda calculus puts the fun into functional programming

( luisex v | 2018. 03. 01., cs – 15:11 )

Sziasztok,
érdekes szavazás, ami kapcsán csak egy kérdésem van: mire?
Tudtommal a TDM/TDD még mindig csak egy eszköz, és nem világfilozófia, de javítsatok ki, ha tévednék :)
Üdv,
LuiseX

( Aadaam v | 2018. 03. 01., cs – 22:40 )

Ezeket az agilis vackokat ne hívjuk már tervezési módszertannak.

A tervezés az, ami megmondja, kinek, pontosan mit kell csinálnia a szoftvernek, és miért pont azt.

Ezt a legtöbb fejlesztési módszertan inputként kapja, nálunk a TDD az egy output converter a pipeline-unk végén, kb. mint amikor valami nem wordbe kéri az exportot hanem pdf-be.

Kaptak már tőlünk RUP / Crystal Use Cases, Scrum User Story és Jobs to be Done (JTBD) formátumban is tervezési outputot fejlesztők, de volt hogy megírtuk a tesztforgatókönyveket is. Ha holnap valaki azt mondja hogy Z specifikációs nyelven szeretné, abban fogja kapni.

Az Agilist azért mert sok helyen hülyén csinálják, még szerintem kissé flegma dolog vackoknak hívni. Lásd még: "Az, hogy nem hoztál sütit..."

Ha ezt ti meg tudjátok csinálni, hogy odamentek az ügyfélhez, és addig beszélgettek vele, ameddig kijön belőle olyan rendszerterv, amit aztán oda lehet adni a programozóknak, azoknak meg nincs más dolguk mint ezt lekódolni, akkor le a kalappal.
So 90s!
Eddig azt hittem ilyen csak a mesében létezik.

Én a valósághoz sokkal közelebb állónak látom a "köcsögjózsef" típusú ügyfeleket. (Lásd még f99)

Annak lehet, hogy kicsit nehéz megmagyarázni, hogy amiért kiköhögte azt a nagy halom zsét és aláírta, hogy azt kéri, aztán a végén megkapja és azt mondja, hogy "lehetne rózsaszínben?", annak kicsit nehéz elmondani, hogy lehet, csak tessék hozzá elővenni a pénztárcát.
És általában a lehetne rózsaszínben az tipikusan ilyesmi szituációban fog előkerülni:

https://youtu.be/BKorP55Aqvg

Specifikációs szolgáltatást nyújtunk.

Nem csak a mesében létezik, bár akik dolgoztak már velünk fejlesztőcégek, azok űrtechnológiának látják sokszor :)

És azért nem 90-es évek, látszólag számodra semmi nem változik, scrum van, backloggal, kéthetes iterációkkal, az változik, hogy hogyan van feltöltve ez a backlog, meg a demo cserélődik le jobb esetben usability tesztekre (mert valójában nem az a kérdés, te tudod-e nyomkodni a saját magad írta appot, hanem ha behozok valakit az utcáról, az összedönti-e).

Azt meg hogy hogy varázsoljuk ki az ügyfélből hogy konzisztens specifikációt tudjunk írni, az meg a mi szakmánk. Nem kell 7 merőleges piros vonalat húzni 2D-ben úgy, hogy az egyik átlátszó legyen, nyugi, neked már egy értelmes rendszert kell fejleszteni, belátható darabonként.

Kb. olyan mint egy szakértő PO, rendes "drótváz", design system komponensekre lebontva, rendes user story-k, acceptance criteria-k, és mindenre ott a MIÉRT.

Néha megjelenünk egy grooming meetingen és hozunk pár új story-t, meg azt látod hogy jól van feltöltve a jira.

Elmondta. Az "agilis vackok" úgy kezdődnek, hogy van itt egy backlog, hogy lehet konzisztensen, átláthatóan szállítani, és megoldani, hogy legyen feedback loop, és az ott előjött dolgok ne törtjék teljesen keresztbe a munkát. Arról sajnos nem nagyon szól, hogy hogy lesz egy használható backlog.

Igen, lassan szembe kéne nézni azzal, hogy a scrum egy implementációs módszertan, semmit nem szól arról, pontosan hogy jöjjünk rá arra, mit csináljon a program és miért azt, ezt már inputként várja, user story-k formájában.

A trükk arra rájönni, hogy ehhez nem követelmények kellenek, hanem komplett terv.

"Igen, lassan szembe kéne nézni azzal, hogy a scrum egy implementációs módszertan"

Ez szerintem nagyon nem igaz... lehet így tekinteni, lehet ezt propagálni ügyfélnek és ekkor el lehet adni egy szolgáltatást, ami során előáll egy komplett terv és annak a lebontása story listára, de a scrum nem erről szól... ez egy öszvér módszertan, ahol a tervezés klasszikus vízesés modell, az implementálás meg agilis, de inkább az implementálás is vízesés modell, csak rá van húzva egy scrum köpeny, ahol a mérföldköveket sprint demónak hívjuk.

Ha a sokadik sprint után visszanézel és nem látsz kidobott terveket, nem látsz fejlesztési zsákutcákat, nem látsz evolválódott felületeket és interfészeket, nem látsz komoly refactor nyomokat, akkor az nem agilis fejlesztés volt, hanem egy kutyaközönséges vízesés modell, amit agilisnek adtak el, mert az ügyfél agilis fejlesztést kért.

Miért kéne a heti milliós nagyságrendbe kerülő fejlesztőket kidobott tervekre pazarolni? Vannak kidobott tervek - nálunk. Hetente akár több is.

Evolválódás is van, az is nálunk, akár napi szinten, de van persze hogy valamit át kell írni új feature miatt. Azt az ügyfelek és a fejlesztők is utálják amúgy, hiába az embrész cséndzs.

Sokkal gyorsabb az inkrement a dizájnban mint fejlesztésben, ami itt fél nap, az a fejlesztésben egy sprint. User feedback akár naponta (durvább esetben félnaponta) van, ilyen sűrüséggel release-elünk.

Nem egybe kap egy nagy tervet az ügyfél, ún. Epic-szintű tervek jönnek pár hetes periódusokban. Mondjuk a HUP esetén a kommentelés egy ilyen epic lehetne, a szálakkal, válaszolással, szerkesztéssel, de az egész HUP nem egybe jönne le. Tipikusan ennek a felét tudna egy csapat két hét alatt megirni.

Komoly refaktor nyomok... hadd ne mondjam, mit látok néha a büszkén agilis fejlesztőcégeknél. Örülök, hogy nyomnak entert a pontosvessző után. Jóideje nem nézek bele a forrásokba, néha elgondolkozom a projekt felénél, hogy még mindig jobban megérné kidobni a csapatot és keresni másikat...

A dolog lényege, hogy előbb jöjjünk rá, mire van szükségünk, ellenőrizzük, hogy tényleg erre és így-e, és utána dobjuk csak rá azt a tízmilliós nagyságrendet amibe egy fejlesztés kerül. Mi kb. a fejlesztési költségek tizedébe kerülünk.

Miért kéne a heti milliós nagyságrendbe kerülő fejlesztőket kidobott tervekre pazarolni? Vannak kidobott tervek - nálunk. Hetente akár több is.

Azért, mert ha időközben nincs egy-két greenfield vagy R&D jellegű projekt, akkor leragadtok egy olyan technológiai stack használatánál, amit épp ismertek.
Új technológia, max tapasztalt új ember felvételével fogja növelni a portfóliót.

Közben a fejlesztők csak rabszolgamód nem csinálnak mást, csak a terveiteket átírják kódba. Amit meg lassan (mondjuk 20-30 év múlva) egy AI is meg fog tudni csinálni.

Ha valamit a saját károtokon tanultok meg, akkor nem csak avval lesztek tisztában, hogy egy-egy eszköz mire nem jó, de a határait is megismeritek, hogy mire jó. Talán itt volt a múltkor a hype driven development linkelve.
Azért a chart végén ott is volt egy "Realisation" fázis, amikorra is mindenki tisztába kerül vele, hogy egy egy technológia pontosan mire jó, hogyan skálázódik, stb. Az ilyet csak first hands experience útján lehet felszedni.
Néha be kell koszolni ilyennel a kezet, még ha zsákutca is. Nem biztos, hogy éppen azon a projekten fogja visszahozni a belefektetett időt és erőforrást, ami mentén beleöltétek az erőforrásokat.

De ha jók vagytok, akkor gondolom úgyse csak egy üf-nek dolgoztok, folyamatosan van business pipeline és amikor meg épp az a technológia lesz a nyerő megoldás egy adott komponenshez, akkor ott már nem evvel kell vesződni, csak használni a már meglévő tudást.
Ott lehet más "zsákutcából" tanulni.

Kidobott terv szerintem nincs, csak olyan "projekt", aminek a tanulságait esetleg később, valami más kapcsán fogod felhasználni.

És közben az emberek sem maradnak motiválatlanok, vagy ragadnak le egy fix befásult monoton munkába és aztán húznak el a megszerzett tudással máshová.

My 0.02€

Nem foglalkozunk a technológiai stack-kel, az nem a mi dolgunk, tisztán tervezőcég vagyunk.

Van egy általános rendszerünk arra, hogy tudjuk az adott platform vagy iparág jellemző technológiáit beilleszteni, ez "design patterns" (pontosabban pattern language) alapú. Ezzel az AI megoldásokat is sikerült "bekötnünk" idén a rendszereinkbe.

A fejlesztő ezt hogy oldja meg - rá van bízva. Nyilván megfigyelhető a szokásos pattern, a hit mindig legyőzi a racionalitást, azaz a .NET fejlesztő majdnem mindent .NET-ben fog, a javascriptes mindent javascriptben, a drupalos mindent drupalban. Az ügyfélnek meg haverjai vannak, meg garasoskodása, vállatvonunk, nekünk egyre megy.

A mi embereink motiváltak, mert mindig új domain, mindig új alkalmazáskörnyezet, nyilván a trükk az, hogy nem egyetlen fejlesztőcéggel dolgozunk, nem egyetlen alkalmazáson. Van hogy az egészségügyet kell könyékig érteni, van, hogy a logisztikát, van hogy a marketinget.

De mi inkább a domainekbe és a problémamegoldásba vagyunk szerelmesek azt hiszem, nem a technológiába :) az csak egy eszköz.

"Nem foglalkozunk a technológiai stack-kel, az nem a mi dolgunk, tisztán tervezőcég vagyunk."

Nagyszerű. És honnan döntöd el mondjuk, hogy egy szimpla fórumnál mi a legjobb technológia, ami a legjobban lefedi az üzleti igényt és ez hogy tud futni abban a környezetben, ahova kerülni fog? Mi van akkor, ha a technológiai stack pénzügyi szempontjai beleszólnak az üzleti igényekbe? Mert nem egyszer fordult elő, hogy ha egy gombot ide teszek, az havonta $100 pénz licencben, ha oda teszem, akkor meg havonta $10000 pénz licencben, ez hol csatolódik vissza a tervezésbe?

Nem foglalkozunk a technológiai stack-kel, az nem a mi dolgunk, tisztán tervezőcég vagyunk.
A fejlesztő ezt hogy oldja meg - rá van bízva.
Az ügyfélnek meg haverjai vannak, meg garasoskodása

Pedig a tervezésnél ezeket mind bele kellene tervezni, különben borítékolhatóan bukta lesz a projektből.

Ez is érdekes hozzáállás: vállatvonunk, nekünk egyre megy

Bukta nem lesz belőle, csak mondjuk drágább lesz, mint amennyiből egyébként ki lehetne hozni, ha tényleg összeülnek azok, akiknek össze kellene ilyenkor ülnie.

Vannak olyan területek - mondjuk jellemzően az állami szféra és a nagy mamutok, ahol ez nem feltétlen számít, hogy valami kevéssé hatékony vagy kirívóan pazarló, mert úgy sincs annyi ügyfél, hogy komoly problémákkal szembesülnének az üzemeltetés során... ha meg mégis, akkor lehet mutogatni, hogy a tervezés kilóra megvolt, pláne volt wow-faktor is benne, aztán a fejlesztést és az üzemeltetést baszták el. Mondjuk általában igaz, hogy faszság volt tervezve és a végig nem gondolt folyamat miatt kellett plusz erőforrásokat súlyos milliókért alátenni, de soha senki nem méri vissza, hogy ez milyen arányban az üzemeltetők, a fejlesztők vagy a tervezők sara, úgyis az üzemeltetők fognak szopni vele évekig.

Általában bemutatják Bélát és barátait. Béla és barátai mindig hisznek valamelyik technológiában. Hogy ez most az UWA .NET, a java server faces vagy valamelyik JS framework, szempontunkból egyre megy. Nem mindig értünk vele egyet hogy ez lenne az ideális technológia a feladatra, de sajna ahhoz Béláékat kéne Laciékra cserélni, az meg úgyse lesz.

Mint a kis piros labdakatalógust elővesszük az adott cucc dokumentációját, megpróbáljuk kideríteni, mi az ami lassú benne (pl. régen Nokia mobilok nem bírtak sarkokat lekerekíteni gyorsan egy videókártya bug miatt), megpróbáljuk megtudni, Béláék miben ügyesek.

De az elsődleges feladat, hogy kiderüljön, milyen infókra kiváncsi a user, honnan kapja őket / hogyan tudja a legminiáisabb efforttal beadni őket és mit csinál velük.

Ez teljesen független attól, Béláék miben hisznek, nekünk arra kell rájönni, mi a megoldandó feladat, és találni rá egy megvalósítható megoldást, ez max abban változtat, mennyi idő lesz lefejleszteni.

Képzeld el úgy, hogy kapsz egy zsák Star Warsos legót, hogy meséld el vele az Ébredő Erő sztoriját. Elmeséled. Másnap kapsz egy másik legókészletet (pl. Bionics) és megkérnek, hogy ezzel meg az Utolsó Jediket meséld. Lehet, nem alkalmas rá, de a legókészlet adott, neked a mesélésben kell otthonosnak lenned, és kreatívan kell tudni alkalmazkodni a körülményekhez.

A legókészlet az a platform. Azért nem lényeg, mert adottság, meg mert arra kell figyelni, mit kell belőle kihozni.

Amúgy nem ez a kidobott idő, hogy a csapat nézegeti egy picit a legósdobozt, hanem amikor az nincs végiggondolva, mi a sztori amit el akarunk mesélni, dehát az a mi dolgunk hogy ezt kiderítsük.

Egy fokkal konkrétabb: egy projekten egy olyan alkalmazás UI refactorát kellett megoldani, amit egy solr pluginnel meg egy picit megpofozott solr frontenddel pikkpakk össze lehetett volna rakni java/html/js alapokon.

Sajna viszont az app nemhogy oracle-delphi kombóban volt írva, de volt hozzá egy oridzsi oracle DBA meg egy delphi frontend csapat. A DBA az ötletről se akart hallani, hogy esetleg ne Oracle legyen az engine (pedig hátul maradhatott volna az), és hát a delphis srácok se azért maradtak a delphi mellett mert nem tűnt fel nekik hogy mintha egyre kevesebb delphi app lenne és egyre több webes. Sőt, egy webes appot cseréltek le anno erre.

Kerestünk dephi komponenskönyvtárakat, találtunk egy UI megoldást amiben nem annyira katasztrofálisan ronda és kirívó a delphi app, és átterveztük a delphi platfom megtartásával. Az oracle FTS-t pedig sikerült addig pofozni amíg nem hozott élhető válaszidőket. Mindenki happy: user számára kb ugyanazt tudja mint a solr-es tudna, a programozók meg maradhattak a platformjukon.

A user nem webappot akart hanem egy olyan appot amire rá lehet nézni reggelente és lehet agy nélkül is használni. A cél az volt hogy ne kelljen keresnie mi mit csinál, ne kelljen megtanulni.

A platform, az mindegy. Tényleg.

GDD-t (Goal Directed Design) használunk mint tervezési módszertan, nem része az agilis hype-nak, az informatika nem is nagyon vesz tudomást a tervezési módszertanokról (User-centered design, Design Thinking), de még tudományterületeiről (user research, information architecture, stb) sem. Néha megjelenik egy-egy tervezési könyv, amit aztán kevesen alkalmaznak a gyakorlatban...

Sprintszinkron van a fejlesztőkkel, de igazából az csak szakaszhatár, interfészeljük a scrum-ot ahol csak lehet. Belül mi sem teljesen vizesünk de jobban hasonlít a RUP-ra mint a scrum-ra, azaz a különböző munkafolyamatok különböző intenzitással, párhuzamosan mennek, van ami ciklikus szervezésű, van, ami nem.

Én őszintén hiszem, hogy a szoftverfejlesztés és a szoftvertervezés külön szakág, ahogy az üzemeltetésnek is sikerült leválni szépen.

ha behozok valakit az utcáról, az összedönti-e

Remélem pozitívan fogadod a kritikát, ahogyan építőjelleggel szánom:
- Ha a usability a cél, miért azt tesztelitek, hogy egy random utcáról behozott ember össze tudja-e dönteni? Inkább azt kellene tesztelni, hogy a random utcáról behozott ember, tudja-e intuitíven használni. Az sem baj, ha 100 fölött van az IQ-ja.
- Ha meg a "durability"/security a cél, akkor arra meg van csomó féle fajta fuzzer. Olvasva lentebbi hozzászólásodat is: lehet, hogy nem is ártana, ha néha nem mersz belenézni a kódba, vagy felmerül benned, hogy most még olcsóbb lenne kivágni a fejlesztőbandát, és 0-ról újrakezdeni.

Amúgy respect a többi részért! A 90-es évekre célzást meg úgy értettem, hogy ennyire "vegytisztán", tervezőasztalon készült dolgot utoljára még az egyetemen hallottam. A való életben és a gyakorlatban úgy tűnik, ezek a módszertanok sokszor rugalmatlanok, lekezelni azt, amilyen szélkakas-gyorsasággal meg tudja gondolni ügyfél magát, mikor 1-1 mérföldkőnél demózás van.
Persze, személyesen ilyen fajta ügyfelekkel nem volt dolgom. Kivételesen jó helyzetben volt alkalmam szoftvert fejleszteni ;-)
Inkább én is csak war storyk alapján ismerem az ilyen ügyfeleket, csak a magyarországi ismerettségi körben, meg szinte csak ilyet hallani.

A végével kicsit összezavartál: groomingon hozod be az új story-kat? Azt nem a sprint planningen szokás?
Nekem úgy rémlik, a groomingnál csak kivételes esetben tolunk bele futó sprintbe új storykat. Ott max prió-kon finetunolunk a sprint hátralévő részén finomítandó, meg kb. állapotegyeztetés a folyó sprintről.

Az össze tudja-e dönteni alatt én usability-t (is) értettem, de gyakran a user olyan sorrendben próbál valamit elérni ami nincsen jól leprogramozva, és ezért az app hibára fut.

Durabilty más tészta.

Az ügyfél azért gondolja meg magát, mert ott látja először, mit kap. Nem gondolja meg magát egy jól előkészített UX projekten, ezek le vannak kezelve, ott vagyunk a demón is.

Groomingon hozzuk be az új story-kat de nem az aktuális sprintre, hanem a rákövetkezőre, azaz ott beszéljük át, mi az ami nem érthető, nem elég részletesen kidolgozott vagy technikailag challenge-elt. Muszáj hogy legyen egy ilyen meeting, és úgy látjuk, jobb ha ez nem akkor derül ki amikor az ügyfél arra számít, ez két hét múlva meg lesz. A fejlesztőnek is jobb hogy nem aznap tudja meg, mit fog csinálni a következő két hétben. Picit persze leopárd harap, de mi se tudunk mindenre reagálni a planningen úgy, hogy abból becsülni lehessen.

Hmm... Azért az viccesen hangzik, hogy valamit annyira hibásan programozzanak le, hogy rossz sorrendben eléréstől hibára fusson egy app.
Persze el tudom képzelni, hogy ilyen előfordul. Csak épp ahhoz agyhalott kóderek kellenek.

Persze, amit fent a solr-es vs. oracle-s sztorinál leírtál, eléggé sugalja, hogy akadnak ilyesmik :)

A másik részét köszi! Így már érthetőbb, sött egy kifejezetten pozitív példa. Mondhatni wow faktor!
Kb. nagykönyvi példa, vagy hogy is mondjam, hogy na így kell jól agilisen! ;-)
Remélem nem veszed sértésnek (ha jól rémlik, te vackoztad le feljebb az "agilist"), de szerintem EZ az agilis, illetve, ahol nem így csinálják, na ott is így kellene!
Le a kalappal! ;-)