Tema: Test First Positivist: Det som ikke kan måles, eksisterer ikke! Reduserer sjanser for defekter! Gir en oppdatert ”TODO-liste” Gir trygghet til å.

Presentasjon om: "Tema: Test First Positivist: Det som ikke kan måles, eksisterer ikke! Reduserer sjanser for defekter! Gir en oppdatert ”TODO-liste” Gir trygghet til å."— Utskrift av presentasjonen:

1 Tema: Test First Positivist: Det som ikke kan måles, eksisterer ikke! Reduserer sjanser for defekter! Gir en oppdatert ”TODO-liste” Gir trygghet til å gjøre senere endringer Tvinger fram et lavere koblet design  Forbedrer designet rett ut fra startgropen Gir ”Just-in-Time” Analyse

2 Tema: Tester De beste testene tester enheter Dersom testene ikke har fanger nok feil: Oppnevn en prosjekt-sabotør (test testene) Dersom feil oppstår i integrasjon Kartlegg hvilken enhet som oppfører seg feil Introduser tester som verifiserer mot dette For å teste at en klasse kaller de riktige metodene på en annen: Bruk ”Mock objects” for å teste rekkefølgen på kallene

3 Tema: Spikes Hva gjør man dersom man skal estimere hvor lang tid det vil ta å lage et hull i isen? Slår en tynn stake gjennom den Spike er et lite program som lages for å teste noe og som så kastes Typer: Performance Spike (gjør 20000 kall mot webserveren) Arkitektur Spike Estimerings-spike (for å vite mer om hvor lang tid noe kommer til å ta)

4 XP & Design XP gjør ikke en stor designjobb på forhånd XP fokuserer på Enkelhet Betyr dette at XP er ”imot design”? NEI!: Istedet designer vi når vi vet hva vi skal designe Et enkelt program betyr det dette er mulig Grundig testing betyr vi vet når vi ødelegger noe Et design som ikke er uttrykket i kode eksisterer ikke!

5 Tema: Refactoring Programmet skal: Passere alle tester Si alt som må sies Ikke gjenta seg selv Ha færrest mulig klasser og metoder Understøttes av enhetstestene Angriper ”code-smells” (Ender ofte opp på Patterns)

6 Eksempel: Før public void mouseDragged(MouseEvent e) { if (m_resizeComponent.getWidth() + e.getX() >= MIN_WIDTH) m_resizeComponent.setBounds(m_resizeComponent.getX(), m_resizeComponent.getY(), m_resizeComponent.getWidth() + e.getX(), m_resizeComponent.getHeight()); else m_resizeComponent.setBounds(m_resizeComponent.getX(), m_resizeComponent.getY(), MIN_WIDTH, m_resizeComponent.getHeight()); m_resizeComponent.validate(); }

7 Refactoring - Etter protected void adjustWest(Rectangle rect, MouseEvent e) { int newWidth = Math.max(rect.width–e.getX(), MIN_WIDTH); int deltaX = newWidth – rect.width; rect.x -= deltaX; rect.width += deltaX; } public void mouseDragged(MouseEvent e) { Rectangle rect = m_resizeFrame.getBounds(); adjustWest(rect, e); m_resizeFrame.setBounds(rect); m_resizeFrame.validate(); }

8 Tema: Planlegging User Stories gir en uformell beskrivelse Samtale med kunden gir mer utfyllende info Akseptanse-tester verifiserer forståelsen Dette er primær tilbakemelding til kunden Forrige iterasjoner gir Project Velocity (Starter på 1 User Story enheter/3 person- uke) Engineering Tasks gir uformelle TODO Daglige Stand-up møter viser status Et prosjektmedlem bør være ”Tracker”

9 Tema: XP og CMM CMM er ikke en prosess, men et prosess- forbedrings rammeverk XP fokuserer på mange av de samme tingene som CMM: Kvalitetsikring, metoder, måling, forbedring XP passer relativt bra inn i CMM rammeverket For mer info – se http://www.xprogramming.com/xpmag/xp_and_cmm.htm http://www.xprogramming.com/xpmag/xp_and_cmm.htm

10 Tema: XP og CMM, level 3-5 SEI Level Three – Defined XP Passer som hånd i hanske 12 extreme practices User Stories + Tester SEI Level Four – Managed Flere kvantitive målinger og mål kan trenges SEI Level Five – Optimizing Når defekter oppstår, skriver man tester for å demonstrere dem

11 Cost of Anticipatory Design Invested Cost and Design Complexity Time ’A’ needed’B’ needed Cost of A Cost of B

12 Tema: Parvis Programmering To programmere sitter ved samme maskin Den med tastaturet tenker kortsiktig (sjåfør), den andre tenker langsiktig og gir konstant review (kartleser) Rollene byttes ofte Parene rokeres ofte (oftere enn daglig)