...
Væsentlige/forretningskritiske dele af koden skal testes med unittests. Det forventes ikke at testdækningen bliver 100%. Som et koncervativt konservativt mål sigtes efter 60% testdækning.
...
Webservices udvikles efter følgende "best practice" for webservices:
...
SIG kører ugentligt en statisk kodeanalyse på udvalgte kodespor for hver applikation, analysen består af 8 meget basale optællinger i koden.
STAR, Udviklere og Projektledere får en adgang til dette værktøj ved onboarding.
Målet er at ny kode skrives til en score på 4,0 points, og at gammel kode løftes til score på 3,5 points.
SIG tæller ud fra følgende opdeling af koden:
Se opdateret dokumentation her:
https://www.softwareimprovementgroup.com/methodologies/iso-iec-25010-2011-standard/
Program - Følger med stor sandsynlighed den opdeling i forretningsapplikationer/systemer som vi allerede kender: STAR applikationer og systemer, men der kan forekomme afvigelser for applikationer der f.eks. har en frontend og en backend som er fælles for flere applikationer.
Component - Dette kan være .NET assemblies, men kan og blot være væsentlige namespaces, eller fysisk opdeling af koden i foldere.
Module - C# klasse, Javascript fil eller tilsvarende
Unit - C# metode (funktion/operation) i en klasse, eller Javascript metoder (funktioner)
Følgende otte optællinger foretages, med angivelse af hvad der skal være opfyldt for at få 4 stjerner (svarende til 3.5 - 4.5 points)
Code size - Programmer skal holdes små, målet er at et C# program højest er 160.000 linjer fraregnet duplikeret kode, testkode og kommentarer.
Duplication - Duplikeret kode skal undgås, der er tale om duplikeret kode hvis de samme 6 linjer kode er gentaget mere end et sted.
Højst 4,6% af koden er duplikeret
Unit size - Antal kodelinjer i en metode. Her er kortere bedre, anbefalingen er 30 linjer, målet er højst 60 linjer pr. metode:
mindst 56,3% af koden ligger i metoder med højst 15 linjer i hver - (altså højest 43,7% af kode ligger i metoder med mere end 15 linjer)
mindst 77,7% af koden ligger i metoder med højst 30 linjer i hver - (altså højest 22,3% af kode ligger i metoder med mere end 30 linjer)
mindst 93,1% af koden ligger i metoder med højst 60 linjer i hver - (altså højest 6,9% af kode ligger i metoder med mere end 60 linjer)
Unit complexity - målt som McCabe cyclomatic complexity - anbefalingen er en kompleksitet på 5, målet er højst 10 (dvs. 10 valgpunkter/forgreninger i hver metode).
mindst 74,8% af koden ligger i meter med kompleksitet på højest 5 - (altså højest 25.2% af kode ligger i metoder med kompleksitet over 5)
højest 10% af koden ligger i metoder med kompleksitet over 10
højest 1,5% af koden ligger i metoder med kompleksitet over 25
Unit interfacing - her tælles antallet af parametre en metoder tager - anbefalingen er 2 parametre, målet er højst 5 parametre for en metode
mindst 86,2% af koden ligger i metoder med højest 2 parametre - (altså højest 13,8% af koden ligger i metoder med 3 eller flere parametre)
højest 2,7% af koden ligger i metoder med 5 eller flere parametre
højest 0,7% af koden ligger i metoder med 7 eller flere parametre
Module coupling - målt som antallet af indkomne afhængigheder til en klasse - anbefalingen er 10 aftagere/kaldere, nogle utility-klasser vil have mange flere
mindst 78,4% af koden ligger i klasser med højst 10 aftagere/kaldere - (altså højst 21,6% af koden ligger i klasser med mere end 10 aftagere/kaldere)
højest 13,8% af koden ligger i klasser med mere end 25 aftagere/kaldere
højest 6,6% af koden ligger i klasser med mere end 50 aftagere/kaldere
Component balance - et program skal erfaringsmæssigt helst være delt i 9 lige store komponenter
Her måles på afvigelsen fra det optimale, både hvad angår antal komponenter og ligefordeling af antal kodelinjer i komponenterne
Component independence - antallet af klasser i en komponent som refereres fra en anden komponent skal holdes lavt, skriv tynde veldefinerede interfaces
højst 13,2% af koden må ligge i klasser der aftages/refereres fra en anden komponent end klassen egen
Component entanglement
Mandemåned og kodelinjer
...
Centralt build og deployment
...
Den vedhæftede PowerPoint præsentation er materialet, som blev gennemgået ved det faglige indlæg torsdag den 30. august 2018 omkring kodekvalitet. Præsentationen indeholder lidt information om, hvorfor man bør kigge på kodekvalitet samt eksempler på de tiltag, som er taget på DFDG.