Cansat de la revisió o depuració de codi interminables, de vegades penses com simplificar-te la vida. I després de buscar una mica, o ensopegar-hi accidentalment, podeu veure la frase màgica: "Anàlisi estàtica". Vegem què és i com pot interactuar amb el vostre projecte.
De fet, si escrius en qualsevol llengua moderna, aleshores, sense ni tan sols adonar-te'n, ho passes a través d'un analitzador estàtic. El fet és que qualsevol compilador modern proporciona, encara que un petit conjunt d'avisos sobre problemes potencials en el codi. Per exemple, quan compileu codi C++ a Visual Studio, podeu veure el següent:
En aquesta sortida veiem que la variable var mai s'ha utilitzat en cap lloc de la funció. Així que, en realitat, gairebé sempre utilitzeu un senzill analitzador de codi estàtic. No obstant això, a diferència dels analitzadors professionals com Coverity, Klocwork o PVS-Studio, els avisos proporcionats pel compilador només poden indicar una petita gamma de problemes.
Si no sabeu del cert què és l'anàlisi estàtica i com implementar-la, per aprendre més sobre aquesta metodologia.
Per què necessiteu una anàlisi estàtica?
En poques paraules: acceleració i simplificació.
L'anàlisi estàtica us permet trobar molts problemes diferents al codi: des de l'ús incorrecte de les construccions del llenguatge fins a errors d'ortografia. Per exemple, en lloc de
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;Heu escrit el codi següent:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Com podeu veure, hi ha una errada a l'última línia. Per exemple, PVS-Studio emet l'advertiment següent:
Penseu en revisar la correcció de l'ús de l'element "y".
Si voleu ficar les vostres mans en aquest error, proveu un exemple ja fet a Compiler Explorer: **.
I com enteneu, no sempre és possible parar atenció a aquestes seccions de codi immediatament i, per això, us podeu asseure a depurar durant una bona hora, preguntant-vos per què tot funciona tan estrany.
Tanmateix, això és clarament un error. Què passaria si el desenvolupador escrivia un codi subòptim perquè s'oblidava d'alguna subtilesa del llenguatge? O fins i tot ho va permetre al codi ? Malauradament, aquests casos són completament habituals i la major part del temps es dedica a depurar codis que funcionen específicament que conté errors ortogràfics, errors típics o comportaments no definits.
És per a aquestes situacions on va aparèixer l'anàlisi estàtica. Es tracta d'un assistent per al desenvolupador que assenyalarà diversos problemes al codi i explicarà a la documentació per què no és necessari escriure d'aquesta manera, què pot comportar i com solucionar-ho. Aquí teniu un exemple de com podria semblar: **.
Podeu trobar errors més interessants que l'analitzador pot detectar als articles:
Ara que heu llegit aquest material i esteu convençuts dels beneficis de l'anàlisi estàtica, potser voldreu provar-lo. Però per on començar? Com integrar una nova eina al vostre projecte actual? I com presentar-li l'equip? Trobareu respostes a aquestes preguntes a continuació.
Nota. L'anàlisi estàtica no substitueix ni cancel·la una cosa tan útil com les revisions de codi. Complementa aquest procés, ajudant a detectar i corregir errors d'ortografia, inexactituds i dissenys perillosos per endavant. És molt més productiu centrar-se en les revisions del codi sobre algorismes i claredat del codi, en lloc de buscar un parèntesi o un parèntesi fora de lloc. .
0. Conèixer l'eina
Tot comença amb una versió de prova. De fet, és difícil decidir implementar alguna cosa en el procés de desenvolupament si mai abans no heu vist l'eina en directe. Per tant, el primer que heu de fer és descarregar .
Què aprendràs en aquesta etapa:
- Quines són les maneres d'interactuar amb l'analitzador;
- L'analitzador és compatible amb el vostre entorn de desenvolupament?
- Quins problemes hi ha actualment en els vostres projectes?
Després d'haver instal·lat tot el que necessiteu, el primer que heu de fer és fer una anàlisi de tot el projecte (, , ). En el cas de PVS-Studio a Visual Studio, veureu una imatge similar (a la qual es pot fer clic):
El fet és que els analitzadors estàtics solen emetre un gran nombre d'avisos per a projectes amb una gran base de codi. No cal arreglar-los tots, ja que el vostre projecte ja funciona, la qual cosa significa que aquests problemes no són crítics. Tanmateix, tu i corregir-los si cal. Per fer-ho, cal filtrar la sortida i deixar només els missatges més fiables. Al connector PVS-Studio per a Visual Studio, això es fa filtrant per nivells d'error i categories. Per obtenir la sortida més precisa, deixeu-ho només alt и General (també es pot fer clic):
De fet, 178 avisos són molt més fàcils de veure que diversos milers...
En pestanyes mitjà и Sota Sovint hi ha bons avisos, però aquestes categories inclouen aquells diagnòstics que tenen menys precisió (fiabilitat). Podeu trobar més informació sobre els nivells d'avís i les opcions per treballar amb Windows aquí: **.
Val la pena haver revisat amb èxit els errors més interessants (i corregits amb èxit). . Això és necessari perquè els nous avisos no es perdin entre els antics. A més, un analitzador estàtic és un assistent per al programador, i no una llista d'errors. 🙂
1. Automatització
Després de conèixer-se, és hora de configurar els connectors i integrar-se a CI. Això s'ha de fer abans que els programadors comencin a utilitzar l'analitzador estàtic. El fet és que el programador pot oblidar-se d'habilitar l'anàlisi o no vol fer-ho gens. Per fer-ho, heu de fer una comprovació final de tot perquè el codi no provat no entri a la branca de desenvolupament general.
Què aprendràs en aquesta etapa:
- Quines opcions d'automatització ofereix l'eina;
- L'analitzador és compatible amb el vostre sistema de muntatge?
Com que la documentació perfecta no existeix, de vegades cal escriure . Això és normal i estem encantats d'ajudar-te. 🙂
Ara passem als serveis d'integració contínua (CI). Qualsevol analitzador es pot implementar en ells sense problemes greus. Per fer-ho, heu de crear una etapa separada del pipeline, que normalment es troba després de les proves de compilació i unitats. Això es fa mitjançant diverses utilitats de consola. Per exemple, PVS-Studio proporciona les utilitats següents:
- (anàlisi de solucions, projectes C#, C++ a Windows)
- (vigilància de la compilació)
- (anàlisi de projectes C++ a Linux / macOS)
- (anàlisi de solucions, projectes C# a Linux / macOS)
- (anàlisi de projectes Java)
- (conversor de fitxers d'informes)
Per integrar l'anàlisi a CI, heu de fer tres coses:
- Instal·leu l'analitzador;
- Executar anàlisi;
- Donar resultats.
Per exemple, per instal·lar PVS-Studio a Linux (base Debian), heu d'executar les ordres següents:
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-studioEn sistemes amb Windows, no hi ha manera d'instal·lar l'analitzador des del gestor de paquets, però és possible desplegar l'analitzador des de la línia d'ordres:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsPodeu obtenir més informació sobre el desplegament de PVS-Studio en sistemes amb Windows **.
Després de la instal·lació, heu d'executar l'anàlisi directament. Tanmateix, es recomana fer-ho només després de la compilació i les proves. Això es deu al fet que l'anàlisi estàtica sol trigar el doble que la compilació.
Com que el mètode de llançament depèn de la plataforma i les característiques del projecte, mostraré l'opció per a C++ (Linux) com a exemple:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wLa primera comanda realitzarà l'anàlisi, i la segona converteix l'informe en format de text, el mostra a la pantalla i retorna un codi de retorn diferent de 0 si hi ha avisos. Un mecanisme com aquest es pot utilitzar convenientment per bloquejar una compilació quan hi ha missatges d'error. Tanmateix, sempre podeu eliminar la bandera -w i no bloquegeu un conjunt que contingui advertències.
Nota. El format del text és incòmode. Es proporciona simplement com a exemple. Preste atenció a un format d'informe més interessant: FullHtml. Et permet navegar pel codi.
Podeu llegir més sobre com configurar l'anàlisi de CI a l'article "" (Windows) o "" (Linux).
D'acord, heu configurat l'analitzador al servidor de compilació. Ara, si algú ha penjat codi no provat, l'etapa de verificació fallarà i podreu detectar el problema, però, això no és del tot convenient, ja que és més eficient comprovar el projecte no després que les branques s'hagin fusionat, sinó abans, en l'etapa de sol·licitud d'extracció A.
En general, configurar una anàlisi de sol·licitud d'extracció no és molt diferent del llançament habitual d'una anàlisi sobre CI. Excepte la necessitat d'obtenir una llista dels fitxers modificats. Normalment es poden obtenir consultant les diferències entre branques mitjançant git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listAra heu de passar aquesta llista de fitxers a l'analitzador com a entrada. Per exemple, a PVS-Studio això s'implementa utilitzant la bandera -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listPodeu obtenir més informació sobre com analitzar les sol·licituds d'extracció **. Encara que el vostre CI no estigui a la llista de serveis esmentats a l'article, trobareu útil la secció general dedicada a la teoria d'aquest tipus d'anàlisi.
En configurar l'anàlisi de les sol·licituds d'extracció, podeu bloquejar les confirmacions que continguin advertències, creant així un límit que el codi no provat no pot travessar.
Sens dubte, tot això és bo, però m'agradaria poder veure tots els avisos en un sol lloc. No només de l'analitzador estàtic, sinó també de les proves unitàries o des de l'analitzador dinàmic. Hi ha diversos serveis i complements per a això. PVS-Studio, per exemple, té .
2. Integració en màquines desenvolupadores
Ara és el moment d'instal·lar i configurar l'analitzador per al desenvolupament diari. En aquest moment ja us heu familiaritzat amb la majoria de les maneres de treballar, així que aquesta es pot anomenar la part més fàcil.
Com a opció més senzilla, els desenvolupadors poden instal·lar ells mateixos l'analitzador necessari. Tanmateix, això trigarà molt de temps i els distreu del desenvolupament, de manera que podeu automatitzar aquest procés mitjançant un instal·lador i els senyaladors necessaris. Per a PVS-Studio hi ha diversos . Tanmateix, sempre hi ha gestors de paquets, per exemple, Chocolatey (Windows), Homebrew (macOS) o desenes d'opcions per a Linux.
Aleshores haureu d'instal·lar els connectors necessaris, per exemple per , , etcètera...
3. Ús diari
En aquesta etapa, és hora de dir algunes paraules sobre les maneres d'accelerar l'analitzador durant l'ús diari. Una anàlisi completa de tot el projecte requereix molt de temps, però amb quina freqüència canviem el codi al llarg de tot el projecte alhora? Gairebé no hi ha cap refactorització que sigui tan gran que afecti immediatament tota la base de codi. El nombre de fitxers que es canvien alhora rarament supera la dotzena, de manera que té sentit analitzar-los. Per a una situació així n'hi ha . Simplement no us alarmeu, aquesta no és una altra eina. Aquest és un mode especial que us permet analitzar només els fitxers modificats i les seves dependències, i això passa automàticament després de la creació si esteu treballant en un IDE amb el connector instal·lat.
Si l'analitzador detecta problemes en el codi canviat recentment, ho informarà de manera independent. Per exemple, PVS-Studio us informarà sobre això mitjançant una alerta:
Per descomptat, no n'hi ha prou amb dir als desenvolupadors que utilitzin l'eina. Hem de dir-los d'alguna manera què és i com és. Aquí, per exemple, hi ha articles sobre un inici ràpid per a PVS-Studio, però podeu trobar tutorials similars per a qualsevol eina que preferiu:
Aquests articles proporcionen tota la informació necessària per a l'ús diari i no necessiten gaire temps. 🙂
Fins i tot en l'etapa de conèixer l'eina, vam suprimir molts avisos durant un dels primers llançaments. Malauradament, els analitzadors estàtics no són perfectes, així que de tant en tant donen falsos positius. Normalment és fàcil suprimir-los, per exemple, al connector PVS-Studio per a Visual Studio, només cal que feu clic a un botó:
Tanmateix, podeu fer més que suprimir-los. Per exemple, podeu informar d'un problema al servei d'assistència. Si es pot corregir el fals positiu, en futures actualitzacions podreu notar que cada cop hi ha menys falsos positius específics per a la vostra base de codi.
Després de la integració
Així doncs, hem passat per totes les etapes d'integració de l'anàlisi estàtica en el procés de desenvolupament. Malgrat la importància de configurar aquestes eines a CI, el lloc més important per executar-les és l'ordinador del desenvolupador. Al cap i a la fi, un analitzador estàtic no és un jutge que digui en algun lloc lluny de tu que el codi no és bo. Al contrari, és un assistent que et diu si estàs cansat i et recorda si has oblidat alguna cosa.
És cert que sense un ús regular, és poc probable que l'anàlisi estàtica simplifiqui significativament el desenvolupament. Al cap i a la fi, el seu principal benefici per a un desenvolupador no rau tant en la recerca de seccions de codi complexes i controvertides, sinó en la seva detecció precoç. Accepteu que descobrir un problema després d'haver enviat les edicions a prova no només és desagradable, sinó que també requereix molt de temps. L'anàlisi estàtica, quan s'utilitza regularment, analitza tots els canvis directament a l'ordinador i informa de llocs sospitosos mentre es treballa amb el codi.
I si vostè o els seus companys encara no esteu segurs de si val la pena implementar l'analitzador, us suggereixo que ara comenceu a llegir l'article "". Aborda les preocupacions típiques dels desenvolupadors que l'anàlisi estàtica els ocuparà temps i així successivament.
Si voleu compartir aquest article amb un públic de parla anglesa, utilitzeu l'enllaç de traducció: Maxim Zvyagintsev. .
Font: www.habr.com