Ördög Rafael - The Clean Coder - bookreview

5,243 views

Published on

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

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,243
On SlideShare
0
From Embeds
0
Number of Embeds
2,571
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Ördög Rafael - The Clean Coder - bookreview

  1. 1. The Clean Coder A Code of Conduct forProfessional Programmers (Robert C. Martin)
  2. 2. Uncle Bob Martin
  3. 3. 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?
  4. 4. 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.
  5. 5. 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!
  6. 6. A konfliktus értéke
  7. 7. 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á!)
  8. 8. 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.
  9. 9. 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.
  10. 10. 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
  11. 11. 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ó.
  12. 12. 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
  13. 13. 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.
  14. 14. Ú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.
  15. 15. 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.
  16. 16. É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.
  17. 17. 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.
  18. 18. 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.
  19. 19. 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ó.
  20. 20. 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.
  21. 21. 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.
  22. 22. 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).
  23. 23. 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.
  24. 24. „The user doesnt know what he wants.”
  25. 25. 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.
  26. 26. 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.
  27. 27. Fitnesse Példagiven the command LogFileDirectoryStartupCommandgiven that the old_inactive_logs directory does not existwhen the command is executedthen the old_inactive_logs directory should existand it should be emptygiven the command LogFileDirectoryStartupCommandgiven that the old_inactive_logs directory existsand that it contains a file named xWhen the command is executedThen the old_inactive_logs directory should still existand it should still contain a file named x
  28. 28. 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!
  29. 29. 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
  30. 30. Teszt piramis
  31. 31. Teszt piramisKözel 100% lefedettségetkínáló, implementációspecifikus tesztek, melyeketa programozók maguknakírnak.
  32. 32. Teszt piramisAcceptance tesztek közülazok, melyek üzleti logikáttesztelnek optimálisfeltételek mellet.Interakcióba csak mockobjectekkel léphet.
  33. 33. Teszt piramisKomponensek közöttikommunikációtteszteli, tipikusan a leadarchitect írja. Néhányperformancia teszt is lehetbenne. Napi 1 futás.
  34. 34. Teszt piramisEgyben teszteli az egészrendszert. Itt is lehetnekperformancia tesztek.
  35. 35. Teszt piramisAz egyetlen manuális tesztcsoport. Teljesen adhoc, ésa lényege épp az, hogyazokat az eseményeketváltsa ki, amikre senki nemszámított. (Bug hunt day.)
  36. 36. 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!
  37. 37. 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.
  38. 38. 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
  39. 39. 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!
  40. 40. 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

×