De fleste ingeniørteams har to separate samtaler om den samme kodebase. Den ene handler om sikkerhed: er der en risiko for SQL-injektion, en hardcodet hemmelighed, en udnyttelig afhængighed? Den anden handler om vedligeholdelse: er denne funktion for kompleks, er denne kode duplikeret tre gange, er der død kode, som ingen tør slette.
Disse samtaler foregår normalt i forskellige værktøjer, der drives af forskellige teams og efter forskellige tidsplaner. En sikkerhedsscanner markerer, hvad der kan udnyttes. Et separat kvalitetsværktøj, der ofte købes og administreres uafhængigt, markerer, hvad der er dyrt at vedligeholde. To licenser, to dashboards, to parsere, der går i det samme abstrakte syntakstræ for at besvare to forskellige spørgsmål.
Den opdeling har en pris. Pålidelighedsfejl (den slags, der forårsager runtime-fejl, ikke brud) får ikke den samme disciplin som sikkerhedsfejl, fordi de ligger uden for sikkerhedsteamets rækkevidde. dashboardOg når et team allerede har en statisk analysemotor, der analyserer hver fil af sikkerhedsmæssige årsager, er det overflødigt arbejde uden fælles fordel at oprette en anden, urelateret motor blot for at kontrollere kodekvaliteten.
Hvorfor kodekvalitet er vigtig (og hvordan den er anderledes end Code Security)
Kodekvalitet og code security besvare to forskellige spørgsmål. Code security spørger: kan denne kode udnyttes? Kodekvalitet spørger: kan denne kode vedligeholdes? En funktion kan være perfekt sikker og stadig være et virvar på fem hundrede linjer, som ingen ønsker at røre ved, og et velorganiseret, letlæseligt modul kan stadig leveres med en kritisk injektionsfejl. Ingen af disciplinerne erstatter den anden.
Omkostningerne ved at ignorere kodekvalitet viser sig ikke som et brud. Det viser sig langsommere: en nyansat bruger to uger i stedet for to dage på at foretage en sikker ændring, en rutinemæssig funktion tager tre sprints, fordi ingen kan forudsige, hvad en duplikeret blok vil ødelægge andre steder, en vagtingeniør bruger en time på at spore en fejl gennem død kode, der burde have været fjernet for et år siden. Intet af det udløser en sikkerhedsadvarsel. Alt dette viser sig i hastighed, og når det er synligt i en sprint-retro, er det allerede dyrt at reparere.
Det er tilfældet, når man skal behandle kvalitet med samme strenghed som sikkerhed: ikke fordi en lugt af kode er en trussel, men fordi det at lade vedligeholdelsesgæld ophobe sig uovervåget er, hvordan en kodebase bliver det sted, hvor funktioner dør.
Den bedre måde: Én motor, to regelkataloger
Xygenis kodekvalitetsscanner analyserer kildekode for vedligeholdelses- og pålidelighedsfejl: kodelugt, kompleksitetsbrud, død kode og duplikering - de mønstre, der ikke forårsager et brud, men som forårsager nedbrud, regressioner og langsomme teams.
Det karakteristiske designvalg er arkitektonisk, ikke kosmetisk. Code Quality deler sin statiske analysemotor med Xygenis SAST scanner: de samme parsere, den samme AST-konstruktion, den samme filopdagelse. Hvad den ikke deler, er regelkataloget. Kvalitetsregler er begrænset til kvalitet, ikke sikkerhed, og resultaterne vises i en dedikeret kvalitetssektion på Xygeni-platformen, der holdes adskilt fra SAST og resten af sikkerhedsrisikotabellerne.
Resultatet: Teams får et vedligeholdelsesperspektiv og et sikkerhedsperspektiv fra den samme underliggende analyseproces, uden at flette to forskellige bekymringer sammen til én støjende dashboard.
To måder at få et kvalitetssignal i din Pipeline
Ikke alle funktioner til "kodekvalitet" fungerer på samme måde under motorhjelmen. Mange CI/CD-native kvalitetsværktøjer er aggregeringslag: de analyserer ikke selv din kodede importerer resultater fra den linter, du allerede kører (en JavaScript-linter, en Python-linter, en duplikationsdetektor), hver omformateret til et delt JSON-skema, hver opsat som sin egen pipeline trin. Det er fleksibelt, men det betyder, at dit kvalitetssignal kun er så ensartet som antallet af separate værktøjer, formater og vedligeholdere, du har sat sammen, ét pr. sprog.
Xygenis Code Quality-scanner tager den anden vej: én native motor, der allerede kører af sikkerhedsmæssige årsager, udvidet med et kvalitetsregelkatalog. Der er ingen linter, der skal installeres pr. sprog, intet rapportformat, der skal omformateres, intet separat job, der skal vedligeholdes pr. værktøj. Du får én kommando, én ensartet alvorlighedsmodel og én dashboard afsnittet, fordi analysen aldrig var opdelt på tværs af værktøjer til at begynde med.
Hvordan Virker Det?
Kodekvalitet kører som sin egen CLI-kommando:
xygeni kvalitet -d [indstillinger] (xygeni kodekvalitet fungerer som et alias.)
Den deler sin optionsmodel med xygeni sast, så alle, der allerede kører Xygenis sikkerhedsscanner, vil genkende brugerfladen med det samme:
Generering af en kodekvalitetsrapport
En scanning producerer en kodekvalitetsrapport, som du kan sende til platformen, eksportere som JSON til CI-artefakter eller give til en teamleder uden at give dem dashboard adgang. Begge er kommandoer på én linje:
# Scan og upload direkte til Xygeni-platformen
xygeni kvalitet -n MitProjekt –upload
# Eksporter en kodekvalitetsrapport som JSON, kun kritiske fund
xygeni kvalitet -d –detektorer kritiske –format json –output quality.json
Når den er uploadet, er det den samme kodekvalitetsrapport, der udfylder Kvalitetssektionen i dashboardfiltrerbar, med udskydelige detaljer pr. fund, baselines og den samme rapporteringsadfærd, som teams allerede bruger til SAST.
Kørekvalitet sideløbende med en sikkerhedsscanning
For hold, der ønsker begge signaler fra en enkelt aflevering, SAST scanneren accepterer en –inkluder-kvalitet flag:
xygeni sast -d –inkluder-kvalitet
Fordi SAST og Kodekvalitet deler parserfasen, hvilket er mere effektivt end at køre de to scannere efter hinanden. Det producerer to separate rapporter, sikkerhed og kvalitet, og hver især ender stadig i sin egen situation. dashboard sektion. Flaget ændrer, hvordan scanningen udføres, ikke hvordan resultaterne er organiseret.
Scanning uden forbindelse
For miljøer med luftgab eller CI-løbere uden udgang til Xygeni-platformen kan kvalitetsscanninger køres lokalt og uploades senere:
xygeni kvalitet -d -n MitProjekt
# …senere, fra en vært med forbindelse:
xygeni rapport-upload -n MitProjekt -r depsdoctor-quality.json
Resultaterne lander i kvalitetssektionen præcis som de ville gøre fra en live-scanning: samme triage, samme politik, samme grundlæggende adfærd.
Hvorfor det er vigtigt at holde kvalitet adskilt fra sikkerhed
Det ville være nemt at inkludere kodelugt i samme alvorlighedsliste som en sårbarhed, der kan udnyttes. Xygeni gør det bevidst ikke. En duplikeret funktion og en SQL-injektion er ikke den samme type risiko, og at behandle dem på samme måde træner teams i enten at overreagere på vedligeholdelsesstøj eller underreagere på reelle sikkerhedsresultater. At holde regelkatalogerne, rapporterne og dashboard separate visninger, mens de deler den nedenstående motor, betyder det, at hvert team får det signal, der er vigtigt for dem, uden at betale for et andet statisk analyseværktøj.
Prøv det: Kodekvalitet er tilgængelig i dag via Xygeni CLI. Teams, der allerede kører xygeni sast kan tilføje –inkluder-kvalitet til deres eksisterende pipeline i én linje, intet nyt værktøj at ombygge, intet andet dashboard at tjekke.
Ofte stillede spørgsmål
Hvad er Xygeni-kodekvalitet?
Xygeni Code Quality er en statisk analysescanner, der registrerer vedligeholdelses- og pålidelighedsfejl, herunder kodelugt, kompleksitetsbrud, død kode og duplikering. Den kører som sin egen kommando (xygeni-kvalitet) og rapporterer til en dedikeret kvalitetssektion på Xygeni-platformen, adskilt fra sikkerhedsresultater.
Er kodekvalitet det samme som SAST?
Nr. Kodekvalitet og SAST dele den samme underliggende parsing-motor, men bruge uafhængige regelkataloger og producere uafhængige rapporter. SAST leder efter sikkerhedssårbarheder; Kodekvalitet leder efter mangler i vedligeholdelse og pålidelighed.
Kan jeg køre en kvalitetsscanning og en sikkerhedsscanning på samme tid?
Ja. Løber. xygeni sast -d –inkluder-kvalitet udfører begge regelsæt i én omgang, hvilket er mere effektivt end at køre de to scannere separat, da de deler parserfasen. Resultaterne producerer stadig to separate rapporter og vises i to separate dashboard sektioner.
Har jeg brug for en separat licens til kodekvalitet?
Upload og visning af kvalitetsresultater kræver kodekvalitetsrettighederne, den samme som kræves for at køre scanningen.
Kan Code Quality køre uden internetadgang?
Ja. Scanninger kan køre lokalt uden –upload flag, og den resulterende rapport kan uploades senere fra en tilsluttet vært ved hjælp af Upload af xygeni-rapport.
