KÄ ieviest statiskÄ koda analizatoru mantotÄ projektÄ, nedemotivÄjot komandu
Ir viegli izmÄÄ£inÄt statiskÄ koda analizatoru. Bet, lai to Ä«stenotu, Ä«paÅ”i liela, veca projekta izstrÄdÄ, ir vajadzÄ«gas prasmes. Ja tas tiek izdarÄ«ts nepareizi, analizators var pievienot darbu, palÄninÄt attÄ«stÄ«bu un demotivÄt komandu. ÄŖsi parunÄsim par to, kÄ pareizi pieiet statiskÄs analÄ«zes integrÄcijai izstrÄdes procesÄ un sÄkt to izmantot kÄ daļu no CI/CD.
Ievads
Nesen manu uzmanÄ«bu pievÄrsa publikÄcija "Darba sÄkÅ”ana ar statisko analÄ«zi, nepÄrslogojot komandu". No vienas puses, Å”is ir labs raksts, ar kuru ir vÄrts iepazÄ«ties. No otras puses, man Ŕķiet, ka tas joprojÄm nesniedz pilnÄ«gu atbildi par to, kÄ nesÄpÄ«gi Ä«stenot statisko analÄ«zi projektÄ ar daudz RakstÄ teikts, ka JÅ«s varat pieÅemt tehnisko parÄdu un strÄdÄt tikai pie jauna koda, bet nav atbildes, ko darÄ«t ar Å”o tehnisko parÄdu vÄlÄk.
MÅ«su PVS-Studio komanda piedÄvÄ savu skatÄ«jumu uz Å”o tÄmu. ApskatÄ«sim, kÄ vispirms rodas statiskÄ koda analizatora ievieÅ”anas problÄma, kÄ Å”o problÄmu pÄrvarÄt un kÄ nesÄpÄ«gi pakÄpeniski novÄrst tehnisko parÄdu.
problÄmas
Parasti nav grÅ«ti palaist un redzÄt, kÄ darbojas statiskais analizators [1]. KodÄ var pamanÄ«t interesantas kļūdas vai pat biedÄjoÅ”as iespÄjamÄs ievainojamÄ«bas. Var pat kaut ko salabot, bet tad daudzi programmÄtÄji padodas.
Visi statiskie analizatori rada kļūdaini pozitÄ«vus rezultÄtus. Å Ä« ir statiskÄ koda analÄ«zes metodoloÄ£ijas iezÄ«me, un ar to neko nevar darÄ«t. VispÄrÄ«gÄ gadÄ«jumÄ tÄ ir neatrisinÄma problÄma, ko apstiprina Raisa teorÄma [2]. MaŔīnmÄcÄ«Å”anÄs algoritmi arÄ« nepalÄ«dzÄs [3]. Pat ja cilvÄks ne vienmÄr var pateikt, vai tas vai cits kods ir nepareizs, tad no programmas to nevajadzÄtu gaidÄ«t :).
Kļūdaini pozitÄ«vi rezultÄti nav problÄma, ja statiskais analizators jau ir konfigurÄts:
AtspÄjotas neatbilstoÅ”Äs noteikumu kopas;
Dažas neatbilstoÅ”as āādiagnostikas ir atspÄjotas;
Ja mÄs runÄjam par C vai C++, tad tiek iezÄ«mÄti makro, kas satur konkrÄtas konstrukcijas, kuru dÄļ katrÄ vietÄ, kur tiek izmantoti Å”Ädi makro, parÄdÄs bezjÄdzÄ«gi brÄ«dinÄjumi;
Ir atzÄ«mÄtas savas funkcijas, kas veic darbÄ«bas, kas lÄ«dzÄ«gas sistÄmas funkcijÄm (savs analogs memcpy vai printf) [4];
Viltus pozitÄ«vie rezultÄti ir Ä«paÅ”i atspÄjoti, izmantojot komentÄrus;
Un tÄ tÄlÄk.
Å ajÄ gadÄ«jumÄ mÄs varam sagaidÄ«t zemu viltus pozitÄ«vu rezultÄtu aptuveni 10ā15% [5]. Citiem vÄrdiem sakot, 9 no 10 analizatora brÄ«dinÄjumiem norÄda uz reÄlu koda problÄmu vai vismaz uz "spÄcÄ«gi smaržojoÅ”u kodu". PiekrÄ«tu, Å”is scenÄrijs ir ÄrkÄrtÄ«gi patÄ«kams, un analizators ir Ä«sts programmÄtÄja draugs.
ReÄli lielÄ projektÄ sÄkotnÄjÄ aina bÅ«s pavisam cita. Analizators izdod simtiem vai tÅ«kstoÅ”iem brÄ«dinÄjumu par mantoto kodu. Nav iespÄjams Ätri saprast, kuri no Å”iem brÄ«dinÄjumiem ir aktuÄli un kuri nav. Ir neracionÄli apsÄsties un sÄkt risinÄt visus Å”os brÄ«dinÄjumus, jo galvenais darbs Å”ajÄ gadÄ«jumÄ apstÄsies uz dienÄm vai nedÄļÄm. Parasti komanda nevar atļauties Å”Ädu scenÄriju. BÅ«s arÄ« milzÄ«gs skaits atŔķirÄ«bu, kas sabojÄ pÄrmaiÅu vÄsturi. Un tik daudzu koda fragmentu Ätra masveida rediÄ£ÄÅ”ana neizbÄgami radÄ«s jaunas drukas kļūdas un kļūdas.
Un pats galvenais, Å”Ädam varoÅdarbam cÄ«ÅÄ pret brÄ«dinÄjumiem ir maz jÄgas. PiekrÄ«tiet, ka, tÄ kÄ projekts veiksmÄ«gi darbojas jau daudzus gadus, lielÄkÄ daļa kritisko kļūdu tajÄ jau ir izlabotas. JÄ, Å”ie labojumi bija ļoti dÄrgi, tie bija jÄatkļūdo, tika saÅemtas negatÄ«vas lietotÄju atsauksmes par kļūdÄm utt. Statiskais analizators palÄ«dzÄs Ätri un lÄti novÄrst daudzas no Ŕīm kļūdÄm kodÄÅ”anas stadijÄ. Bet Å”obrÄ«d, tÄ vai citÄdi, Ŕīs kļūdas ir novÄrstas, un analizators galvenokÄrt atklÄj nekritiskas kļūdas vecajÄ kodÄ. Å o kodu var neizmantot, to var izmantot ļoti reti, un kļūda tajÄ var neradÄ«t ievÄrojamas sekas. IespÄjams, ka kaut kur pogas Äna ir nepareizÄ krÄsÄ, taÄu tas nevienam netraucÄ produkta lietoÅ”anu.
Protams, pat nelielas kļūdas joprojÄm ir kļūdas. Un dažreiz kļūda var slÄpt patiesu ievainojamÄ«bu. TomÄr atteikÅ”anÄs no visa un pavadÄ«t dienas/nedÄļas, risinot defektus, kas tik tikko izpaužas, izskatÄs pÄc apÅ”aubÄmas idejas.
ProgrammÄtÄji skatÄs, skatÄs, skatÄs visus Å”os brÄ«dinÄjumus par veco darba kodu... Un viÅi domÄ: mÄs varam iztikt bez statiskÄs analÄ«zes. Iesim rakstÄ«t kÄdu jaunu noderÄ«gu funkcionalitÄti.
SavÄ veidÄ viÅiem ir taisnÄ«ba. ViÅi domÄ, ka vispirms viÅiem ir kaut kÄ jÄatbrÄ«vojas no visiem Å”iem brÄ«dinÄjumiem. Tikai tad viÅi varÄs gÅ«t labumu no regulÄras koda analizatora lietoÅ”anas. PretÄjÄ gadÄ«jumÄ jauni brÄ«dinÄjumi vienkÄrÅ”i noslÄ«ks vecajos, un neviens tiem nepievÄrsÄ«s uzmanÄ«bu.
Å Ä« ir tÄda pati analoÄ£ija kÄ ar kompilatora brÄ«dinÄjumiem. Ne velti viÅi iesaka kompilatoru brÄ«dinÄjumu skaitu paturÄt pie 0. Ja ir 1000 brÄ«dinÄjumu, tad, kad bÅ«s 1001, neviens tam nepievÄrsÄ«s uzmanÄ«bu, un nav skaidrs, kur meklÄt Å”o jaunÄko brÄ«dinÄjumu.
SliktÄkais Å”ajÄ stÄstÄ ir, ja kÄds no augÅ”as Å”ajÄ brÄ«dÄ« liek jums izmantot statisko koda analÄ«zi. Tas tikai demotivÄs komandu, jo no viÅu viedokļa radÄ«sies papildu birokrÄtiskÄ sarežģītÄ«ba, kas tikai traucÄ. Neviens neskatÄ«sies uz analizatora atskaitÄm, un visa izmantoÅ”ana bÅ«s tikai āuz papÄ«raā. Tie. FormÄli analÄ«ze ir iebÅ«vÄta DevOps procesÄ, taÄu praksÄ tas nevienam nedod labumu. MÄs dzirdÄjÄm detalizÄtus stÄstus no konferences apmeklÄtÄjiem stendos. Å Äda pieredze var atturÄt programmÄtÄjus no statiskÄs analÄ«zes rÄ«ku izmantoÅ”anas ilgu laiku, ja ne uz visiem laikiem.
TehniskÄ parÄda ievieÅ”ana un likvidÄÅ”ana
Faktiski statiskÄs analÄ«zes ievieÅ”anÄ pat lielÄ vecÄ projektÄ nav nekÄ sarežģīta vai biedÄjoÅ”a.
CI / CD
TurklÄt analizatoru var nekavÄjoties iekļaut nepÄrtrauktÄ izstrÄdes procesÄ. PiemÄram, PVS-Studio izplatÄ«jumÄ ir utilÄ«tas, lai Ärti skatÄ«tu atskaiti vajadzÄ«gajÄ formÄtÄ, un paziÅojumi izstrÄdÄtÄjiem, kuri uzrakstÄ«juÅ”i problemÄtiskas koda sadaļas. Tiem, kurus vairÄk interesÄ PVS-Studio palaiÅ”ana no CI/CD sistÄmÄm, iesaku iepazÄ«ties ar atbilstoÅ”o sadaÄ¼Ä dokumentÄcija un rakstu sÄrija:
Bet atgriezÄ«simies pie jautÄjuma par lielu skaitu kļūdaini pozitÄ«vu koda analÄ«zes rÄ«ku ievieÅ”anas pirmajos posmos.
EsoÅ”o tehnisko parÄdu novÄrÅ”ana un jaunu brÄ«dinÄjumu risinÄÅ”ana
MÅ«sdienu komerciÄlie statiskie analizatori ļauj izpÄtÄ«t tikai jaunus brÄ«dinÄjumus, kas parÄdÄs jaunÄ vai mainÄ«tÄ kodÄ. Å Ä« mehÄnisma Ä«stenoÅ”ana atŔķiras, bet bÅ«tÄ«ba ir viena. PVS-Studio statiskajÄ analizatorÄ Å”Ä« funkcionalitÄte tiek Ä«stenota Å”Ädi.
Lai Ätri sÄktu izmantot statisko analÄ«zi, mÄs iesakÄm PVS-Studio lietotÄjiem izmantot brÄ«dinÄjumu masveida slÄpÄÅ”anas mehÄnismu [6]. VispÄrÄjÄ ideja ir Å”Äda. LietotÄjs palaida analizatoru un saÅÄma daudzus brÄ«dinÄjumus. TÄ kÄ projekts, kas tiek izstrÄdÄts daudzus gadus, ir dzÄ«vs, attÄ«stÄs un pelna naudu, tad visticamÄk ziÅojumÄ nebÅ«s daudz brÄ«dinÄjumu, kas norÄda uz kritiskiem defektiem. Citiem vÄrdiem sakot, kritiskÄs kļūdas jau ir novÄrstas tÄ vai citÄdi, izmantojot dÄrgÄkas metodes vai pateicoties klientu atsauksmÄm. AttiecÄ«gi visu, ko analizators Å”obrÄ«d atrod, var uzskatÄ«t par tehnisko parÄdu, ko nav praktiski mÄÄ£inÄt nekavÄjoties novÄrst.
Varat norÄdÄ«t, ka PVS-Studio Å”os brÄ«dinÄjumus paÅ”laik uzskata par neatbilstoÅ”iem (saglabÄjiet tehnisko parÄdu vÄlÄkam laikam), un tas vairs nerÄdÄ«s. Analizators izveido Ä«paÅ”u failu, kurÄ tiek saglabÄta informÄcija par kļūdÄm, kas vÄl nav interesantas. Un tagad PVS-Studio izdos brÄ«dinÄjumus tikai par jaunu vai mainÄ«tu kodu. TurklÄt tas viss tiek Ä«stenots gudri. Ja, piemÄram, avota koda faila sÄkumam tiek pievienota tukÅ”a rinda, analizators saprot, ka patiesÄ«bÄ nekas nav mainÄ«jies, un turpinÄs klusÄt. Å o iezÄ«mÄÅ”anas failu var ievietot versiju kontroles sistÄmÄ. Fails ir liels, taÄu tÄ nav problÄma, jo nav jÄgas to bieži uzglabÄt.
Tagad visi programmÄtÄji redzÄs brÄ«dinÄjumus, kas saistÄ«ti tikai ar jaunu vai mainÄ«tu kodu. TÄdÄjÄdi jÅ«s varat sÄkt lietot analizatoru, kÄ saka, no nÄkamÄs dienas. Un vÄlÄk varat atgriezties pie tehniskÄ parÄda, pakÄpeniski labot kļūdas un konfigurÄt analizatoru.
TÄtad pirmÄ problÄma ar analizatora ievieÅ”anu lielÄ vecÄ projektÄ ir atrisinÄta. Tagad izdomÄsim, ko darÄ«t ar tehnisko parÄdu.
Kļūdu labojumi un pÄrveidojumi
VisvienkÄrÅ”ÄkÄ un dabiskÄkÄ lieta ir atlicinÄt kÄdu laiku, lai analizÄtu masveidÄ apspiestos analizatora brÄ«dinÄjumus un pakÄpeniski tos risinÄtu. Kaut kur jÄlabo koda kļūdas, kaut kur jÄreaÄ£Ä, lai pateiktu analizatoram, ka kods nav problemÄtisks. VienkÄrÅ”s piemÄrs:
if (a = b)
LielÄkÄ daļa C++ kompilatoru un analizatoru sÅ«dzas par Å”Ädu kodu, jo pastÄv liela varbÅ«tÄ«ba, ka viÅi patieÅ”Äm vÄlÄjÄs rakstÄ«t (a == b). Bet ir neizteikta vienoÅ”anÄs, un tas parasti tiek atzÄ«mÄts dokumentÄcijÄ, ka, ja ir papildu iekavas, tad tiek uzskatÄ«ts, ka programmÄtÄjs ir apzinÄti uzrakstÄ«jis Å”Ädu kodu, un nav nepiecieÅ”ams lamÄties. PiemÄram, PVS-Studio diagnostikas dokumentÄcijÄ V559 (CWE-481) ir skaidri rakstÄ«ts, ka Å”Äda rinda tiks uzskatÄ«ta par pareizu un droÅ”u:
if ((a = b))
VÄl viens piemÄrs. Vai tas ir aizmirsts Å”ajÄ C++ kodÄ? pÄrtraukums vai ne?
case A:
foo();
case B:
bar();
break;
PVS-Studio analizators Å”eit izdos brÄ«dinÄjumu V796 (CWE-484). TÄ var nebÅ«t kļūda, un tÄdÄ gadÄ«jumÄ jums vajadzÄtu dot parsÄtÄjam mÄjienu, pievienojot atribÅ«tu [[kritums]] vai piemÄram __atribÅ«ts__((kritums)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;
Var teikt, ka Å”Ädas koda izmaiÅas neizlabo kļūdu. JÄ, tÄ ir taisnÄ«ba, taÄu tÄ sniedz divas noderÄ«gas lietas. PirmkÄrt, analizatora ziÅojums atbrÄ«vojas no viltus pozitÄ«viem rezultÄtiem. OtrkÄrt, kods kļūst saprotamÄks cilvÄkiem, kas iesaistÄ«ti tÄ uzturÄÅ”anÄ. Un tas ir ļoti svarÄ«gi! Tikai tÄpÄc ir vÄrts veikt nelielus pÄrveidojumus, lai kods bÅ«tu skaidrÄks un vieglÄk uzturÄjams. TÄ kÄ analizators nesaprot, vai "pÄrtraukums" ir vajadzÄ«gs vai nÄ, tas bÅ«s neskaidrs arÄ« citiem programmÄtÄjiem.
Papildus kļūdu labojumiem un pÄrveidojumiem varat Ä«paÅ”i izslÄgt acÄ«mredzami nepatiesus analizatora brÄ«dinÄjumus. Dažas nebÅ«tiskas diagnostikas var atspÄjot. PiemÄram, kÄds domÄ, ka brÄ«dinÄjumi ir bezjÄdzÄ«gi V550 par peldoÅ”o/dubulto vÄrtÄ«bu salÄ«dzinÄÅ”anu. Un daži tos klasificÄ kÄ svarÄ«gus un izpÄtes vÄrtus [7]. Kuri brÄ«dinÄjumi tiek uzskatÄ«ti par atbilstoÅ”iem un kuri nÄ, ir jÄizlemj izstrÄdes komandai.
Ir arÄ« citi veidi, kÄ novÄrst viltus brÄ«dinÄjumus. PiemÄram, makro marÄ·Äjums tika minÄts iepriekÅ”. Tas viss ir sÄ«kÄk aprakstÄ«ts dokumentÄcijÄ. VissvarÄ«gÄkais ir saprast, ka, pakÄpeniski un sistemÄtiski pieejot darbam ar viltus pozitÄ«viem rezultÄtiem, ar tiem nav nekÄ slikta. LielÄkÄ daļa neinteresantu brÄ«dinÄjumu pÄc konfigurÄÅ”anas pazÅ«d, un paliek tikai tÄs vietas, kuras patieÅ”Äm prasa rÅ«pÄ«gu izpÄti un dažas izmaiÅas kodÄ.
TÄpat mÄs vienmÄr palÄ«dzam saviem klientiem izveidot PVS-Studio, ja rodas kÄdas grÅ«tÄ«bas. TurklÄt bija gadÄ«jumi, kad mÄs paÅ”i novÄrsÄm viltus brÄ«dinÄjumus un izlabojÄm kļūdas [8]. Katram gadÄ«jumam nolÄmu pieminÄt, ka ir iespÄjama arÄ« Ŕī paplaÅ”inÄtÄs sadarbÄ«bas iespÄja :).
Sprūdrata metode
Ir vÄl viena interesanta pieeja, lai pakÄpeniski uzlabotu koda kvalitÄti, novÄrÅ”ot statiskÄ analizatora brÄ«dinÄjumu. BÅ«tÄ«ba ir tÄda, ka brÄ«dinÄjumu skaits var tikai samazinÄties.
Tiek reÄ£istrÄts statiskÄ analizatora izdoto brÄ«dinÄjumu skaits. KvalitÄtes vÄrti ir konfigurÄti tÄ, ka tagad var ievadÄ«t tikai kodu, kas nepalielina darbÄ«bu skaitu. RezultÄtÄ trauksmes signÄlu skaita pakÄpeniskas samazinÄÅ”anas process sÄkas ar analizatora regulÄÅ”anu un kļūdu laboÅ”anu.
Pat ja cilvÄks vÄlas nedaudz krÄpties un nolemj iet garÄm kvalitÄtes vÄrtiem, nevis likvidÄjot brÄ«dinÄjumus savÄ jaunajÄ kodÄ, bet gan uzlabojot veco treÅ”Äs puses kodu, tas nav biedÄjoÅ”i. TomÄr sprÅ«drats griežas vienÄ virzienÄ, un pakÄpeniski defektu skaits samazinÄsies. Pat ja cilvÄks nevÄlas pats labot savus jaunos defektus, viÅam tik un tÄ bÅ«s kaut kas jÄuzlabo blakus esoÅ”ajÄ kodÄ. KÄdÄ brÄ«dÄ« vienkÄrÅ”ie veidi, kÄ samazinÄt brÄ«dinÄjumu skaitu, beidzas, un pienÄk brÄ«dis, kad tiks novÄrstas Ä«stas kļūdas.