or*dtrosnilt,'+'.q':'

Transkript

1 %,u lbnvaston.*.'. or*dtrosnilt,'+'.q':' JavaBin 5. mai Vidar Alvestad - Skatteetaten

2 Inspirert av: Noen eksempler er hentet fra boken. Jeg tror Mr. Feathers tilgir meg dersom du kjøper boken ;-)

3 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

4 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!

5 Døhh! Det er enklere sagt enn gjort!

6 Beholde egenskaper Å lage programvare handler mest om å beholde systemets egenskaper... Eksisterende egenskaper Nye egenskaper

7 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...

8 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)

9 Men husk: Å skrive enhetstester er ikke alt Å forstå forretningsområdet/domenet er minst like viktig (men ikke fokus for denne presentasjonen)

10 Sensing and separation

11 Late som objekter Mock Objects Fake Objects

12 Verktøy CI (Hudson min favoritt) xunit / TestNG Refactoring tools (Eclipse god støtte) Fit/Fitnesse Canoo, Selenium, Watir, Cucumber m.m

13 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)!

14 Kode- og designforståelse

15 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

16 Lag time

17 Stresset! Må bare fikse det kjapt Husk: Koden er ditt hus. Det er du som må leve med det!

18 Legger til funksjonalitet Vi skal sørge for at ingen av de nye entries allerede er med i transactionbundle

19 En annen mulighet... Ønsketenkningsprinsippet: Jeg kunne ønske det var en metode her som het uniqueentries og som gjorde akkurat det jeg hadde behov for...

20 TDD Lag så metoden (helst ved hjelp av TDD, det skader heller ikke å parprogrammere...)

21 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

22 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

23 Vi skal legge til logge funksjonalitet. Decorator Pattern

24 Store klasser

25 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

26 Seeing responsibilities Group methods Look at hidden methods Look for decisions that can change Look for internal relationships Look for the primary responsibility

27

28

29

30

31

32

33

34

35 Noen tips til slutt Kona mi lager gele nå Programvare = gele? Tester = formen Uten tester blir geleen ustabil Men godt er det...

36 Programming is the art of doing one thing at the time Micheal C. Feathers

37 Ta barnesteg og sjekk inn tidlig og ofte

38 Gladprogrammering!

39

40 Takk for meg! epost: vidar.alvestadsnabelkrøllskatteetaten.no vidar.alvestadkrøllalfagmail.com twitter: vidar_alvestad linkedin

41 Hvilke tester skal jeg skrive? I utgangspunktet skriver vi ikke tester for å finne bugs i koden Vi skriver tester for å bevare egenskapene i systemet