🥇Analiza statică – de la întâlnirea cu ea până la integrare

Statutul de a scăpa de revizuirile interminabile de cod sau de depanare te face, din când în când, să te întrebi cum să îți faci viața mai simplă. Și, după ce ai căutat puțin, sau poate ai dat peste el din întâmplare, poți descoperi expresia magică: "Analiza statică". Să vedem ce înseamnă aceasta și cum poate interacționa cu proiectul tău.

Așadar, dacă scrii în orice limbaj modern, atunci, chiar fără să îți dai seama, l-ai trecut printr-un analizator static. Asta pentru că orice compilator modern oferă, chiar dacă foarte puține, o serie de avertizări despre problemele potențiale din cod. De exemplu, atunci când compilezi cod C++ în Visual Studio, poți vedea următoarele:

În această ieșire vedem că variabila var nu a fost folosită nicăieri în funcție. Deci, practic, ai folosit aproape întotdeauna un simplu analizator static de cod. Cu toate acestea, spre deosebire de analizatoarele profesionale, cum ar fi Coverity, Klocwork sau PVS-Studio, avertizările furnizate de compilator pot indica doar un spectru restrâns de probleme.

Dacă nu știi sigur ce este analiza statică și cum să o implementezi, . Stocarea de date ar trebui să fie non-locală, pentru ca Kubernetes să poată alege mai flexibil un nou nod după repornire sau relocare., pentru a te familiariza mai detaliat cu această metodologie.

De ce este necesară analiza statică?

Pe scurt: pentru a accelera și simplifica.

Analiza statică permite identificarea unei mulțimi de probleme diferite în cod: de la utilizarea incorectă a construcțiilor limbajului, până la greșeli de tipar. De exemplu, în loc de

auto x = obj.x;
auto y = obj.y;
auto z = obj.z;

ai scris următorul cod:

auto x = obj.x;
auto y = obj.y;
auto z = obj.x;

După cum vezi, în ultima linie a apărut o greșeală de tipar. De exemplu, PVS-Studio oferă următorul avertisment:

V537 Consideră revizuirea corectitudinii utilizării elementului 'y'.

Dacă vrei să testezi această greșeală, atunci încearcă exemplul pregătit pe Compiler Explorer: *clic*.

Și, după cum îți imaginezi, nu tot timpul poți să acorzi atenție unor astfel de porțiuni de cod imediat și din această cauză poți rămâne blocat la depanare pentru o vreme bună, neștiind de ce totul funcționează atât de ciudat.

Cu toate acestea, aceasta este o greșeală evidentă. Dar ce se întâmplă dacă dezvoltatorul a scris cod suboptimal pentru că a uitat o subtilitate a limbajului? Sau chiar a comis o situație de comportament nedefinit.? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.

Aceste situații sunt exact motivul pentru care a apărut analiza statică. Este un instrument pentru dezvoltatori care le va indica diverse probleme în cod și le va explica în documentație de ce nu trebuie să scrie astfel, la ce poate duce și cum să le corecteze. Iată un exemplu despre cum poate arăta:clic*.

Mai multe erori interesante pe care le poate descoperi analizatorul pot fi găsite în articolele:

Acum, citind acest material și asigurându-vă de utilitatea analizei statice, poate doriți să o încercați în practică. Dar de unde să începeți? Cum să integrați noul instrument în proiectul existent? Și cum să familiarizați echipa cu acesta? Veți găsi răspunsuri la aceste întrebări mai jos.

Notă. Analiza statică nu înlocuiește și nu anulează o activitate atât de utilă precum revizuirile de cod. Ea completează acest proces, ajutând la observarea și corectarea erorilor tipografice, a inexactităților și a constructelor periculoase. Este mult mai productiv să ne concentrăm în timpul revizuirilor de cod pe algoritmi și claritatea codului, nu pe identificarea unei paranteze plasate greșit sau citirea funcțiilor de comparație plictisitoare.

0. Familiarizarea cu instrumentul

Totul începe cu o versiune de probă. Într-adevăr, este greu să te decizi să implementezi ceva în procesul de dezvoltare dacă nu ai văzut niciodată instrumentul în acțiune. Așadar, primul lucru pe care trebuie să-l faci este să descarci a produsului, care va funcționa timp de 14 zile în scopuri de explorare..

Ce veți învăța în această etapă:

Care sunt modalitățile de interacțiune cu analizatorul;
Este analizatorul compatibil cu mediul dumneavoastră de dezvoltare;
Ce probleme există acum în proiectele dumneavoastră.

După ce ați instalat tot ce este necesar, primul lucru pe care trebuie să-l faceți este să rulați analiza întregului proiect (Windows, Linux, macOS). În cazul PVS-Studio în Visual Studio, veți vedea o imagine asemănătoare (clickabil):

Problema este că, de obicei, proiectele cu o bază mare de cod generează o mulțime de avertizări din partea analizatoarelor statice. Nu este necesar să le corectați pe toate, deoarece proiectul dumneavoastră funcționează deja, ceea ce înseamnă că aceste probleme nu sunt critice. Cu toate acestea, puteți să vă uitați la cele mai interesante avertizări și a le corecta dacă este necesar. Pentru aceasta, este nevoie să filtrați rezultatul și să lăsați numai cele mai de încredere mesaje. În pluginul PVS-Studio pentru Visual Studio, acest lucru se face prin filtrarea pe niveluri și categorii de erori. Pentru un rezultat cât mai precis, lăsați activate doar Ridicat și General (de asemenea, clicabil):

Acestea fiind spuse, este mult mai simplu să revizuiești 178 de avertizări decât câteva mii...

În tab-uri Medium și Low se întâlnesc frecvent bune avertizări, însă în aceste categorii sunt incluse acele diagnostice care au o precizie mai mică (credibilitate). Mai multe informații despre nivelurile de avertizare și opțiunile de utilizare pe Windows pot fi găsite aici: *clic*.

După ce ați revizuit cele mai interesante erori (și le-ați corectat cu succes), este bine să filtrați avertizările rămase. Acest lucru este necesar pentru a preveni ca noi avertizări să se piardă printre cele vechi. De asemenea, analyzer-ul static este un asistent pentru programator, nu o listă de bug-uri. 🙂

1. Automatizare

După familiarizare, vine momentul setării plugin-urilor și integrării în CI. Acest lucru trebuie realizat înainte ca programatorii să înceapă utilizarea analyzer-ului static. Motivul este că programatorul poate uita să activeze analiza sau pur și simplu nu dorește. Este necesară o verificare finală a tuturor, astfel încât codul neanalizat să nu poată ajunge în ramura principală de dezvoltare.

Ce veți învăța în această etapă:

Ce opțiuni de automatizare oferă instrumentul;
Dacă analyzer-ul este compatibil cu sistemul dumneavoastră de build.

Din moment ce documentația ideală nu există, uneori este necesar să scrieți în asistență. Este normal și suntem bucuroși să vă ajutăm. 🙂

Acum, să trecem la serviciile de integrare continuă (CI). Orice analyzer poate fi integrat în acestea fără probleme serioase. Pentru aceasta, trebuie creată o etapă separată în pipeline, care se află de obicei după build și testele unitare. Acest lucru se face prin diverse utilitare de linie de comandă. De exemplu, PVS-Studio oferă următoarele utilitare:

PVS-Studio_Cmd.exe (analiza soluțiilor, proiecte C#, C++ pe Windows)
CLMonitor.exe (monitorizarea compilării)
pvs-studio-analyzer (analiza proiectelor C++ pe Linux / macOS)
pvs-studio-dotnet (analiza soluțiilor, proiecte C# pe Linux / macOS)
pvs-studio.jar (analiza proiectelor Java)
PlogConverter (convertor de fișiere de raport)

Pentru a integra analiza în CI, trebuie realizate trei lucruri:

Instalați analyzer-ul;
Rulați analiza;
Livrați rezultatele.

De exemplu, pentru a instala PVS-Studio pe Linux (bazat pe Debian), trebuie să executați comenzile următoare:

wget -q -O - https://files.viva64.com/etc/pubkey.txt 
    | sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list 
  https://files.viva64.com/etc/viva64.list
  
sudo apt-get update -qq
sudo apt-get install -qq pvs-studio

În sistemele bazate pe Windows, nu există posibilitatea de a instala analizatorul din managerul de pachete, dar există posibilitatea de a desfășura analizatorul din linia de comandă:

PVS-Studio_setup.exe /verysilent /suppressmsgboxes 
/norestart /nocloseapplications

Mai multe informații despre desfășurarea PVS-Studio în sistemele bazate pe Windows pot fi citite *aici*.

După instalare, trebuie să lansați analiza. Totuși, este recomandat să faceți acest lucru doar după ce compilarea și testele au fost finalizate. Acest lucru se datorează faptului că analiza statică necesită de obicei de două ori mai mult timp decât compilarea.

Deoarece metoda de lansare depinde de platformă și de particularitățile proiectului, voi arăta o variantă pentru C++ (Linux) ca exemplu:

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -w

Prima comandă va efectua analiza, iar a doua converteșteraportul în format text, îl va afișa pe ecran și va returna un cod de ieșire diferit de 0 în cazul în care există avertismente. Un mecanism similar este convenabil de utilizat pentru a bloca compilarea în cazul mesajelor de eroare. Totuși, puteți elimina întotdeauna flag-ul -w și nu bloca compilarea care conține avertismente.

Notă. Formatul text este inconvenient. Este adus pur și simplu ca exemplu. Rețineți un format de raport mai interesant – FullHtml. Acesta permite navigarea prin cod.

Mai multe informații despre configurarea analizei pe CI pot fi citite în articolul "PVS-Studio și Continuous Integration" (Windows) sau "Cum să configurați PVS-Studio în Travis CI" (Linux).

Bine, ați configurat funcționarea analizatorului pe serverul de construcție. Acum, dacă cineva a încărcat cod netestat, etapa de verificare va eșua și veți putea detecta problema, dar nu este foarte convenabil, deoarece este mai eficient să verificați proiectul nu după ce a avut loc fuziunea ramurilor, ci înainte, în etapa de pull request.

În general, configurarea analizei pentru pull request nu diferă semnificativ de lansarea obișnuită a analizei pe CI. Cu excepția necesității de a obține o listă a fișierelor modificate. De obicei, acestea pot fi obținute cerând diferența dintre ramuri folosind git:

git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

Acum trebuie să furnizăm analziatorului această listă de fișiere. De exemplu, în PVS-Studio, acest lucru este realizat prin intermediul unei opțiuni -S:

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log 
                            -S .pvs-pr.list

Mai multe informații despre analiza pull request-urilor pot fi găsite *aici* Chiar dacă CI-ul dumneavoastră nu se află în lista serviciilor menționate în articol, secțiunea generală dedicată teoriei acestui tip de analiză vă va fi utilă.

Configurând analiza pull request-urilor, veți putea bloca commit-urile care conțin avertismente, astfel creând o limită pe care codul nesupus verificării nu o va putea depăși.

Toate acestea sunt, fără îndoială, bune, însă ar fi util să putem vedea toate avertismentele într-un singur loc. Nu doar de la analziatorul static, ci și de la testele unității sau de la analziatorul dinamic. Pentru aceasta există diverse servicii și pluginuri. PVS-Studio, de exemplu, are un plugin pentru integrarea în SonarQube.

2. Integrarea pe mașinile dezvoltatorilor

Acum este timpul să instalăm și să configurăm analziatorul pentru utilizarea zilnică în dezvoltare. Până acum ați avut ocazia să vă familiarizați cu majoritatea metodelor de lucru, astfel că aceasta poate fi considerată cea mai simplă parte.

Cel mai simplu mod – dezvoltatorii pot instala singuri analziatorul necesar. Totuși, acest lucru va dura mult timp și îi va distrage de la dezvoltare, așa că puteți automatiza acest proces, folosind un installer și opțiunile necesare. Pentru PVS-Studio există diverse opțiuni pentru instalarea automată. Totuși, există mereu manageri de pachete, de exemplu, Chocolatey (Windows), Homebrew (macOS) sau zeci de opțiuni pentru Linux.

Apoi, va trebui să instalați pluginurile necesare, de exemplu, pentru Visual Studio, IDEA, Rider etc.

3. Utilizarea zilnică

În această etapă este timpul să spunem câteva cuvinte despre modurile de accelerare a funcționării analziatorului în utilizarea zilnică. O analiză completă a întregului proiect durează foarte mult, dar cât de des modificăm codul deodată în întregul proiect? Puțin probabil să existe o refactorizare atât de mare care să afecteze întreaga bază de cod odată. Numărul fișierelor modificate deodată rar depășește o duzină, așa că merită să le analizăm. Pentru o astfel de situație există modul de analiză incrementală. Nu vă speriați, nu este un alt instrument. Acesta este un mod special care permite analizarea doar a fișierelor modificate și a dependențelor acestora, iar acest lucru se întâmplă automat după compilare, dacă lucrați într-o IDE cu pluginul instalat.

În cazul în care analizatorul descoperă probleme în codul recent modificat, acesta va informa de sine stătător. De exemplu, PVS-Studio vă va anunța printr-o notificare:

Desigur, nu este suficient să le spunem dezvoltatorilor să folosească instrumentul. Trebuie să le explicăm ce este și cum funcționează. Iată, de exemplu, articole despre un ghid rapid pentru PVS-Studio, dar astfel de tutoriale le puteți găsi pentru orice instrument preferat:

Aceste articole oferă informațiile necesare pentru utilizarea de zi cu zi și nu consumă mult timp. 🙂

Încă din etapa de familiarizare cu instrumentul, am eliminat foarte multe avertismente în timpul uneia dintre primele runde de utilizare. Din păcate, analizatorii statici nu sunt perfecți, astfel că, din când în când, generează alarme false. De obicei, este ușor să le suprimați, de exemplu în pluginul PVS-Studio pentru Visual Studio, este suficient să apăsați un buton:

Cu toate acestea, nu doar le puteți suprima. De exemplu, puteți anunța suportul despre o problemă existentă. Dacă alerta falsă poate fi rezolvată, în actualizările viitoare puteți observa că, de fiecare dată, devin din ce în ce mai puține alarme false specifice bazei dumneavoastră de cod.

După integrare

Iată că am trecut prin toate etapele integrării analizei statice în procesul de dezvoltare. În ciuda importanței configurării unor astfel de instrumente pe CI, cel mai important loc de rulare este, de fapt, computerul dezvoltatorului. Fiindcă analizatorul static nu este un judecător care vă spune de la distanță că codul nu este bun. Din contră, este un asistent care vă oferă sugestii atunci când sunteți obosiți și vă reamintește dacă ați uitat ceva.

Adevărul este că, fără utilizarea regulată, analiza statică va fi puțin probabil să simplifice semnificativ dezvoltarea. Cea mai mare utilizare a sa pentru dezvoltatori constă nu doar în identificarea porțiunilor complicate și controversate de cod, ci și în descoperirea lor timpurie. Să recunoaștem, a descoperi o problemă atunci când modificările au fost trimise pentru testare este nu doar neplăcut, ci și foarte consumator de timp. Analiza statică, atunci când este utilizată regulat, examinează fiecare modificare direct pe computerul dumneavoastră și semnalează locurile suspecte în timpul lucrului la cod.

Și dacă dumneavoastră sau colegii dumneavoastră încă nu sunteți siguri dacă merită să implementați un analizator, vă propun să citiți acum articolul "Motive pentru a implementa un analizator static de cod PVS-Studio în procesul de dezvoltare". Acesta analizează temerile obișnuite ale dezvoltatorilor că analiza statică le va consuma timpul și așa mai departe.

Dacă doriți să împărtășiți acest articol cu o audiență vorbitoare de engleză, vă rog să folosiți linkul către traducere: Maxim Zvyagintsev. Analiza Statică: De la începerea utilizării până la integrare.

Sursa: habr.com