%,u lbnvaston.*.'. or*dtrosnilt,'+'.q':' JavaBin 5. mai Vidar Alvestad - Skatteetaten
Inspirert av: Noen eksempler er hentet fra boken. Jeg tror Mr. Feathers tilgir meg dersom du kjøper boken ;-)
Hva er lecacy code? Kode uten automatiserte enhetstester = dårlig kode Det spiller ingen rolle hvor godt koden er skrevet Uten testene aner vi ikke om koden blir dårligere eller bedre når vi endrer den Med tester kan vi endre på koden med trygghet
Vi må kunne endre koden med større trygghet! Vi må sammen lage automatiserte enhetstester som gir oss øyeblikkelig tilbakemelding. På denne måten skal vi sammen endre systemet til det bedre!
Døhh! Det er enklere sagt enn gjort!
Beholde egenskaper Å lage programvare handler mest om å beholde systemets egenskaper... Eksisterende egenskaper Nye egenskaper
Edit & Pray Bruk lang tid med å studere koden. Bruk hjernen som en run-time Når du er sikker (ganske sikker) på at du forstår koden: Gjør endringene. Men sørg for at disse er minimale. Du vil vel ikke ødelegge noe? Start systemet og trykk rundt omkring for å se om noe feiler Håp og be om at det gikk bra...
Alternativ: Cover & Modify Identifiser de stedene i koden du ønsker å endre Finn steder i koden som må testes Bryt opp avhengigheter Skriv testene Gjør endringene og sørg for at design og kode blir bedre (refactor)
Men husk: Å skrive enhetstester er ikke alt Å forstå forretningsområdet/domenet er minst like viktig (men ikke fokus for denne presentasjonen)
Sensing and separation
Late som objekter Mock Objects Fake Objects
Verktøy CI (Hudson min favoritt) xunit / TestNG Refactoring tools (Eclipse god støtte) Fit/Fitnesse Canoo, Selenium, Watir, Cucumber m.m http://www.opensourcetesting.org
Jeg forstår ikke koden... Whiteboard med domenemodell Kodegjennomgang i team: Ta utskrift av koden og heng den opp Marker feks ansvarsområder og kode som kan flyttes Effekt skisser Scratch refactoring Slett kode (og unødvendige kommentarer)!
Kode- og designforståelse
Det tar en evighet å endre koden! I et godt vedlikeholdt system: Tar KANSKJE tid å finne ut hvor endringen bør legges inn Endringen er ENKEL å gjennomføre I et dårlig vedlikeholdt system: Tar ALLTID tid å finne ut hvor endringen bør legges inn Endringen er VANSKELIG å gjennomføre
Lag time
Stresset! Må bare fikse det kjapt Husk: Koden er ditt hus. Det er du som må leve med det!
Legger til funksjonalitet Vi skal sørge for at ingen av de nye entries allerede er med i transactionbundle
En annen mulighet... Ønsketenkningsprinsippet: Jeg kunne ønske det var en metode her som het uniqueentries og som gjorde akkurat det jeg hadde behov for...
TDD Lag så metoden (helst ved hjelp av TDD, det skader heller ikke å parprogrammere...)
Sprout method Sprout class Det foregående eksempelet er det som kalles for sprout method (sprout = spire) Man lar en metode eller klasse spire på siden av eksisterende kode Blander ikke eksisterende og ny kode Enkel teknikk, men lar seg bare gjennomføre dersom funksjonaliteten skal enkelt utvides
Temporal coupling Gruppere ting sammen bare fordi de tilfeldigvis hender på samme tid skaper unødvendige koplinger Det er forbausende hvor ofte dette gjøres spesielt i en forvaltningssituasjon
Vi skal legge til logge funksjonalitet. Decorator Pattern
Store klasser
The Single- Responsibility Principle Every class should have a single responsibility It should have a single purpose in the system There should be only one reason to change it
Seeing responsibilities Group methods Look at hidden methods Look for decisions that can change Look for internal relationships Look for the primary responsibility
Noen tips til slutt Kona mi lager gele nå Programvare = gele? Tester = formen Uten tester blir geleen ustabil Men godt er det...
Programming is the art of doing one thing at the time Micheal C. Feathers
Ta barnesteg og sjekk inn tidlig og ofte
Gladprogrammering!
http://manifesto.softwarecraftsmanship.org/
Takk for meg! epost: vidar.alvestadsnabelkrøllskatteetaten.no vidar.alvestadkrøllalfagmail.com twitter: vidar_alvestad linkedin
Hvilke tester skal jeg skrive? I utgangspunktet skriver vi ikke tester for å finne bugs i koden Vi skriver tester for å bevare egenskapene i systemet