Recommended
Recommended
More Related Content
Similar to Kunskapsbaren 2011 Linköping - Koda om eller koda nytt?
Similar to Kunskapsbaren 2011 Linköping - Koda om eller koda nytt? (20)
Kunskapsbaren 2011 Linköping - Koda om eller koda nytt?
- 1. LINKÖPING 12 MAJ, 2011
- 4. Hur blev det så här? Prototyper som får liv Time to market är viktigt, så vi har ofta bråttom Flyttskadad kod Ibland måste man ta över saker som andra gjort Kod som åldras – sällan med värdighet Om du inte alltid sköter om din kod så blir den dålig 4
- 5. Identifiera dålig kod Vi kan inte fixa allt Se till att fixa det värsta först Var uppmärksam på tecken på dålig kod Höga estimat för att införa ny funktionalitet Leta efter områden med hög komplexitet Lyssna på vad utvecklarna säger om koden Titta på felrapporter 5
- 6. Analys av felrapporter Felrapporter kan användas till mycket mer än att lösa ett specifikt problem Hur många fel har vi? Vad är det för sorts fel vi har? I vilken fas uppstod felet? I vilket område har vi felen? Att försöka hålla en övergripande koll på alla felrapporter är nyttigt 6
- 7. Miljö Utan fungerande verktyg kan ingen jobba Börja med att se till att förutsättningarna finns Byggmiljö Varje bygge måste lyckas Byggtiderna måste vara korta Versionshanteringssystem Analysverktyg Felrapportering Tänk på både intern och extern användning 7
- 8. Att lära sig produkten Det är OK att läsa kod Funktionstester säger ofta mer om produkten än designdokumentation Ibland är det svårt att identifiera rätt väg framåt Gör prototyper för att lära sig mer Dela upp produkten i bitar och håll en seminareserie Kan kombineras med ett modulansvar 8
- 9. Kodgranskningar Kodgranskning kan ske på flera nivåer Parprogrammering Kompisgranskning Expertgruppsgranskning I en produkt full av dåliga exempel är ett viktigt syfte att styra kulturen Se till att bra exempel sprids 9
- 10. Skriva om eller rätta till? I början är det lätt att vilja skriva om all dålig kod Om man inte förstår koden, hur kan man skriva om den? Hitta områden med stora skillnader i komplexitet mellan problemet och lösningen 10000 rader för att flytta filer mellan två datorer Se till att du inte tappar någon funktionalitet Om koden är dålig så är säkert testerna dåliga 10
- 11. Funktionstester Bra funktionstester är utmärkt stöd vid omimplementering Automatisera funktionstesterna Regressionstester kan snabbt hitta problem Se till att du testar rätt saker Använd rätt villkor för pass/fail 11
- 12. Unittester Unittesta gammal kod är sällan vettigt Detta får inte spilla över till ny kod Bra designade unittester hjälper till vid refactoring Det är dock lätt att göra fel 12
- 13. Förändra gammal eller ärvd kod (eng. Legacy) Leta efter förändringsställen Hitta testpunkter Bryt isär beroenden Skriv tester Förändra 13
- 14. Vägen framåt...
- 15. Kultur Hålla motivationen uppe Jobba för små segrar Bryta dåliga designmönster En organisation med god smak Scoutregeln Lämna alltid koden lite bättre än när du fick den 15
- 16. Mod, tillit, förtroende och ansvar Mod hos organisationen Tillit från kunden och användaren Förtroende för individen Ansvar hos utvecklaren 16
- 17. Litteraturtips Working Effectively with Legacy CodeMichael C. FeathersPrentice Hall 2005, ISBN 0-13-117705-2 Kod, merkodoch lite till… 17
- 18. Thank you!
Editor's Notes
- En annan undertitel skulle kunna var ”En existentiell diskussion om livet efter arvet”Hej och välkomna till detta seminarie om gammal kod.Svaret på frågan är Ja, kanske mer åt Nja eller egentligen NjäeKanske är det så att det inte finns något entydigt svar inte någon fördefinierad sanning.Vi hoppas att ni alla här skall få några tankar med er, vara lite klokare, ha några verktyg med er för att kunna avgöra när vilket är det rätta för er.Vi som håller i seminariet är,< Presentation >
- Analys: Var är vi, vad är viktigt, vad skall vi göra förstMedel: Verktyg, Miljö, Felrapporter, Tester, DokumentationMål: Gör en förändring, inför den nya funktionaliteten
- MickeTTM viktigt. Man vet inte vad som kommer att lyckas. Alltså blir v1.0 oftast en prototyp. När den lyckas rampar man upp med folk och ska försöka få produkten att leva.
- MickeTar lång tid att rätta felHöga estimat för nya featuresDet känns som en bestraffning att jobba i den.Många rader kod per fil/objektMånga rader kod per funktion/metodHög cyklomatisk komplexitet, se verktygsslideMycket felrapporter -> Nästa slide
- MickeOm man håller bra koll på sina felrapporter kan man lära sig mycket om produkten. Titta inte bara på antalet utan också vilken typ av felrapporter som dyker upp. Har vi mycket logiska fel -> vi testar för liteHar vi felrapporter angående användning -> vi förstår inte hur produkten används
- MattiasFörsta steget är nästan alltid att se till att byggmiljö, versionshantering och felrapportering fungerar. Utan det kommer man ingenstans.Se till att miljö, versionshanteringssystem och felrapportering blir ett stöd för verksamheten, inte ett hinder.
- MattiasOm man håller bra koll på sina felrapporter kan man lära sig mycket om produkten. Titta inte bara på antalet utan också vilken typ av felrapporter som dyker upp. Har vi mycket logiska fel -> vi testar för liteHar vi felrapporter angående användning -> vi förstår inte hur produkten används
- MickeLilla kodgranskinging gruppen kan man använda när man vill hålla koll på ett distribuerat utvecklingsteam att alla kodar likartat och att designen inte går sönder över tid.Alla-skall-med-principen, här deltar alla i grupper om att kodgranska, utmärkt sätt för att sprida hur god kod skall se ut. Att dela med sig av sätt att göra olika saker på.Leder ofta till högre delning av funktionalitet mellan delar av systemet.
- MickeGammal kod innehåller rättningar för saker som vi inte förstod från början.Dessa rättningar är sällan med i designdokument och är lätta att missa att flytta med när man gör nytt.
- MickeFunktionstester är black-box tester på en hel ”funktion”, ”modul”, ”delsystem”Automatiska förståsBra unittester är bättre
- MattiasUnittester innehåller assertsUnittester testar bara det externa gränssnittet på en klass, en c-fil...Unittester är singel-trådadeUnittester är snabbaUnittester har bra beskrivande namn. Med bra beskrivande namn så kan man läsa unittesterna som en saga om koden. En sedelärande sagaÄr isolerat, unittester spiller inte state mellan varandra.Skriver eller läser inte i filsystem, databaser eller på nätverketAtt unittesta gammal kod är sällan vettigt, men hur ser man till att dessa tankar inte spiller över på ny kod?
- MattiasAtt jobba med gammal kod, skulle kunna ske i följande lunk.FörändringsställenVet du var och hur?Gå vidareJag känner inte min kod bra nog för att ändra något -- att sätta sig ned och verkligen gå igenom kod känns av någon anledning inte som riktigt jobb.KodgranskningGör en liten designskissGör en upprensning i koden, bryt ut metoder, fixa indentering, behövs nya klasser, funktioner, metoder fixa det -- det finns versionshanterings-system när det är dags att backaSCRATCH REFACTORINGTa bort kod som inte används, återigen, det finns versionshantering om du behöver koden igenTestpunkterDet kan vara lätt, men förmodligen inte. Kod som är skriven utan unittester är allt som oftast svår att testa.SensingHitta sidoeffekterPrototypingBeroendenDenna del är väldigt beroende av valt språk och vilka verktyg som finns tillhands. Dynamiskt typade språk är ofta lättare. Java och eclipse - änvänd mockramverk.C++interface kan vara ett steg på vägen, Ingen kod i h-filer om du inte måste, stubbar, mocks för externa bibliotekCSkriv stubbar eller mocks av externa lib, byt ut symboler i objektfilerTesterSkriv tester, runt det som du vill förändra, för att testa och låsa in det nuvarande EXTERNA, observerbara beteendet.Skriv tester för det nya beteendetFörändraGrattis, du är nu klar att med tillförsikt göra förändringen
- Analys: Var är vi, vad är viktigt, vad skall vi göra förstMedel: Verktyg, Miljö, Felrapporter, Tester, DokumentationMål: Gör en förändring, inför den nya funktionaliteten
- M & MScoutregeln - Lämna koden lite bättre än när du fick denAtt allt är skit får inte bli en ursäkt för att inte göra den lite bättre.Ursäkter som "Det går inte att rätta upp allt så vi lämnar det som det är" får inte bli accepterat.Att jobba i ett hav av skit är inte kul. Hur motiverar man folk? Prata om det, men det är mycket viktigt att inte hamna i "allt är skit".När man inte förstår koden är det lätt att bara kopiera något existerande och ändra lite.För att förstå vad som är bra och dålig kod måste man läsa en massa kod. Det är viktigt att folk usätts för massvis med exempel på kod.
- M & MUnittester innehåller assertsUnittester testar bara det externa gränssnittet på en klass, en c-fil...Unittester är singel-trådadeUnittester är snabbaUnittester har bra beskrivande namn. Med bra beskrivande namn så kan man läsa unittesterna som en saga om koden. En sedelärande sagaÄr isolerat, unittester spiller inte state mellan varandra.Skriver eller läser inte i filsystem, databaser eller på nätverketAtt unittesta gammal kod är sällan vettigt, men hur ser man till att dessa tankar inte spiller över på ny kod?