Budapest Agile Meetup - 2012.03.08. http://www.meetup.com/AgileHungary/events/50473012/ http://agilehungary.hu/

1. The Clean Coder
A Code of Conduct for
Professional Programmers
(Robert C. Martin)

3. Uncle Bob Martin

6. Ki volt a felelős?
• A rakéta tervezői?
– Tudtak a problémáról, jelentették 7 évvel korábban.
– A javításra megvolt a javaslat, de a vezetés halogatta a
megvalósítást.
– Közvetlen az indítás előtt is felhívták a figyelmet a problémára.
• A NASA döntéshozói?
– Hatalmas politikai és anyagi nyomás alatt döntöttek.
– Úgy érezték a mérnökök aggodalmai túlzóak (bizalomhiány).
• Elég-e tudomásul venni, hogy a vezetők voltak a
hibásak?
– Nyugodtan aludtak-e a mérnökök aznap éjszaka?
– Tehettek-e volna többet?

8. Katasztrofális bugok
• MIM-104 Patriot rakéta számítási hiba miatt célt tévesztett, ezzel 28
amerikai katona életét oltotta ki.
• 1983-ban majdnem atomháborút okozott a rakétaelhárítás hibásan
működő szoftvere.
• Ariane 5 rakéta 1 milliárd dolláros prototípusa egy bug miatt
önmegsemmisített.
– További drága bugok az űrkutatás területén: Mars Polar Lander, NASA
Mariner 1, Phobos 1, Mars Global Surveyor
• 2003. augusztus 14-én több államnyi területen elment az áram
milliárdos anyagi kárt okozva.
• Therac-25 sugárterápiás eszköz hibás működése 5 emberéletet
követelt 1980-ban.
• 1992 áprilisában az első F-22 Raptor software hiba miatt landolás
közben a földnek csapódott.
• 1982 -1983: Vancouver Stock Exchange Index számításában
felhalmozódtak a kerekítési hibák és újraszámításnál kiderült: nem
520, hanem 1098.892 kéne, hogy legyen.

10. Felelősségvállalás
• Felelősségvállalás tetteinkért.
– Ha kell, akár anyagi értelemben is.
– Bizonyos értelemben programozni arrogancia:
• Azt állítod, képes vagy elvégezni 10 , 100 vagy éppen több ezer
ember munkáját egyszerre.
• Hatalmas felelősség: könnyen okozhatsz annyi kárt, mint 1000
„átlagember”.
• Ne gúnyold, aki hibázott (inkább segíts).
• Viseld méltósággal, ha a hibáidért büntetnek, vagy gúnyolnak.
– Ne vedd a szívedre, ha igaztalanul teszik.
• Ne tégy kárt.
– A célod mindig a hibátlan program legyen.
• Nem sikerülhet mindig, mert a programok bonyolultak.
• Az emberi test is az, mégse mondja az orvosod azt, hogy „néha
megesik, hogy a beteg meghal a műtőben, ez normális”
• Tanulj meg őszintén bocsánatot kérni!

11. A konfliktus értéke

12. A konfliktus értéke
• Egy cégen belül mindenkinek van felelősége.
– Mindenki a saját érdekeit kell, hogy védje:
• A gazdasági vezető érdeke, hogy ne folyjon el a pénz.
• A termék manager védi a használhatóságot.
• A projekt manager a határidők teljesítéséért felelős.
• A TE feladatod, hogy megtartsd a fejlesztés lendületét, és
REÁLIS információkat szolgáltass annak állapotáról.
– Ne térj ki részletekre:
» Jó esetben amúgy se érdekli, mert a TE dolgod.
» Rossz esetben még beleszól a végén.
– Közös megegyezés:
• Addig vitázzatok, amíg közös nevezőre nem jutottatok.
• Ne próbálj hős lenni. (Ha túlhajtod magad, csökkenni fog a
teljesítményed.)
• Megpróbálom = Megcsinálom. (Számítani fognak rá!)

13. Team player?
• Tévhit • Realitás
– Mindig azt próbálja – Nemet mond, ha kell, de ha
teljesíteni, amit kérnek tőle. igent mond, azt be is váltja.
– Kerüli a konfliktust. – Megoldja a konfliktust.
– Nem kerüli meg a – Ha szükségesnek
feletteseit. érzi, magasabb vezetőknek
is jelzi a problémát.
– Nem enged a célokból. – Időben felismeri, ha nem
reálisak a célok.
– Ha kell, feladja az – Ragaszkodik az
elveit, hogy időben kész elveihez, mert tudja, hogy a
legyen. kapkodás csak lassít a
munkán.
– Ismeri a határait. Ha mégis
– Ha kell, zokszó nélkül kell túlórázni, azt
túlórázik. pihenéssel kompenzálja.

14. Elhivatottság
• Az elhivatottság fokai:
– Azt mondod, hogy meg kéne tenned.
– Az gondolod, hogy (majd egyszer) megteszed.
– Meg is teszed.
• Az elhivatottság hiányának nyelve:
– Kellene / Bárcsak / CsinálJUK meg / Majd egyszer
• Ha ezt hallod, ne számíts megoldásra!
• Az elhivatottság nyelve
– Megcsinálom! (Nem mi, nem valaki, hanem ÉN!)
– Ne hagyj magadnak kiutat.
• Ne várj másra!
– Beszélj meg vele időpontot.
– Ha szükséges, javasolj hetenkénti találkozót.
– Absztraháld az interface-t, hogy addig is tudj haladni, amíg rá vársz.
– Ha még mindig nincsenek készen, akkor készíts mock-ot az ő
rendszerükre, hogy a sajátodat tudd tesztelni.

15. Becslések
• A becslés nem egy szám, hanem egy eloszlás.
– Ez a tényt mindig tedd egyértelművé.
– Vigyázz, hogy ne vállalj implicit módon kötelezettséget
olyanra, amit nem tudsz biztosan teljesíteni.
– Amíg nem vagy biztos a dolgodban, ne vállalj be határidőt.
• Használd a PERT módszert.
– Optimista becslés, normális becslés, pesszimista becslés.
• Ezekből sok egyéb információ számolható.
• Bontsd fel a feladatokat apró részekre.
– A nagyszámok törvénye szerint, minél több becslést
aggregálunk, annál kisebb lesz az eltérés esélye.
• Becsülj csapatban:
– Több ember kisebbet téved.
– Wideband Delphi alapú módszerek:
• Flying fingers, Planing poker, Affinity Estimation

16. Csúszások
• Senki sem tökéletes, előfordul, hogy kicsúszunk az
időből:
– Soha ne remélj: légy tárgyilagos, és ismerd fel minél hamarabb a
csúszást.
• „Monitor your progress” (Pl.: burn down chart.)
– Ne kapkodj: a kapkodásnak később nagyon megfizeted az árát.
• False delivery: hamis meggyőződés, mely szerint kész vagy, és
tovább mehetsz:
– Legyen a késznek pontos definíciója:
» FitNesse, Selenium, RobotFX, Cucumber
• Martin Fowler megengedőbb: Technical debt.
– Túlórák:
• Néha szükséges, de nagyon gondold meg, hogy mikor élsz vele:
– 2-3 hét után többet rontja a hatékonyságot, mint amit segít.
– 20% túlóra NEM hoz 20% több eredményt.
– Legyen B terv arra az esetre, ha a túlóra sem segített.
– Ne áldozd fel a magánéleted, és ne várd ezt mástól se.
» Nincs rosszabb, mint a rosszkedvű programozó.

18. A lendület megőrzése
• Ne hagyd, hogy a program elrohadjon.
– Azért soft a software, mert könnyű változtatni.
• Ez mindig legyen igaz!
• Akkor marad rugalmas a struktúra, ha nem hagyod
megkövülni.
• Ha kezd áttekinthetetlen lenni a forráskód, ne menj tovább.
• Boy scout rule / Betört ablak elv: Refaktorálj, amint úgy
érzed, hogy valamit lehetne jobban is.
• Emlékezz rá, hogy a rendetlen kód exponenciálisan lassít le.
– Veszélyes a folyamatos változtatás?
• Az igazán veszélyes az, ha minden változtatás sok apró 1-1
soros módosítássá válik.
– Mit tegyünk a veszély ellen?
• Használj védőhálót = Automatizált tesztek

19. Felkészültség
• A software fejlesztés nehéz feladat:
– Egymásnak ellentmondó követelményeknek kell megfelelni.
– Kreativitást igényel minden egyes lépés.
• Légy mindig kipihent.
– A hajnal 3-kor írt kódban mindig sok a hiba.
• Ha lassulsz, elakadsz, ne akarj hős lenni: menj
haza, pihenj, zuhanyozz le, reggel be fog ugrani a megoldás.
– Fáradtan az ember hajlamos „keresztbe drótozni” dolgokat.
• Rossz és visszafordíthatatlan döntéseket hozunk.
• Aggódás:
– Ha agyilag máshol jársz, nem haladsz.
– Lehetőleg oldd meg a gondjaidat a szabadidődben.
• Ha megengedett, hogy eltold a munkaidődet 1-2 órával, akkor ezt
használd arra, hogy közelebb kerülj a megoldáshoz. (Sokszor elég
a megnyugváshoz.)
• Ha ez nem fér bele a cégkultúrába, akkor viszont ne késs emiatt!
– Ha muszáj elkezdened dolgozni, akkor 45 percenként szánj 10
percet a probléma megoldására.

20. Útvesztők és egyéb csapdák
• Least objectional activity / Priority inversion
– Néha előfordul, hogy amit csinálnod kell, ahhoz nincs
kedved.
– Ilyenkor könnyen esünk abba a hibába, hogy
meggyőzzük magunkat arról, hogy egy másik feladat
mégis fontosabb.
• Kifogásokat gyártasz és hazudsz magadnak, hogy
felkészítsd magad arra, hogy másnak is hazudj.
• Útvesztők
– Néha rosszul döntünk, de ilyenkor ismerjük fel
mielőbb.
• Ne győzködd magad, hogy jó lesz, ha látod, hogy nem.

21. Kollaboráció
• Programozók maguk közt
– Ne birtokold a kódot.
– Pairing
• Ha megzavarnak, a párod segít visszazökkenni.
• Ha fáradt vagy, segít tartani a ritmust.
• Rákényszerít, hogy pontosabban gondolj végig mindent.
• Programozók és munkáltatók
– Tartsd tiszteletben a cég értékeit.
– Értsd meg az üzleti célokat.
– Értsd meg a csapatod céljait.
– Figyelj oda a határidőkre és egyéb fontos
információkra.
– Legyél politikus.

22. Értsd meg, mivel foglalkozol
• Azonosulj a megrendelővel / főnököddel:
– Az ő problémája végül a tiéd is!
– Mindig a cég érdekeit tartsd szem előtt.
– Nem az a célod, hogy holnap elégedett
legyen, hanem az, hogy a közös célt elérjétek.
• Ismerd meg a területet:
– Ne vakon programozz: ismerd meg a felhasználók
szakterületét legalább alapszinten.
– Rettenetes hiba pusztán a specifikációból dolgozni:
ismerd a témát annyira, hogy észrevedd a hibákat
benne.

23. Teams
• Az összeszokott team sokkal jobb.
• Ne projektek köré szervezzünk csapatot, hanem
kész csapatot rendeljünk projekthez.
– Egy összeszokott csapat képes akár több projektet is
effektíven szétosztani egymás között.
• A csapatok teljesítménye mérhető bizonyos (heurisztikus)
metrikákkal.
• Megadható egy csapatnak, hogy a fenti teljesítménymérők
tekintetében hogyan ossza meg az idejét több projekt között.
– Adott esetben átmenetileg ez eltolható egyik-másik projekt
javára, ha határidő közeleg.
• Fél emberek nincsenek
– A feladatok közötti kontextus váltás időt emészt fel.

24. Meeting
• Szükségesek és hasznosak.
• Egy rossz meeting rengeteg időt elpocsékolhat.
– Anyagi oldal: egy átlag 1 órás meeting ára $200/résztvevő
– A munkáltatóddal szembeni kötelességed, hogy NE menj el
olyan meetingre, ami nem érint.
• Legyen pontos agenda.
– Ha nem érint, illedelmesen mondj rá nemet.
– Ha eltérnek az agendától, hívd fel rá a figyelmet.
– Ha valamiért mégsem érint a téma, illedelmesen távozz.
• Stand-up meetings
– Segít tartani a tempót.
• Vitás kérdések:
– Ami 5 perc alatt nem dől el, azt szimpla vita nem dönti el.
– Légy tekintettel másokra, ha őket nem érinti, a vitát meeting után
folytassátok.

26. Flow zone
• Meditatív állapot, melyben a fejlesztő
hatékonynak érzi magát, és képes gyorsan
nagymennyiségű kódot írni.
– Probléma:
• Valóban több kód születik ilyenkor, na de olyan is...
• Mivel úgy érezzük, kevésbé hibázunk, kevésbé is vesszük
észre, ha mégis.
• Könnyebben feladjuk a diszciplínáinkat. (Például TDD esetén
több kódot írunk meg egy iterációban, mint kéne.)
• A flow-ból kiszakított programozó sokszor durván reagál, ha
kérdeznek tőle valamit.
• A pair programming segít kívül maradni.
– Gyakorláshoz viszont jó.

27. Flow zone
• Zenehallgatás:
– Kizárja a külvilágot, de befolyásolhatja a
döntéseinket. (Dalszövegből kiragadott elnevezések.)
– Könnyebben kerül az ember flow-ba.
• Ha kizökkentenek:
– Ne reagálj agresszívan, ne éreztesd a másikkal, hogy
megzavart.
– A TDD segít abban, hogy kontextusban
maradj, hiszen a nem működő teszt megmutatja, hol
tartottál.

28. Pomodoro technika
• 25 percre állítsd be, addig
koncentrálj arra, amit
csinálsz.
• Utána 5 percig foglalkozz
mással.
– Hívd vissza azt, aki
keresett.
– Válaszolj annak, aki
kérdezett tőled.
– Ha nem történt
semmi, akkor csak kapcsolj
ki picit.
• Minden negyedik ilyen
után tarts 30 perc
szünetet.

29. A hiba megelőzése
• A teszter már ne találjon hibát!
– Költséges egy nagy QA team fenntartása.
– A debuggolásra szánt idő épp olyan drága, mint a fejlesztésre
szánt.
• A hiba megkeresése sokszor több idő, mint a megelőzése.
– Ha sok hibát talál a QA, az megrendíti a vezetők bizalmát a
csapatban.
– Felelőtlen és lusta hozzáállás:
• A teszterek csak szűrik a hibákat, sok elkerülheti a figyelmüket.
• Tesztelj minden egyes módosítást!!!
– Automatizáld a teszteket.
– A 100% lefedettséget célozd.
– Nincs nehezen tesztelhető feladat, csak rosszul tervezett
program!
• Design for tests!
– A tesztelés minden szintjén automatizálj, így bizonyos esetekben
QA team már nem is kell (pl.: FitNesse).

31. Test Driven Development
• Rövid iterációk
• Alaposan tesztelt kód
– Amit elveszítesz időben a teszt írással, visszanyered a debuggolásnál.
• Modulárisabb forráskódot kényszerít ki.
• A felhasználó szemszögéből tervezed az interface-t.
• Segíti a refaktorálást, bátorságot ad a változtatásokhoz.
– „Ki kéne javítani!” <VS> „Hozzá nem érek!”
• Több tanulmány is született már a hibaráta csökkenéséről, és a
fejlesztés felgyorsulásáról.
• Vannak nehézségei (pl.: IP kapcsolatot tartalmazó program
tesztelése), de ezekre már mind született megfelelő megoldás.
(Komoly irodalma van a TDD-nek.)
• Példákon keresztül dokumentálja a használatot.
• Stb, stb, stb.

32. „The user doesn't know what he wants.”

33. Felhasználói igények
• A megrendelő nem tudja, mit szeretne.
– Ami papíron jól hangzik, gyakorlatban lehet mesterkélt.
• Készülj fel a változásokra.
• Ne tervezd túl a dolgokat előre.
• Ne próbálj túl pontosan becsülni határidőt.
– Hangsúlyozd, hogy becslésről van szó.
– A diagramjaidon szerepeljenek hiba határok.
• Kétértelműség
– Ha a döntéshozók nem értenek egyet, sokszor megkerülik a
döntést.
• Ha valami kétértelműt látsz a specifikációban, jó esély van rá, hogy
ide-oda kell majd változtatni.
– Sokszor feltételezzük implicit módon, hogy a másik tud
valamit, vagy egyetért velünk valamiben.
• Ha valamiben nem vagy biztos, kérdezz.
• Ha nem kapsz egyértelmű választ, vagy hezitál a
döntéshozó, készülj fel a változtatásra.

34. Acceptance Tests
• Definíció: olyan automatizált teszt, melyet a fejlesztők
(főleg QA részről) és a döntéshozók közösen írnak a
fejlesztés megkezdése ELŐTT, annak érdekében, hogy
a „KÉSZ” fogalmát pontosítsák az egyes felhasználói
igények esetén.
– Nem ugyanaz, mint a User Acceptance Test, ami kézi, és a
munka befejeztével valósul meg.
– Happy path vs. Unhappy path. (Stakeholders vs. QA)
• FitNesse:
– Acceptance testing keretrendszer
– Automatizált és Wiki alapú
– Egyszerű nyelvezetű, így a fejlesztéshez nem értő döntéshozók
számára is elérhető.
– Kikényszeríti a könyörtelen precizitást a requirement
megfogalmazóitól.

35. Fitnesse Példa
given the command LogFileDirectoryStartupCommand
given that the old_inactive_logs directory does not exist
when the command is executed
then the old_inactive_logs directory should exist
and it should be empty
given the command LogFileDirectoryStartupCommand
given that the old_inactive_logs directory exists
and that it contains a file named x
When the command is executed
Then the old_inactive_logs directory should still exist
and it should still contain a file named x

38. Unit test vs. Acceptance test
• Implementációra • Követelményekre
vonatkozik. vonatkozik.
• Programozóknak • Döntéshozóknak és
szól. programozóknak szól.
• Az egység a függvény • Az egység a user
és az osztály. story.
• Az implementációt • A követelmény
segíti. megértését segíti.
Mindkettő elsősorban dokumentáció, és csak
másodsorban teszt!

39. Egyéb megjegyzések
• Ne légy passzív agresszív:
– Ha egy teszt fura, egyeztess annak írójával.
– Rossz hozzáállás: „Ezt kérték, ezt implementálom”.
• GUI-n keresztül csak GUI-t tesztelj.
– Válaszd le teljesen a magrendszerről, már csak az SRP miatt is.
– A GUI gyakran változik, fenntarthatatlanná tenné a teszteket.
• Mind a unit, mind az acceptance test rendszer legyen
összekötve a verziókövetővel (Continous Integration)
– Minden commit váltson ki egy teljes tesztet.
– Senki ne commitoljon failing tesztet.
– Ha mégis fail van, akkor mindenki azonnal azzal foglalkozzék.
– Soha ne kommentezz ki tesztet.
• Martin Fowler kicsit lazább: limitált méretű quarantine

41. Teszt piramis

42. Teszt piramis
Közel 100% lefedettséget
kínáló, implementáció
specifikus tesztek, melyeket
a programozók maguknak
írnak.

43. Teszt piramis
Acceptance tesztek közül
azok, melyek üzleti logikát
tesztelnek optimális
feltételek mellet.
Interakcióba csak mock
objectekkel léphet.

44. Teszt piramis
Komponensek közötti
kommunikációt
teszteli, tipikusan a lead
architect írja. Néhány
performancia teszt is lehet
benne. Napi 1 futás.

45. Teszt piramis
Egyben teszteli az egész
rendszert. Itt is lehetnek
performancia tesztek.

46. Teszt piramis
Az egyetlen manuális teszt
csoport. Teljesen adhoc, és
a lényege épp az, hogy
azokat az eseményeket
váltsa ki, amikre senki nem
számított. (Bug hunt day.)

48. A tudás hatalom
• A mi szakmánkban 5 év nagy idő.
– A munkahelyi feladatok általában nem mozgatják
meg minden képességedet.
• Előfordulhat, hogy amit már rég elfelejtettél, arra lenne
szükséged, és nem is veszed észre: frissítsd a régi tudást is.
• Aki nem ismeri a múltat, előbb-utóbb megismétli azt.
– A technológiák olyan gyorsan tűnnek el, amilyen
gyorsan megjelennek.
– Nem a munkáltatód feladata, hogy képezzen téged.
• A Te piaci értéked múlik ezen, nem az övé.
– Nem munkaidőben kell ezt megtenned.
• Legyél hálás, ha kapsz rá időt!

49. Tanulj
• Cél: Átlag heti 20 óra tanulás
– A manager pozíció (ide értve a CEO-t is) nem ad felmentést!
– Ezt az időt semmiképp ne töltsd munkahelyi feladatokkal: ez a
TE időd!
– Edzés közben, vezetés közben hallgass podcastokat.
– Olvass a vonaton szakkönyveket.
– Alapíts a barátaiddal Code Dojo-t.
– Gyakorold a Kata-kat.
– Tanulj meg új nyelveket!
• Lehetőleg olyat, ami nem hasonlít arra, amit épp használsz.
– Burn out? Ellenkezőleg: ezt az időt arra szánd, amiért szereted a
munkádat.
• Dolgozz közösen másokkal.
• Légy mentor: taníts, abból többet tanulsz.

51. Gyakorlás
• Kata
– Harcművészetekben: formagyakorlat
• A harc egyik felét imitáló mozgás.
• Célja: a test felkészítése a helyes reakciókra, a
mozgás folyamatossá tétele.
– Programozás terén:
• A fejlesztőkörnyezet kiismerése.
• Design elvek berögzülése.
• Különböző döntések következményeinek
megértése.
• Diszciplínák (pl.: TDD) gyakorlása

53. Tágítsd a látóköröd
• Nem egészséges beleragadni egy
technológiába.
– Ki tudja meddig használják még?
• Open source projects
– Lehetőleg olyan nyelven, amit munkahelyen
nem használsz.
• Ha otthon vagy dojo-ban
gyakorolsz, gyakran válts nyelvet.
– Akár egy napon belül is!

55. Felhasznált képek
• Rajzok: Robert C. Martin: The Clean Coder
• Egyéb képek:
– http://www.acclaimimages.com/_gallery/_image_pages/0124-1003-0412-
5958.html
– http://blogs.exploratorium.edu/strange-attractor/stairway-to-heaven/
– http://infinitybound.com/index.php/2009/09/08/space-elevator-materials-are-the-
key/
– http://spaceelevatorwiki.com/wiki/index.php/Main_Page
– http://en.wikipedia.org/wiki/File:Challenger_explosion.jpg
– http://www.hanselman.com/blog/HanselminutesPodcast171TheReturnOfUncleBo
b.aspx
– http://www.aeronauticpictures.com/stock-photo/thumbnails.php?album=84
– http://news.nationalpost.com/2011/08/08/photo-gallery-seven-sad-stock-traders/
– The Social Network movie
– http://www.naturalproductivity.com/2011/11/02/defeat-distractions-with-the-
pomodoro-technique/
– http://www.digitaltrends.com/computing/was-dennis-ritchie-more-important-than-
steve-jobs/
– Kill Bill movie