Clean as you code

I ett tidigare inlägg skrev jag en del om hur vi i teamet jobbar med kvalitet i koden, men då på ett mer övergripande plan med reviews och kodstruktur. Tittar man lite närmre på koden och granskar den under lupp så är det ju minst lika viktigt att kvaliteten finns där med.

Clean as you code

Clean as you code 1280 1920 C.A.G

Det finns egentligen ingen giltig ursäkt för att inte hålla sin kod i bra skick. Det räcker inte bara med att den kompilerar och är buggfri. Bra kod kan bedömas utifrån dess kodstandard, läsbarhet och förändringsbarhet. Mindre bra kod brukar vara svår att läsa, svår att underhålla och i förlängningen också dyr att förvalta. Dessutom inbjuder mindre bra kod till mindre bra lösningar eftersom man inte förstår andemeningen med logiken. Men som tur är finns ju en massa fina verktyg som hjälper oss att hålla ordning på vår kod.

 

IntelliJ

Det vi i teamet tar hjälp av är olika verktyg för code inspection. Ett IDE som t ex IntelliJ har code inspection inbyggt och kan ge en snabb feedback på död kod, eventuella buggar, stavfel mm. Det brukar vara en bra rutin att köra en code inspection innan man committar sin kod. IntelliJ har också en massa bra plugins som kan ses som kryddade varianter av IntelliJ’s egen code inspection.

 

SonarLint

SonarLint är t ex en bra plugin som de flesta i teamet har installerat. Den hjälper oss att hitta potentiella buggar och andra sårbarheter i koden. Man kan säga att SonarLint fungerar som en stavningskontroll som markerar fel i koden så att dessa kan fixas till innan commit. SonarLint är ett bra komplement till code inspection i IntelliJ eftersom vi får en direkt återkoppling samtidigt som vi skriver koden. Ofta ges inte bara en highlight utan även en förklaring till problemet, vilket vi gärna nyttjar för att kunna lära oss mer om problemet. Är man lite om sig och kring sig här kan man bygga upp en bra förståelse genom att läsa på om det som inte var bra och därmed undvika en del fallgropar i framtiden.

 

SonarQube

Men för att få en bild över helheten behöver vi andra verktyg som t ex SonarQube, som är en server för kodanalys. Med SonarQube kan vi skaffa oss en bra överblick över hela kodbasen och visualisera tydliga mätpunkter för teamet. Det jag gillar med SonarQube är att vi även kan visa på kvaliteten i det vi bygger för t ex en ledningsgrupp eller produktägare som inte har möjlighet att värdera kvaliteten i koden på samma sätt som oss utvecklare. Här finns tydlig info om buggar, sårbarheter, code smells, test coverage och duplicerad kod. Sonarqube visualiserar trender över vart koden är på väg vad gäller test coverage och komplexitet, mm. Vi får en bild över den cyklomatiska komplexiteten, som är ett mätvärde för hur många vägar ett anrop kan ta genom koden och i förlängningen vilka testfall vi saknar för en bra coverage. Kognitiv komplexitet är ett annat mätvärde som visualiseras och är ett värde på hur svår koden är att förstå. Alla dessa mätpunkter hjälper oss att se vilket skick koden är i.

För oss i teamet är det viktigt att hela tiden få feedback på hur koden mår och vi har därför ett automatiserat flöde som genererar rapporter vid varje bygge. Rapporterna skickas till vår genensamma SonarQube och på så sätt kan vi visualisera kvaliteten i alla våra mikrotjänster på en central server. SonarQube är ett verktyg som vi samlas kring med jämna mellanrum för stämma av att vi kvalitetsmässigt är där vi vill vara. För teamet är det ett stort värde i att kunna visualisera kvaliteten i det vi bygger.

 

Vägen framåt

Med hjälp av verktygen kan man få en heads-up på tillståndet, jobbet får man göra själv och en bra approach när man utvecklar kod är att hela tiden sträva efter att förfina och förbättra. Det här är självklart för de allra flesta, i alla fall i teorin, men det ser inte alltid ut så i verkligheten. Tidspress, prioriteringar och den mänskliga faktorn gör att dessa viktiga saker hamnar i skymundan för andra uppgifter. En massa stökig legacy-kod kan dessutom utmana de mest heliga principerna om att hela tiden refaktorisera och förbättra. I ett sånt läge kan det vara bra att ha ett gemensamt angreppssätt inom teamet.

 

Ett angreppssätt kan vara att man fokuserar på att all ny kod som produceras ska hålla den standard man kommit överens om. Det är såklart fortfarande ok att fixa till sin legacy-kod, men fokus ska ligga på kod som producerar idag. Genom att också definiera en quality gate som bara gäller ny kod behöver man inte känna frustration för den legacy-kod som inte möter upp till den standard vi satt för ny kod. I takt med att man committar ny kod som passerar sin quality gate kommer kvaliteten på koden gradvis att öka.

 

Tillsammans i teamet har vi hittat vårt sätt att aktivt arbeta med kvaliteten i koden. Vi ser inga ursäkter till att inte hålla vår kod i bra skick och det är riktigt tillfredsställande att faktiskt veta mer om den kod vi tillsammans skapar.

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kontaktperson

Annika Rogneby

+46 70 687 33 08

annika.rogneby@cag.se

X
X