ProHoster > Blogs > Administrācija > Kā ieviest statiskā koda analizatoru mantotā projektā, nedemotivējot komandu

Kā ieviest statiskā koda analizatoru mantotā projektā, nedemotivējot komandu

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.

Kā ieviest statiskā koda analizatoru mantotā projektā, nedemotivējot komandu
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.

Kā ieviest statiskā koda analizatoru mantotā projektā, nedemotivējot komandu
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.

Kā ieviest statiskā koda analizatoru mantotā projektā, nedemotivējot komandu

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.

Å Ä« metodika ir sÄ«kāk aprakstÄ«ta ļoti interesantā Ivana Ponomareva rakstā "Ieviesiet procesā statisko analÄ«zi, nevis izmantojiet to kļūdu atraÅ”anai", kuru iesaku izlasÄ«t ikvienam, kas interesējas par koda kvalitātes uzlaboÅ”anu.

Raksta autoram ir arÄ« ziņojums par Å”o tēmu: "Nepārtraukta statiskā analÄ«ze".

Secinājums

Ceru, ka pēc Ŕī raksta lasÄ«tāji vairāk pieņems statiskās analÄ«zes rÄ«kus un vēlēsies tos ieviest izstrādes procesā. Ja jums ir kādi jautājumi, mēs vienmēr esam gatavi padomu mÅ«su statiskā analizatora PVS-Studio lietotājiem un palÄ«dzēt tā ievieÅ”anā.

Pastāv arÄ« citas tipiskas Å”aubas par to, vai statiskā analÄ«ze patieŔām var bÅ«t ērta un noderÄ«ga. Lielāko daļu Å”o Å”aubu mēģināju kliedēt publikācijā ā€œIemesli PVS-Studio statiskā koda analizatora ievieÅ”anai izstrādes procesāā€ [9].

Paldies par uzmanību un nāc download un izmēģiniet PVS-Studio analizatoru.

Papildu saites

  1. Andrejs Karpovs. Kā es varu ātri redzēt interesantus brīdinājumus, ko PVS-Studio analizators rada C un C++ kodiem?
  2. Wikipedia. Rīsa teorēma.
  3. Andrejs Karpovs, Viktorija Hanjeva. MaŔīnmācÄ«Å”anās izmantoÅ”ana programmas pirmkoda statiskajā analÄ«zē.
  4. PVS-Studija. Dokumentācija. Papildu diagnostikas iestatījumi.
  5. Andrejs Karpovs. PVS-Studio analizatora raksturlielumi, izmantojot EFL Core bibliotēku piemēru, 10-15% kļūdaini pozitīvi.
  6. PVS-Studija. Dokumentācija. Analizatora ziņojumu masveida apspieÅ”ana.
  7. Ivans AndrjaÅ”ins. Par to, kā mēs pārbaudÄ«jām statisko analÄ«zi mÅ«su rentgenstaru endovaskulārās Ä·irurÄ£ijas izglÄ«tojoŔā simulatora projektā.
  8. Pāvels Eremejevs, Svjatoslavs Razmislovs. Kā PVS-Studio komanda uzlaboja Unreal Engine kodu.
  9. Andrejs Karpovs. Iemesli statiskā koda analizatora PVS-Studio ievieŔanai izstrādes procesā.

Kā ieviest statiskā koda analizatoru mantotā projektā, nedemotivējot komandu

Ja vēlaties dalÄ«ties ar Å”o rakstu ar angliski runājoÅ”u auditoriju, lÅ«dzu, izmantojiet tulkoÅ”anas saiti: Andrejs Karpovs. Kā mantotajā projektā ieviest statiskā koda analizatoru un neatturēt komandu.

Avots: www.habr.com

Pievieno komentāru