Koodikvaliteedi roll: kriitilised mõõdikud ja nende mõju

Koodikvaliteeti saab mõõta. See väide kõlab ilmselgelt seni, kuni proovid vastata küsimusele, mida CTO esitab enne tarkvaratoote omandamist või tehnoloogiajuht enne refaktoriseerimisprogrammiga liitumist: kuidas sa tead, et kood on hea? „See töötab” ei ole vastus. „Meeskond vaatas selle üle” ei ole vastus. Vastus nõuab objektiivseid mõõtmisi, mida rakendatakse järjepidevalt: tsüklomaatiline keerukus funktsiooni kohta, hooldatavuse indeks mooduli kohta, defektide tihedus tuhande rea kohta, testide hõlmatus komponendi kohta, koodivoolavus faili kohta sprindi kohta. Kõik need on numbrid. Numbreid saab trendida, võrrelda ja nende põhjal tegutseda.

Väljakutse seisneb selles, et koodikvaliteedi mõõdikud ei ole omavahel asendatavad ega universaalselt tõlgendatavad. Kõrge hooldatavuse indeks COBOL-programmis tähendab midagi muud kui sama skoor Pythoni skriptis. Tsüklomaatiline keerukus 15 on vastuvõetav hästi testitud olekumasinas ja tõsine probleem valideerimisfunktsioonis. Defektide tihedus 2 viga KLOC-i kohta on suurepärane süsteemiprogrammeerimisel ja murettekitav ohutuskriitilises manussüsteemi rakenduses. Mõõdikute kasulikuks muutmiseks on vaja mõista, mida igaüks neist mõõdab, mis seda üles või alla ajab ja millised läviväärtused on konteksti jaoks sobivad. Selle artikli ülejäänud osa pakub just seda.

Mis on koodikvaliteet?

Koodi kvaliteet on aste, milleni lähtekood vastab mõõdetavate omaduste komplektile, mis muudavad selle korrektseks, hooldatavaks, loetavaks, tõhusaks, turvaliseks ja testitavaks. Ükski omadus ei määratle kvaliteeti eraldi. Korrektselt töötava, kuid loetamatu koodi kvaliteet langeb iga muudatusega, sest arendajad, kes seda ei mõista, ei saa seda ohutult muuta. Loetav, kuid testimata kood sisaldab varjatud defekte. Testitud, kuid struktuurilt keerukas kood kogub kasvades rohkem defekte, sest keerukus mitmekordistab tõenäosust, et iga antud muudatus rikub midagi ootamatut.

Standardi ISO/IEC 25010 ametlik definitsioon toob välja kaheksa tarkvara kvaliteediomadust: funktsionaalne sobivus, jõudluse efektiivsus, ühilduvus, kasutatavus, töökindlus, turvalisus, hooldatavus ja kaasaskantavus. Täpsemalt lähtekoodi puhul on omadused, mida saab mõõta otse koodist endast, mitte käitusaja käitumisest, hooldatavus, töökindlus (lähendatakse defektide ja keerukuse mõõdikute abil), turvalisus (staatilise analüüsi abil) ja funktsionaalne sobivus (testimise kaudu). Teiste omaduste mõõtmiseks on vaja koodi käivitada. Koodi kvaliteedi mõõdikud hõlmavad seega tarkvara kvaliteedi määratletud ja olulist alamhulka, mitte kogu seda.

Miks on koodi kvaliteet oluline

Tehnilised meeskonnad teavad, miks koodi kvaliteet on oluline. Äripartnerite ja meeskondade jaoks, kes peavad sisemiselt argumente esitama, on seos kulude ja aja kaudu. McKinsey ja IT-tarkvara kvaliteedi konsortsiumi (CISQ) uuringud näitavad järjepidevalt, et arendajad kulutavad 30–40 protsenti oma ajast olemasoleva tehnilise võla lahendamisele, selle asemel et arendada uut funktsionaalsust. Halb koodi kvaliteet on mehhanism, mille abil tehniline võlg koguneb: iga defekt, mida varakult ei avastata, iga funktsioon, mis on keerulisem kui vaja, iga dubleeritud loogikaplokk, mida tuleb eraldi hooldada, suurendab järgmise muudatuse maksumust. Kõrge koodi kvaliteet vähendab seda kulu pidevalt, kogudes kogu süsteemi eluea jooksul.

Koodikvaliteedi mõõdikud: täielik viide

Allolevad mõõdikud hõlmavad kõiki peamisi koodikvaliteedi mõõtmise kategooriaid. Iga mõõdiku kohta on selgitatud definitsiooni, mõõtmismeetodit, vastuvõetavat vahemikku ja tõlgendust. Allolevas tabelis olevad läviväärtused kajastavad laialdaselt viidatud tööstusharu võrdlusaluseid; ohutuskriitilistes või reguleeritud keskkondades töötavad meeskonnad peaksid rakendama rangemaid läviväärtusi.

Keerukuse mõõdikud

Tsüklomaatiline keerukus mõõdab lineaarselt sõltumatute teede arvu funktsiooni või meetodi kaudu. Selle võttis kasutusele Thomas McCabe 1976. aastal ja see on siiani kõige laialdasemalt kasutatav keerukusmõõt. Valem loendab otsustuspunkte, if, else if, switch juhtumid, tsükli tingimused, catch plokid ja tingimuslikud operaatorid ning liidab 1. Harudeta funktsiooni tsüklomaatiline keerukus on 1.

Tsüklomaatiline keerukus	Tõlgendus
1-5	Lihtne, kergesti testitav
6-10	Mõõdukas, hallatav
11-20	Kompleksne, testimine muutub keeruliseks
21-50	Väga kõrge risk, refaktoreerimine on soovitatav
50 +	Testimatu, peaaegu kindlasti defektide sisaldus

Suur tsüklomaatiline keerukus on tugevalt seotud defektide tihedusega. IEEE Transactions on Software Engineering avaldatud uuringus leiti, et funktsioonidel, mille tsüklomaatiline keerukus on üle 10, on oluliselt kõrgem defektide määr kui lihtsamatel funktsioonidel. Tsüklomaatilise keerukuse analüüsi puhul pärandkoodibaasides on murekohaks leida funktsioone, millel on aastatepikkuse hoolduse jooksul kogunenud otsustusloogika ilma, et keegi oleks kunagi üldist struktuuri ümber faktoriseerinud.

NPathi keerukus loendab funktsiooni unikaalsete teostusteede arvu, sealhulgas pesastatud tingimuste ja tsüklite loodud teid. Kui tsüklomaatiline keerukus loendab harusid lineaarselt, siis NPathi keerukus korrutab need: funktsioonil, millel on kolm järjestikust if-else plokki, on tsüklomaatiline keerukus 4, kuid NPathi keerukus 8, kuna iga tingimus võib olla sõltumatult tõene või väär. NPathi keerukus kasvab pesastusega eksponentsiaalselt. Väärtus üle 200 näitab funktsiooni, mis nõuaks rohkem testjuhtumeid, kui ükski meeskond realistlikult kirjutada suudab.

Kognitiivne keerukus võeti kasutusele SonarSource'i poolt ja see mõõdab koodi mõistmise raskust, mitte seda, kui palju teid see sisaldab. See karistab pesastamist rohkem kui lineaarset hargnemist: if sees a while teise sees if skoorid, mis on kõrgemad kui kolm järjestikust if sama tsüklomaatilise keerukusega laused. Kognitiivne keerukus on paremini kooskõlas arendajate tegelike raskustega koodi lugemisel. Kognitiivne keerukus üle 15 meetodi kohta märgitakse üldiselt ülevaatamiseks; üle 25 näitab see funktsiooni, mille üle enamikul arendajatel on tõeliselt raske arutleda.

Halsteadi mõõdikud tuletavad lähtekoodi neljast loendusest mõõdikute perekonna: erinevad operaatorid (n1), erinevad operandid (n2), operaatorite koguarv (N1) ja operantide koguarv (N2). Nende põhjal arvutab Halstead:

• maht (N × log2(n)): infosisu rakenduse suurus
• Raskus (n1/2 × N2/n2): hinnang selle kohta, kui keeruline on koodi kirjutada või mõista
• Pingutus (Maht × Raskusaste): hinnanguline koguvaimne pingutus koodi rakendamiseks või mõistmiseks

Halsteadi mõõdikud on eriti kasulikud sarnase tsüklomaatilise keerukusega funktsioonide võrdlemisel, et teha kindlaks, millist on raskem mõista. Funktsioonil, millel on 10 haru selgelt nimetatud muutujate kohal, on Halsteadi mõõdiku abil väiksem raskusaste kui funktsioonil, millel on 10 haru arvutatud indeksite ja ühemärgiliste identifikaatorite kohal.

Hooldatavuse mõõdikud

Hooldatavuse indeks on liitmõõdik, mille algselt töötasid välja Paul Oman ja Jack Hagemeister ning mille Microsoft Visual Studio hiljem standardse hooldatavuse mõõdikuna kasutusele võttis. See ühendab Halsteadi mahu, tsüklomaatilise keerukuse ja koodiread üheks skooriks.

Visual Studio valem annab tulemuseks hinde vahemikus 0 kuni 100:

Hooldavuse indeks	Hinnang
20-100	Hooldatav (roheline)
10-19	Mõõdukas hooldusprobleem (kollane)
0-9	Raske hooldada (punane)

Hooldatavuse indeks on kokkuvõtlik statistiline näitaja. See on kõige kasulikum punasesse tsooni jäävate kõrvalekallete, failide või moodulite tuvastamiseks, mitte rohelise tsooni moodulite detailseks võrdlemiseks. Pythonis on radon teek arvutab hooldatavuse indeksi otse. Visual Studios kuvatakse see koodi mõõdikute aknas. Näiteks staatilise koodi analüüs Platvormidel on hooldatavuse indeks tavaliselt üks standardväljunditest koos tsüklomaatilise keerukuse ja koodiridade arvuga.

Koodiread (LOC) ja KLOC mõõdavad koodibaasi suurust ridades või tuhandetes ridades. LOC üksi ei ütle kvaliteedi kohta midagi, kuid annab olulisi nimetajaid teistele mõõdikutele: defektide tihedus on vigade arv KLOC kohta, kommentaaride tihedus on kommentaaride arv LOC kohta, testide tihedus on testiväidete arv LOC kohta. LOC skaleerib ka keerukuse hinda: 500-realine funktsioon tsüklomaatilise keerukusega 20 on palju suurem probleem kui sama skooriga 50-realine funktsioon.

Koodivoolavus on kiirus, millega kood ajas muutub, mõõdetuna lisatud ridade, kustutatud ridade ja muudetud ridade arvuna faili kohta ajaühikus. Suur koodivoolavus näitab ebastabiilsust: sageli muutuv kood võib reageerida disainile, mis polnud algusest peale õige, nõuetele, mis ei olnud stabiilsed, või vigadele, mis vajavad pidevalt parandusi. Microsofti uuring näitas, et koodivoolavusest 10% suuremates failides oli viis korda rohkem defekte kui väikese vooluga failides. Koodivoolavuse jälgimine koos defektide määraga näitab, kas sagedased muudatused parandavad kvaliteeti või tekitavad uusi probleeme.

Koodi katvuse mõõdikud

Ühiktestide katvus on koodibaasis olevate ridade, harude või tingimuste protsent, mida ühiktestid täidavad. Kõige tähendusrikkam vorm on harude katvus: kas iga koodis oleva otsuseni saab jõuda vähemalt ühe testiga nii tõese kui ka väära tulemuse korral. Rea katvust on lihtsam manipuleerida – test, mis täidab iga rea ​​ilma midagi kinnitamata, saavutab 100% rea katvuse ega püüa midagi kinni.

Ühiktestide katvuse valdkonna võrdlusnäitajad:

• Alla 50%: ebapiisav, enamik defekte ei leia testidest
• 50–75%: mõõdukas, peamised teed kaetud, äärejuhtumid tõenäoliselt vahele jäänud
• 75–90%: hea enamiku rakenduskoodi jaoks
• Üle 90%: sobib ohutuskriitiliste või suure töökindlusega süsteemide jaoks

Ohutuskriitiliste rakenduste koodi katvus järgib rangemaid standardeid. Lennundustarkvara DO-178C ja funktsionaalse ohutuse IEC 61508 määravad katvuse nõuded (MC/DC katvus kõrgeimate kriitilisuse tasemete jaoks), mis ületavad standardse ühiktestimise saavutatut. Ohutuskriitiliste rakenduste koodi kvaliteedi parandamiseks on vaja katvuse tööriistu, mis jälgivad tingimuste/otsuste katvust ja suudavad esitada sertifitseerimisasutuste nõutavaid ametlikke tõendeid.

Testitihedus täiendab katvust, mõõtes testiväidete arvu tootmiskoodi suuruse suhtes. Suur katvus madala testitihedusega võib viidata testidele, mis käivitavad koodi ilma käitumist sisukalt kontrollimata. Suur testitihedus madala katvusega näitab teste, mis on koondunud väikesesse ossa koodibaasist.

Defektide mõõdikud

Vigade tihedus (ka defektide tihedus) on kinnitatud defektide arv tuhande koodirea kohta (KLOC). See on koodi õigsuse kõige otsesem kvantitatiivne mõõt. CISQ tööstusharu võrdlusnäitajad näitavad, et kommertslikul valmistarkvaral on enne testimist keskmiselt umbes 15–50 defekti KLOC kohta; pärast testimist ja väljaandmist on kvaliteetsel kommertstarkvaral tavaliselt alla ühe defekti KLOC kohta.

Staatilise analüüsi tulemused ligikaudne defektide tihedus enne, kui defektid testimise või tootmise käigus kinnitatakse. Tööriistad nagu SonarQube, Checkmarx ja SMART TS XL Analüüsib koodibaasi teadaolevate defektide ja haavatavuste klassidega seotud mustrite suhtes, genereerides tõsiduse järgi kategoriseeritud potentsiaalsete probleemide loendi. Kriitiliste ja blokeerivate leidude ning LOC suhe annab varajase signaali koodi kvaliteedist enne, kui kood jõuab testimiseni.

Koodi lõhna tihedus loendab antimustrite, dubleeritud koodi, liiga pikkade funktsioonide, liigse klasside sidumise, tunnuste kadeduse ja jumalobjektide olemasolu vastavalt KLOC-ile. Koodi lõhnad ei põhjusta koheseid tõrkeid, vaid ennustavad tulevasi defekte ja hoolduskulusid. Kõrge koodi lõhna tihedusega koodibaas on selline, kus iga tulevase muudatuse maksumus on kõrgem, kuna iga muudatus peab navigeerima akumuleerunud struktuuriliste probleemidega.

Loetavuse ja stiili mõõdikud

Kommentaari tihedus on kommentaariridade ja koodiridade suhe. Optimaalsed vahemikud varieeruvad keele ja meeskonna tavade lõikes, kuid jäävad tavaliselt vahemikku 10–30%. Alla 10% võib viidata ebapiisavalt dokumenteeritud koodile; üle 50% võib viidata koodile, mis on nii keeruline, et see nõuab mitteilmselge loogika ulatuslikku selgitamist. Kommentaaride kvaliteet on olulisem kui kvantiteet: kommentaar, mis kordab koodi toimimist (// increment i by 1) ei lisa midagi, samas kui kommentaar, mis selgitab, miks konkreetne algoritm valiti, lisab olulist väärtust.

Nimekonventsioonide järgimine mõõdab projekti nimetamiskonventsioonidele vastavate identifikaatorite (muutujate, funktsioonide, klasside) protsenti. Automatiseeritud tööriistad saavad nimetamiskonventsioone linting-konfiguratsiooni osana jõustada. Järjepidev nimetamine on üks kõige suurema potentsiaaliga loetavuse täiustusi, kuna see võimaldab arendajatel ennustada identifikaatori eesmärki ainuüksi selle nime põhjal, vähendades harjumatu koodi lugemisega seotud kognitiivset koormust.

Koodi dubleerimise määr mõõdab koodibaasi protsenti, mis on dubleeritud mitmes asukohas. Üle 5% dubleerimist märgistatakse tavaliselt. Dubleeritud kood mitmekordistab hooldustöö: dubleeritud loogika viga tuleb leida ja parandada igas koopias ning käitumise muudatusi tuleb rakendada järjepidevalt kõigis koopiates. Duplikeerimine varjab ka koodibaasi tegelikku suurust: süsteem, millel näib olevat 100 000 rida, võib sisaldada 40 000 rida unikaalset loogikat ja 60 000 rida koopiaid.

Turvalisuse ja tehnilise võla mõõdikud

Tehnilise võla suhtarvu defineerib SonarQube kui hinnangulise paranduskulu ja koodibaasi hinnangulise arenduskulu suhet. Alla 5% olevat tehnilise võla suhet peetakse puhtaks koodibaasiks; üle 20% näitab märkimisväärset kogunenud võlga, mis aeglustab oluliselt edasist arendust.

Turvalisuse levialade tihedus loendab KLOC-i järgi turva levialade, turvaülevaatust vajavate koodimustrite ja kinnitamata haavatavuste arvu. Näideteks on parameetriteta SQL-päringud, aegunud krüptograafiliste funktsioonide kasutamine ja valideerimata sisendi käsitlemine. Staatilise analüüsi tööriistad tuvastavad need mustrid ja esitavad need käsitsi turvaülevaatust vajavate üksustena.

Haavatavuse tihedus loendab kinnitatud turvaauke KLOC-i kohta, tavaliselt liigitades need CVSS-i raskusastme järgi. See mõõdik on kõige olulisem väljalaskejärgsete turvaauditite või pideva turvaseire kontekstis.

Kuidas mõõta koodi kvaliteeti: praktiline lähenemine

Koodikvaliteedi mõõtmine ei ole ühekordne tegevus, vaid pidev praktika, mis on integreeritud arendusprotsessi. Pragmaatiline neljafaasiline lähenemine sobib hästi meeskondadele, kes alustavad mõõtmata koodibaasist.

1. etapp: Lähtetaseme määramine. Enne muudatuste tegemist tehke koodibaasis täielik staatiline analüüs. Salvestage tsüklomaatilise keerukusjaotuse, failide kaupa hooldatavuse indeksi, defektide tiheduse, katvuse ja dubleerimise määra praegused väärtused. See lähtetase on lähtepunkt, millega võrreldakse kõiki tulevasi mõõtmisi. Ilma lähtetasemeta ei saa öelda, kas muudatused parandavad või halvendavad kvaliteeti.

2. etapp: Määrake läviväärtused. Määrake iga mõõdiku jaoks kontekstist lähtuvalt vastuvõetavad läviväärtused. Kommertsveebirakendusel ja ohutuskriitilisel meditsiiniseadmel on erinevad sobivad läviväärtused. Dokumenteerige need läviväärtused projekti kvaliteedistandardites ja tehke need kogu meeskonnale nähtavaks.

3. etapp: integreerimine CI/CD-sse. Konfigureerige CI torujuhe arvutama iga commit- või pull-taotluse põhimõõdikuid. Märgistage muudatused, mis viivad mõõdiku väljaspool selle vastuvõetavat vahemikku. Plokkide liitmised, mis toovad kaasa uut koodi, mille tsüklomaatiline keerukus ületab läve, mis vähendab ulatust alla läve või mis toovad kaasa kriitilisi staatilise analüüsi tulemusi. See muudab mõõdikute läviväärtused suunistest jõustatavateks standarditeks.

4. etapp: Vaadake üle trendid, mitte hetktõmmised. Üksik mõõdiku näit on informatiivne; trend on tegutsemist vajav. Koodivoolu tõusutrend konkreetses moodulis, katvuse langustrend kogu väljalasketsükli vältel või hooldatavuse indeksi langustrend konkreetse faili puhul viitavad probleemidele, mida hetktõmmise mõõtmine võib kahe silma vahele jätta. Vaadake mõõdikute trendid üle igal sprindi retrospektiivil.

Koodikvaliteedi mõõdikud ettevõtte, agiilses ja ohutuskriitilises kontekstis

Koodikvaliteedi mõõdikud agiilses arenduses

Agiilsed meeskonnad seisavad silmitsi koodi kvaliteedi mõõdikutega seotud spetsiifilise väljakutsega: rõhk toimiva tarkvara tarnimisel lühikeste tsüklitega võib tekitada surve tarnida enne kvaliteediprobleemide lahendamist. Lahendus ei ole mõõdikute hülgamine, vaid nende lisamine valmisoleku definitsiooni. Lugu ei ole täielik siis, kui funktsioon töötab; see on täielik siis, kui funktsioon töötab ja uus kood vastab meeskonna kvaliteedilävedele.

Agiilsetes kontekstides on juhtivad näitajad, mis ennustavad tulevasi probleeme enne nende ilmnemist, näiteks koodi voolavuse määr, sprindi kohta lisandunud uus tehniline võlg ja staatilise analüüsi leidude arvu trend versiooni kohta. Mahajäävad näitajad, mis mõõdavad juba saavutatud tulemusi, hõlmavad testimisel leitud defektide tihedust, hooldusele kulutatud aega võrreldes uute funktsioonidega ja tootmisintsidentide määra versiooni kohta.

Koodi kvaliteet tehnilise hoolsuskohustuse täitmiseks

Tehniline hoolsuskohustus ühinemis- ja omandamistehingutes, tarnijate valikul ja süsteemide hankimisel nõuab koodi kvaliteedi struktureeritud hindamist kogu koodibaasis. Selles kontekstis on kõige olulisemad näitajad järgmised:

• Hooldatavuse indeksi jaotus: mitu protsenti koodibaasist langeb punasesse, kollasesse ja rohelisse tsooni
• Tehniline võlakordajaMilline on hinnanguline paranduskulu võrreldes arenduskuludega?
• Defektide tihedus: mitu teadaolevat defekti esineb KLOC-i kohta ja kuidas see võrdub valdkonna võrdlusnäitajatega
• Katse katvus: kui suur osa koodibaasist on automatiseeritud testidega kaetud ja millisel tasemel (rida, haru, tingimus)
• Sõltuvustervis: kui palju väliseid sõltuvusi on olemas, kui palju on aegunud või hüljatud ja kui sügavalt on arhitektuur seotud
• Koodi dubleerimine: milline osa koodibaasist on dubleeritud, mis näitab hooldusriski

Nagu ettevõtte koodi hindamise mõjuanalüüsi kontekstis uuriti , on täpse hoolsuskohustuse täitmiseks oluline mõista mitte ainult iga komponendi kvaliteedinäitajate tulemust, vaid ka seda, kuidas komponendid üksteisest sõltuvad: madala kvaliteediga, kuid isoleeritud moodul võib esindada hallatavaid paranduskulusid, samas kui sama moodul tiheda sõltuvusgraafiku keskel kujutab endast palju suuremat riski.

Koodikvaliteet ohutuskriitilistes ja finantstehnoloogia rakendustes

Lennunduses, autotööstuses, meditsiiniseadmetes ja tööstusjuhtimises kasutatavad ohutuskriitilised rakendused nõuavad koodi kvaliteedistandardeid, mis ületavad tüüpilise kommertstarkvara nõudeid. Peamised erinevused:

• Tsüklomaatilise keerukuse piirid on tavaliselt seatud 10-le või madalamale ning erandid vajavad ametlikku põhjendust.
• Katvusnõuete puhul kasutatakse liini- või harukindlustuse asemel MC/DC (muudetud tingimus-/otsuse kindlustus).
• Staatiline analüüs tuleb läbi viia sertifitseeritud tööriistadega ning rikkumised tuleb dokumenteerida ja lahendada või ametlikult aktsepteerida.
• Koodi voolavust jälgitakse ohutusnäitajana: kõrge muutuste määr ohutuskriitilistes moodulites käivitab täiendava ülevaatuse ja uuesti valideerimise.

Finantstehnoloogia rakendused seisavad regulatiivsete raamistike poolt silmitsi sarnase survega. PCI DSS nõuab turvalisi kodeerimisstandardeid ja koodi ülevaatamise protsesse. Finantsaruandlussüsteemide SOX-vastavus nõuab dokumenteeritud jälgitavust nõuetest läbi koodi kuni testideni. Koodikvaliteedi mõõdikud pakuvad objektiivseid tõendeid nende protsesside toimimise kohta: katvusaruanded tõestavad testide olemasolu, staatilise analüüsi aruanded tõestavad, et teadaolevaid haavatavusmustreid kontrolliti, ja keerukusaruanded näitavad, et retsensendid said koodi mõistlikult hinnata.

Koodikvaliteedi mõõdikud keele järgi

Pythoni koodi kvaliteedi mõõdikud saab arvutada, kasutades radon (tsüklomaatiline keerukus ja hooldatavuse indeks), pylint (koodilõhnad ja stiilirikkumised), coverage.py (testi ulatus), bandit (turvaprobleemid) ja mypy or pyright (tüübi õigsus). Hooldatavuse indeks radon kasutab Pythoni jaoks kalibreeritud modifitseeritud Halsteadi valemit. Hinne A on üle 20, hinne B on 10-20, hinne C on alla 10.

RPG koodi kvaliteet IBM i-s vajab see spetsiaalseid tööriistu, kuna standardkvaliteediga mõõdikute tööriistad ei parsi RPG süntaksit. SMART TS XL pakub RPG-programmide tsüklomaatilist keerukust, koodiridade ja sõltuvuste analüüsi, mis on eriti väärtuslik IBM i töökodadele, mis haldavad suuri pärandkoodibaase, kus kvaliteedi mõõtmist on varem olnud võimatu automatiseerida.

Koodi ülevaatuse mõõdikud

Koodiülevaade on kvaliteedikontrolli tegevus, mille tõhusust saab mõõta:

• Ülevaate kajastus: enne ühendamist ametliku ülevaatuse läbinud kinnitatud koodi osakaal
• Arvustuse kohta leitud defektide arv: ülevaatuse käigus leitud defektide arv võrreldes ülevaadatud muudatuste komplekti suurusega
• Vaadake üle teostusaeg: aeg pull-requesti avamisest selle ülevaatamise ja ühendamiseni
• Arvustuste kommentaaride lahendamise määr: koodi muutmisele viivate arvustuskommentaaride protsent võrreldes tagasilükkamisega

Tipptasemel meeskondadel on ülevaatuste ulatus tavaliselt üle 90%, keskmiselt leitakse ülevaatuse kohta 1–3 viga saja ülevaadatud rea kohta ja neil on lühikesed teostusajad. Ülevaatuse mõõdikud aitavad tuvastada, kas koodi ülevaatamine toimib kvaliteedikontrolli või formaalsusena.

Pidev koodikvaliteedi jälgimine

Ühekordne koodikvaliteedi mõõtmine on oluliselt vähem väärtuslik kui pidev jälgimine. Koodikvaliteet ei ole koodibaasi fikseeritud omadus; see muutub iga muudatustega. Tänapäeval hästi mõõdetav koodibaas võib kiirustades arenduse kolme sprindiga märkimisväärselt halveneda, kui kvaliteedinäitajaid pidevalt ei jälgita.

Tõhus pidev koodikvaliteedi jälgimine hõlmab järgmist:

• Kohustusliku mõõdiku arvutaminetsüklomaatilise keerukuse ja staatilise analüüsi tulemused arvutatakse iga tõuke korral
• Trendi armatuurlauad: peamiste näitajate visuaalne kuvamine aja jooksul, uuendatakse iga päev või iga väljaande kohta
• Kvaliteediväravad CI/CD-s: hooldatavust, turvalisust ja defektide riski mõjutavate mõõdikute miinimumkünniste automatiseeritud jõustamine
• Regressiooni tuvastamine: annab märku, kui mõõdik liigub versioonide vahel märkimisväärselt vales suunas

Koodi kvaliteedi paranemise peamised näitajad ehk signaalid, mis ennustavad, kas kvaliteet järgmises versioonis paraneb või halveneb, on katvuse trendi suund, sprindi kohta lisandunud uute keerukuste arv ja lahendatud koodilõhnade ning lisandunud koodilõhnade suhe. Kui need liiguvad õiges suunas, paraneb kvaliteet. Kui mitte, on halvenemine ennustatav enne, kui see on täielikult toimunud.

Kuidas SMART TS XL Mõõdab ja parandab koodi kvaliteeti

SMART TS XL arvutab selles artiklis kirjeldatud koodikvaliteedi mõõdikute komplekti kõigis arenduskeskkonna keeltes ja platvormidel: COBOL, JCL, Java, .NET, Python, JavaScript, TypeScript, RPG, SQL ja teised. Enamik kvaliteeditööriistu töötab korraga ühel keelel, SMART TS XL loob kogu süsteemi ühtse kvaliteedimudeli, mis võimaldab võrrelda kvaliteeti eri keelte vahel, jälgida mõõdikuid süsteemi tasandil, mitte faili tasandil, ning tuvastada komponentidevahelisi kvaliteediprobleeme, mida ühe keele tööriistad ei näe.

Suurte ja mitmekeelsete koodibaasidega ettevõtete jaoks on staatilise koodi analüüs võimekus SMART TS XL pakub baasmõõtmist, mida vajavad tehniline hoolsuskohustus, pärandi moderniseerimise planeerimine ja pidev kvaliteedi parandamine. sõltuvuse kaardistamine võimekus laiendab kvaliteedihindamist struktuurilistele probleemidele: millistest komponentidest kõige enam sõltutakse, millistel muudatustel on suurim plahvatusraadius ja millised koodibaasi piirkonnad kujutavad endast suurimat hooldusriski, kui kvaliteedimõõdikud on kombineeritud sõltuvuskesksusega.

SMART TS XLkoodi kvaliteedimõõdikud integreeruvad DevOpsi torujuhtmetega API kaudu, võimaldades CI/CD kihil kvaliteedikontrolle. Kui commit lisab funktsiooni, mille tsüklomaatiline keerukus ületab läve või vähendab ulatust alla konfigureeritud miinimumi või toob kaasa kriitilise staatilise analüüsi leiu, võib torujuhe ehituse nurjuda spetsiifilise diagnostikaga, mis ütleb arendajale täpselt, mida mõõdeti ja miks läve ei saavutatud. See nihutab kvaliteedi tagamise pärast avaldamist toimuvatelt audititelt arendussisesele tagasisidele, vähendades kvaliteediprobleemide kulusid, avastades need punktis, kus neid on kõige odavam parandada.

Koodikvaliteet on meeskonna distsipliin, mitte aruanne

Koodikvaliteedi mõõdikute väärtus sõltub täielikult sellest, mida meeskonnad nendega teevad. Kvartaliaruanne koodikvaliteedi kohta, millele keegi ei reageeri, on halvem kui aruande puudumine, sest see loob illusiooni, et kvaliteeti hallatakse, samal ajal kui koodibaas halveneb kontrollimatult. Mõõdikud muutuvad väärtuslikuks siis, kui need suunavad konkreetseid tegevusi: kui uue funktsiooni tsüklomaatiline keerukuse suurenemine käivitab enne funktsiooni ühendamist refaktoriseerimise vestluse, kui mooduli katvuse langus käivitab testimissprindi, kui konkreetse komponendi kasvav defektide tihedus käivitab selle komponendi disaini ametliku ülevaatuse.

Sellise kultuuri loomine eeldab mõõdikute nähtavaks tegemist õigel ajal, arenduse ajal, mitte pärast väljalaset, ning nende sidumist konkreetsete meeskonnakohustustega. Meeskonnad, kes vaatavad oma koodikvaliteedi trendid üle igal sprindi retrospektiivil, kes lisavad oma valmisoleku definitsiooni kvaliteediläved ja kes suhtuvad mõõdikute regressiooni sama tõsiselt kui funktsioonide regressiooni, loovad koodibaase, mille hooldamine on odavam ja mis aja jooksul tekitavad vähem tootmisintsidente. Mõõtmine on lähtepunkt. Distsipliin on see, mis annab tulemuse.