Hur arbetar vi med kvalitet i koden?

Den senaste tiden har jag funderat lite över hur man ser till att en kodbas bibehåller sin kvalitet under projektets gång. Att vi fortfarande efter månaders slit och en massa nya kodrader ser struktur och stringens i det som byggts. Att inte behöva upptäcka att det skapats ett nytt trassel... när det kanske var ett gammalt trassel vi ville bort ifrån. Jag diskuterade detta med en kollega och det mynnade ut i detta blogginlägg – om hur vi i teamet jobbar med dessa frågeställningar.

Hur arbetar vi med kvalitet i koden?

Hur arbetar vi med kvalitet i koden? 2560 1441 C.A.G

Code review
När vi omsätter funktionella krav till fungerande kod börjar vi alltid med att bryta ner kraven i mindre delar. Först därefter kan varje utvecklare koda sin uppgift, eller sin jira om det är verktyget som används. Vi utvecklar alltid ny funktionalitet i egna utvecklingsbrancher och innan vi pushar koden till masterbranchen har vi en code review.

En code review för oss innebär att vi gör en första ‘sanity check’ av koden. Vi tittar övergripande på strukturen, att alla förstår koden och att den inte är för komplex. Vi vill snabbt identifiera kod som vi av någon anledning inte är överens om. Det kan vara allt ifrån rena tankevurpor till att vi fallit in i en java-6-style nu när vi äntligen lyft till Java 11. Vi kollar såklart också att vi har en bra testtäckning med mera.

En code review är för oss inte fråga om att testa koden. Det är en kontroll av att vi inte har hittat på något tokigt och att koden jackar in i den befintliga kodbasen. Code reviews är ett utmärkt sätt att kvalitetssäkra det man pushar in i repot. Vad kvalitetssäkring betyder är såklart bra att komma överens om innan man startar sina code reviews.

Men trots återkommande code reviews händer det ändå att koden drar iväg åt något otäckt håll. Det händer i de flesta projekt om man inte är uppmärksam. Därför har vi schemalagt lite mer omfattande code reviews där hela teamet sitter ner och funderar i lite större strukturer.

 

Team code review
En större code review lägger vi in vid jämna tillfällen då vi utmanar hela vår kodbas. Vi brukar sitta ner hela teamet under ett par timmar och försöker då ta ett steg tillbaka för att kunna se koden i nya perspektiv. Vid dessa tillfällen brukar det, trots code review vid varje push, dyka upp en del klassiska synder såsom allt för stora klasser, komplex logik eller kod som behöver refaktoriseras på något sätt. Kanske behöver vi ändra vår paketstruktur då nya förutsättningar uppstått längs vägen, kanske har vi idag en annan kunskap om det vi bygger som gör att vi behöver omvärdera sättet vi valt att implementera koden på.

En bra övning kan vara att skissa upp ett sekvensdiagram över specifika delar i koden, eller på annat sätt visualisera koden. Om det verkar knepigt kan det vara ett tecken på att något behöver göras.  Man kan även försöka hitta den där röda tråden som ska löpa genom krav-implementation-dokumentation. Finns den inte funderar vi över varför och försöker rätta till det. Att tänka i former av use case som t ex att en utvecklare ska lägga till funktionaliteten x – kan vi på ett enkelt och förståeligt sätt göra det? Upptäcker vi något som skaver så skapar vi jiror som vi lägger i vår backlog. Dessa planerar vi sedan in i våra sprintar.

 

Vad vi vinner med code review
Med återkommande code reviews är vår ambition att hålla koden i bra skick. Vi strävar efter att vara kritiska på ett konstruktivt sätt. Vi funderar i banor som hur vi kan förbättra, förfina och underlätta för framtida förändringar i koden. Vi är medvetna om att det tar tid i anspråk att refaktorisera när vi kanske hellre lägger till ny funktionalitet, men i långa loppet vet vi att det lönar sig. Att diskutera, fundera och implementera gemensamma lösningar sprider inte bara kunskap i teamet utan koden blir också stabilare, bättre och mer hanterlig för de som i slutändan ska använda den. Jag tänker då inte bara på slutanvändaren, som kanske bara rör sig i webbgränssnittet, utan även på drift, förvaltning (kanske vi själva) och andra utvecklare som kommer och går i teamet. Att tänka i banor som att vi skriver koden för någon annan får i alla fall mig att tänka till en extra gång innan jag är klar.

Skynda gärna framåt, men glöm inte att förvalta det du bygger… och när börjar egentligen förvaltningen?

 

Vid pennan/Stefan Nildén Fullstackutvecklare C.A.G Contactor

Kontaktperson

Annika Rogneby

+46 70 687 33 08

annika.rogneby@cag.se

    X
    X