Mer om kodkvalitet. Mer om kodkvalitet. Hur kan man jobba med kodkvalité? Hur kan man jobba med kodkvalité? Hur kan man jobba med kodkvalité?

Transkript

1 Mer om kodkvalitet Hur kan man jobba med kodkvalité 1. Jobba strukturerat genom hela processen Skulle ni köpa/köra en bil som inte har besiktas de senaste åren, speciellt efter lagningen efter krocken Skulle köpa ett hus som är byggt och ombyggt utan ritningar Hur kan man jobba med kodkvalité Fokusera på kvalité och inte kvantitet Bygg det viktigaste först Jobba tillsammans Gemensamt ansvar en för alla alla för en Kontinuerlig uppföljning av processen Kod-granskning Lätt att läsa, lätt att testa, förklara Koden följer grundläggande kodprinciper Koden, systemet är inte onödig svårt att förstå Involvera testning i ett tidigt skede av processen Hur kan man jobba med kodkvalité Tydlighet i förväntningar Tydliga krav vad som ska systemet ska kunna göra Tydliga definitioner när en funktion/del fungerar som den ska både i det lilla och i det stora Tydliga definitioner på när det inte fungerar (undantag, fel, etc) Bra design System/klassdesign/metoddesign Systemarkitektur, klasser, metoder, etc Dokumenterad testning på många nivåer Enhets, integrering, system, acceptans-test Hur ska man följa upp/garantera att koden fungerar även efter flera generationer Mer om det senare Utvecklingprocess Mer om kodkvalitet Kodning Granskning Acceptans Leverans Dokumentation Hantera fel, & felsökning Versionshantering 347

2 Mer om kodkvalitet Bra klasser Bra metoder Testat Typsäkerhet Men det finns mer Dokumentation Att jobba med dåligt kommenterar kod är som att leka viskningsleken Har vi råd att inte dokumentera När man inser att det sitter 5000 andra i Indien och jobbar med den kod jag bygger vidare på Dokumentera program Ett program används sällan endast av den som utvecklat den Användaren behöver få veta hur programmet fungerar Ett program underhålls inte alltid av den som skrivit det Den som ska underhålla programmet behöver info Ett program utvecklas ofta av många personer De andra i utvecklingstemet behöver info Vad kan behöva dokumenteras Exempel på delar som bör ingå: Användarhandledning GUI API:er Systembeskrivning Hur sitter systemet ihop Hur flödar datat, kontrollen, mm Algoritmbeskrivning Lösningens begränsning Testkörningar Källkod Olika delar vänder sig till olika läsare Kod-dokumentation Bör också se prydlig ut då det är den mest detaljerade formen av dokumentation. Dokumentation i form av kommentarer behövs i koden Kommentarer räcker dock inte (rätt jobbigt att alltid behöva läsa källkod) Lösning på en del av problematiken att man vill ha två olika typer av dokumentation som till stor del innehåller samma info: Javadoc Javadoc Speciella kommentarer som kan användas för att generera dokumentation av koden man har skrivit Eclipse har möjlighet att generera denna dokumentation /** startar en javadoc kommentar Måste skrivas innan en klass, attribut, konstruktor eller metod deklaration Första raden skall vara en kort förklaring av vad metoden gör Efter den första raden som börjar så slutar den allmänna beskrivningen av metoden

3 Javadoc (endast klasser och (endast klasser och (endast metoder och (endast sedan @serial eller API beskrivningen på nätet är uppbyggd med hjälp av javadoc För mer info se: javadoc/ 355 Källkod/Indentering Hur man formaterar sin kod Flytta alltid in all kod som står ett block 3-4 tecken Detsamma för enkel sats som hör till t.ex. if- whileoch for- satser Tänk på att inte skriva för långa rader Om du måste bryta upp ett uttryck/sats p.g.a. att raden skulle ha blivit för lång så flytta in resten av uttrycket minst till positionen för starten av uttrycket/satsen Mer info se: Användarhandledning Hur används programmet. Viktigt för användare av programmet Hur ska man gå till väga för att kompilera din källkod. Viktigt för andra utvecklare. Större program är ofta inte helt triviala att bygga och ska ngn annan kunna göra det så behöver det dokumenteras. API Typ av API, anrop, svarskoder, parametrar, 357 begränsningar, exempel, mm. Systembeskrivning Ska beskriva systemets interna uppbyggnad och struktur. Beskriv varje klass och syftet med denna och dess del av helheten. För att beskriva klassen behöver man också beskriva tex de metoder som finns i den. Här kan det gå bra att använda sig av javadoc för att automatgenerera delar av beskrivningen (klistra inte in dessa i rapporten utan hänvisa istället till vart man kan hitta dessa). Beskriv relationer mellan klasser, med figurer och kommentarer till dessa (här passar ett eller flera 358 UML-diagram). Algoritmbeskrivning Om du har använt några icke självklara algoritmer, t.ex. en sorteringsalgoritm, en sökalgoritm eller något annat, ska du beskriva den/dem. Tex i form av pseudokod. Försök undvika att använda element som är direkt kopplade till koden, t ex variabelnamn och dylikt. Syftet med detta avsnitt är att en läsare ska kunna få förståelse för hur en komplicerad del löses utan att behöva lusläsa kod och utifrån denna inse vad som händer. Lösningens begränsningar Beskriver alla begränsningar som du kan komma att tänka på, eller har stött på under testningen. Du bör tala om alla de begränsningar som strider mot specifikationen. Nästan alla lösningar innehåller någon begränsning, tänk till lite bara. Hur kan/kunde begränsningarna undvikas

4 Hur programmet är testat. Beskriv hur programmet är testat utifrån Vad det ska klara av Definition of Done Vad kan tänkas vara svårt för programmet Testfall. Kommentera testfallen. Varför valde du detta testfall Blev resultatet som det var meningen att det skulle bli Tänk på att tester kan göras på olika delar separat och på det färdiga programmet. Enhetstester, integrationstest, systemtest GUI-tester Prestandatester Varför Vad Hur När Varför Visa att systemet gör det ska göra Vad Visa att systemet kan hantera abnorma situationer Garantera att det systemet uppträder som det ska även efter förändringar av koden Med tester ska fel hittas och inte undvikas Allt som man har inte har råd att inte testa Fel kan innebära höra kostnader och katastrofer» Även en pyspunka kan få katastrofala följder Design, processer, koden, migreringar, integreringar, 363 När Hur Så tidigt som möjligt Designen ska testas (CRC, Mock-up:er, ) Koden som precis har skrivits ska det finnas tester för Samt så sent som möjligt Innan man levererar koden Ska inte gå att leverera kod som inte uppfyller baskraven för testning Olika kritiskt beroende på närheten till produktion Även om det är allas ansvar att koden fungerar så måste varje medlem i teamet ta sitt ansvar för sin kod. Även om man har speciella testare/testavdelningar så måste varje medlem i teamet ta sitt ansvar för sin kod. Automatiska Manuella Regressionstest ANALYS SYSTEM DESIGN PROGRAM DESIGN V modellen Validera kraven Verifiera designen KODNING SYSTEMTEST ENHETS- & INTE- GRATIONSTEST DRIFT & UNDERHÅLL ACCEPTANS- TEST 365 Att konstruera tester Oavsett nivå på det som ska testas Kontrakt på modulen (villkor för leverans ) Definition of Done Vilka typer av giltiga indata finns det för den modulen Vilka giltiga utdata är det från de olika typerna av indata Vilka konstigheter kan uppstå Vilka påverkas systemet av modulen som testas Vilka delar av systemet påverkar modulen som ska testas Hur ser gränssnittet ut på det som ska testas På vilka sätt kan man påverka modulen som ska testas På vilka sätt kan man läsa av tillståndet på modulen som ska testas. Jobba strukturerat med testerna Ha en modell för (varför, vad, hur, när, ) Dokumentera 366

5 Att testa Koden som ska testas och testdesign måste ske isolerat så man inte skriver tester utifrån koden, utan kod som uppfyller testerna Konstruera tester och testfallen innan man skriver koden Tester måste konstrueras för extremer, svagheter och gränsfall, men också för normaliteten Mer om testning Test-Driven-Development JUnit När$det$inte$går$bra$ Unit testing för java Används för att testa att metoder/klasser beter sig som det var tänkt Många IDE:er tex Eclipse har inbyggt stöd för detta. Typsäkerhet Jan Erik Moström Bugg-fixar I produktion, måste gradera skadan Katastrof (Hot-fix) Kritisk (ASAP) Mindre kritisk (Nästa release) Okritisk (När det finns utrymme eller den har varit med för länge) I utvecklingen - vilken kvalitet ska/vill man ha Dokumentera kända begränsningar, fel Versionhantering är en viktig nyckel för hantera 371 buggar Debugger Verktyg för att hitta fel i program Tillåter att man stegar igenom program (sats för sats) och undersöker värden som variabler i programmet har Breakpoint Plats i koden där programmet ska stanna upp 372

6 Grundläggande termer Grunderna i Versionshantering Hålla koll på olika version, kunna gå tillbaka, etc. Repo/Repository - förvaring/administrering av förändringar Centraliserad/Decentraliserad Lokal repo/ remote -repo Revisioner - namnge/tagga Trunk/Master-spår Branch -gren/spår clone, commit, revert, rebase, merge, pull, cherry-pick, stash Merge-konflikter som måste hanteras Commits namnges med SHA-hash Några olika system Det finns mängder av programvaror GIT Mercurial CVS SVN (Subversion). Senare programvara. Åtgärdar några av problemen som finns i CVS Dom flesta kör man i grunden i terminal-fönster Det finns även en mängd Program/web-tjänster som lägger på ett grafisk gränssnitt BitBucket, SourceTree, etc Det finns plug-ins/utökningar till många IDE:er för de vanligaste versionshanteringssystemen Eclips+Git, Eclipse+SVN, IntelliJ+Git, IntelliJ+ Mercurial, Origin Local #1 Local #3 Local #

7 Arbetsflöden Några grundläggande arbetsflöden Loggning av förändringar Backa till en tidigare version och fortsätta på den Jobba samtidigt med olika features Hantera olika versioner av samma system Jobba med de grundläggande arbetsflöden tillsammans med andra Logga och delge förändringar Kräver att man kan synkronisera vad olika 380 användare förändrar, mm Don t panic! GitFlow