Staattisen koodin analysaattorin kokeileminen on helppoa. Mutta sen toteuttaminen, etenkin suuren vanhan projektin kehittämisessä, vaatii taitoa. Väärin tehtynä analysaattori voi lisätä työtä, hidastaa kehitystä ja demotivoida tiimiä. Puhutaanpa lyhyesti siitä, kuinka staattisen analyysin integrointia kehitysprosessiin lähestytään oikein ja aletaan käyttää sitä osana CI/CD:tä.
Esittely
Äskettäin huomioni kiinnitettiin julkaisuun "". Toisaalta tämä on hyvä artikkeli, johon kannattaa tutustua. Toisaalta minusta näyttää siltä, että se ei vieläkään anna täydellistä vastausta siihen, kuinka staattinen analyysi voidaan toteuttaa kivuttomasti projektissa, jossa on paljon Artikkelissa sanotaan, että Voit hyväksyä teknisen velan ja työstää vain uutta koodia, mutta ei ole vastausta mitä tehdä tälle tekniselle velalle myöhemmin.
PVS-Studio-tiimimme tarjoaa näkemyksensä tästä aiheesta. Katsotaanpa, kuinka staattisen koodin analysaattorin käyttöönoton ongelma syntyy, kuinka tämä ongelma voidaan ratkaista ja kuinka tekninen velka voidaan poistaa kivuttomasti vähitellen.
Ongelmat
Staattisen analysaattorin käynnistäminen ja toiminnan näkeminen ei yleensä ole vaikeaa []. Saatat nähdä koodissa mielenkiintoisia virheitä tai jopa pelottavia mahdollisia haavoittuvuuksia. Voit jopa korjata jotain, mutta sitten monet ohjelmoijat luovuttavat.
Kaikki staattiset analysaattorit tuottavat vääriä positiivisia tuloksia. Tämä on staattisen koodin analyysimenetelmän ominaisuus, eikä sille voida tehdä mitään. Yleisesti ottaen tämä on ratkaisematon ongelma, kuten Ricen lause vahvistaa []. Koneoppimisalgoritmit eivät myöskään auta []. Vaikka henkilö ei aina voi kertoa, onko tämä tai tuo koodi väärin, sinun ei pitäisi odottaa tätä ohjelmalta :).
Väärät positiiviset tulokset eivät ole ongelma, jos staattinen analysaattori on jo määritetty:
- Epäolennaiset sääntöjoukot poistettu käytöstä;
- Jotkut epäolennaiset diagnoosit on poistettu käytöstä;
- Jos puhumme C:stä tai C++:sta, niin makrot merkitään, jotka sisältävät tiettyjä rakenteita, jotka aiheuttavat turhia varoituksia jokaiseen paikkaan, jossa tällaisia makroja käytetään;
- Omat toiminnot on merkitty, jotka suorittavat samanlaisia toimintoja kuin järjestelmätoiminnot (oma analogi muisti tai printf) [];
- Väärät positiiviset estetään erityisesti kommentteja käyttämällä;
- Ja niin edelleen.
Tässä tapauksessa voimme odottaa alhaisen väärän positiivisen prosentin, noin 10-15 % []. Toisin sanoen 9 analysaattorin varoituksesta 10:stä osoittaa todellisen ongelman koodissa tai ainakin "voimakkaalle haisevalle koodille". Samaa mieltä, tämä skenaario on erittäin miellyttävä, ja analysaattori on ohjelmoijan todellinen ystävä.
Todellisuudessa isossa projektissa lähtökuva on täysin erilainen. Analysaattori antaa satoja tai tuhansia varoituksia vanhasta koodista. On mahdotonta ymmärtää nopeasti, mitkä näistä varoituksista ovat merkityksellisiä ja mitkä eivät. On järjetöntä istua alas ja alkaa käsitellä kaikkia näitä varoituksia, koska päätyö tässä tapauksessa pysähtyy päiviksi tai viikoiksi. Tyypillisesti joukkueella ei ole varaa tällaiseen skenaarioon. Tulee myös valtava määrä eroja, jotka pilaavat muutoshistorian. Ja niin monien koodin fragmenttien nopea massamuokkaus johtaa väistämättä uusiin kirjoitusvirheisiin ja virheisiin.
Ja mikä tärkeintä, tällaisella varoitusten torjunnalla ei ole mitään järkeä. Samaa mieltä siitä, että koska projekti on toiminut menestyksekkäästi useiden vuosien ajan, suurin osa sen kriittisistä virheistä on jo korjattu. Kyllä, nämä korjaukset olivat erittäin kalliita, ne piti korjata, ne saivat negatiivista palautetta virheistä ja niin edelleen. Staattinen analysaattori auttaisi korjaamaan monet näistä virheistä koodausvaiheessa nopeasti ja edullisesti. Mutta tällä hetkellä, tavalla tai toisella, nämä virheet on korjattu, ja analysaattori havaitsee pääasiassa ei-kriittisiä virheitä vanhasta koodista. Tätä koodia ei saa käyttää, sitä voidaan käyttää hyvin harvoin, eikä siinä oleva virhe välttämättä johda havaittaviin seurauksiin. Ehkä jossain napin varjo on väärän värinen, mutta tämä ei häiritse ketään tuotteen käyttöä.
Tietysti pienetkin virheet ovat silti virheitä. Ja joskus virhe voi kätkeä todellisen haavoittuvuuden. Kaikesta luopuminen ja päivien/viikkojen viettäminen puutteiden kanssa, jotka tuskin ilmenevät, näyttää kuitenkin kyseenalaiselta ajatukselta.
Ohjelmoijat katsovat, katsovat, katsovat kaikkia näitä varoituksia vanhasta toimivasta koodista... Ja he ajattelevat: voimme tehdä ilman staattista analyysiä. Lähdetään kirjoittamaan uusia hyödyllisiä toimintoja.
Omalla tavallaan he ovat oikeassa. He ajattelevat, että ensin heidän on jotenkin päästävä eroon kaikista näistä varoituksista. Vain silloin he voivat hyötyä koodianalysaattorin säännöllisestä käytöstä. Muuten uudet varoitukset vain hukkuvat vanhoihin, eikä kukaan kiinnitä niihin huomiota.
Tämä on sama analogia kuin kääntäjän varoitusten kanssa. Ei turhaan suositella kääntäjien varoitusten määrän pitämistä 0:ssa. Jos varoituksia on 1000, niin kun varoituksia on 1001, siihen ei kukaan kiinnitä huomiota, eikä ole selvää, mistä tätä uusinta varoitusta etsiä.
Pahinta tässä tarinassa on, jos joku ylhäältä tällä hetkellä pakottaa sinut käyttämään staattista koodianalyysiä. Tämä vain demotivoi tiimiä, koska heidän näkökulmastaan tulee lisää byrokratiaa, joka vain häiritsee. Kukaan ei katso analysaattorin raportteja, ja kaikki käyttö tapahtuu vain "paperilla". Nuo. Muodollisesti analyysi on sisäänrakennettu DevOps-prosessiin, mutta käytännössä se ei hyödytä ketään. Kuulimme yksityiskohtaisia tarinoita osastoilla konferenssin osallistujilta. Tällainen kokemus voi estää ohjelmoijia käyttämästä staattisia analyysityökaluja pitkään, ellei ikuisesti.
Teknisen velan käyttöönotto ja poistaminen
Itse asiassa staattisen analyysin käyttöönotossa ei ole mitään vaikeaa tai pelottavaa edes suureen vanhaan projektiin.
CI / CD
Lisäksi analysaattori voidaan ottaa välittömästi osaksi jatkuvaa kehitysprosessia. Esimerkiksi PVS-Studio-jakelu sisältää apuohjelmia, joilla voit kätevästi tarkastella raporttia tarvitsemassasi muodossa, ja ilmoitukset kehittäjille, jotka ovat kirjoittaneet ongelmallisia osia koodista. Niille, jotka ovat kiinnostuneempia PVS-Studion käynnistämisestä CI/CD-järjestelmistä, suosittelen tutustumaan vastaaviin dokumentaatio ja artikkelisarja:
Mutta palataanpa kysymykseen suuresta määrästä vääriä positiivisia tuloksia koodianalyysityökalujen käyttöönoton ensimmäisissä vaiheissa.
Nykyisen teknisen velan korjaaminen ja uusien varoitusten käsittely
Nykyaikaiset kaupalliset staattiset analysaattorit antavat sinun tutkia vain uusia varoituksia, jotka näkyvät uudessa tai muuttuneessa koodissa. Tämän mekanismin toteutus vaihtelee, mutta ydin on sama. PVS-Studio staattisessa analysaattorissa tämä toiminto on toteutettu seuraavasti.
Staattisen analyysin nopean käytön aloittamiseksi suosittelemme, että PVS-Studion käyttäjät käyttävät mekanismia varoitusten massapoistoon []. Yleinen ajatus on seuraava. Käyttäjä käynnisti analysaattorin ja sai monia varoituksia. Koska vuosia kehitteillä ollut projekti elää, kehittyy ja tekee rahaa, niin todennäköisimmin raportissa ei ole montaa kriittisiä puutteita osoittavia varoituksia. Toisin sanoen kriittisiä bugeja on jo korjattu tavalla tai toisella kalliimmilla menetelmillä tai asiakkaiden palautteen ansiosta. Näin ollen kaikkea, mitä analysaattori tällä hetkellä löytää, voidaan pitää teknisenä velana, jota ei ole käytännöllistä yrittää poistaa välittömästi.
Voit pyytää PVS-Studioa pitämään näitä varoituksia epäolennaisina toistaiseksi (säästä teknistä velkaa myöhempää käyttöä varten), eikä se enää näytä niitä. Analysaattori luo erityisen tiedoston, johon se tallentaa tiedot virheistä, jotka eivät vielä kiinnosta. Ja nyt PVS-Studio antaa varoituksia vain uudesta tai muuttuneesta koodista. Lisäksi kaikki tämä on toteutettu taitavasti. Jos esimerkiksi lähdekooditiedoston alkuun lisätään tyhjä rivi, analysaattori ymmärtää, että itse asiassa mikään ei ole muuttunut, ja on edelleen hiljaa. Tämä merkintätiedosto voidaan laittaa versionhallintajärjestelmään. Tiedosto on suuri, mutta tämä ei ole ongelma, koska sitä ei ole järkevää tallentaa usein.
Nyt kaikki ohjelmoijat näkevät vain uuteen tai muutettuun koodiin liittyviä varoituksia. Siten voit aloittaa analysaattorin käytön, kuten sanotaan, seuraavasta päivästä. Ja voit palata tekniseen velkaan myöhemmin ja korjata virheet vähitellen ja konfiguroida analysaattorin.
Joten ensimmäinen ongelma analysaattorin käyttöönotossa suuressa vanhassa projektissa on ratkaistu. Nyt selvitetään, mitä tehdä teknisen velan kanssa.
Virheenkorjauksia ja refaktorointia
Yksinkertaisin ja luonnollisin asia on varata aikaa analysoida massiivisesti vaimennetut analysaattorin varoitukset ja käsitellä niitä vähitellen. Jossain pitäisi korjata koodin virheet, jossain taas kertoa analysaattorille, että koodi ei ole ongelmallinen. Yksinkertainen esimerkki:
if (a = b)Useimmat C++-kääntäjät ja -analysaattorit valittavat tällaisesta koodista, koska on suuri todennäköisyys, että he todella halusivat kirjoittaa (a == b). Mutta on olemassa ääneen lausumaton sopimus, ja tämä yleensä mainitaan dokumentaatiossa, että jos on ylimääräisiä sulkeita, katsotaan, että ohjelmoija on tarkoituksella kirjoittanut tällaisen koodin, eikä sinun tarvitse vannoa. Esimerkiksi PVS-Studion diagnostiikkadokumentaatiossa on selvästi kirjoitettu, että seuraavaa riviä pidetään oikeana ja turvallisena:
if ((a = b))Toinen esimerkki. Onko se unohdettu tähän C++-koodiin? rikkoa vai ei?
case A:
foo();
case B:
bar();
break;PVS-Studio-analysaattori antaa varoituksen täällä . Tämä ei välttämättä ole virhe, jolloin sinun tulee antaa jäsentäjälle vihje lisäämällä attribuutti tai esimerkiksi __attribuutti__((putoaminen)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Voidaan sanoa, että tällaiset koodimuutokset eivät korjaa vikaa. Kyllä, tämä on totta, mutta sillä on kaksi hyödyllistä asiaa. Ensinnäkin analysaattoriraportti poistaa vääriä positiivisia tuloksia. Toiseksi koodista tulee ymmärrettävämpi sen ylläpitoon osallistuville ihmisille. Ja tämä on erittäin tärkeää! Pelkästään tätä varten kannattaa tehdä pieniä uudelleenjärjestelyjä, jotta koodista tulee selkeämpi ja helpompi ylläpitää. Koska analysaattori ei ymmärrä, tarvitaanko "katkoa" vai ei, se on myös epäselvää muille ohjelmoijille.
Virheenkorjausten ja refaktorointien lisäksi voit erityisesti estää ilmeisen väärän analysaattorin varoitukset. Jotkut epäolennaiset diagnoosit voidaan poistaa käytöstä. Esimerkiksi joku ajattelee, että varoitukset ovat turhia float/double-arvojen vertailusta. Ja jotkut luokittelevat ne tärkeiksi ja tutkimisen arvoisiksi []. Kehitystiimin voi päättää, mitkä varoitukset katsotaan merkityksellisiksi ja mitkä eivät.
On muitakin tapoja estää vääriä hälytyksiä. Esimerkiksi makromerkintä mainittiin aiemmin. Kaikki tämä on kuvattu tarkemmin dokumentaatiossa. Tärkeintä on ymmärtää, että jos asteittain ja järjestelmällisesti lähestyt väärien positiivisten tulosten kanssa työskentelemistä, niissä ei ole mitään vikaa. Suurin osa epämiellyttävistä varoituksista katoaa määrityksen jälkeen, ja vain paikat, jotka todella vaativat huolellista tutkimista ja joitain muutoksia koodiin, jäävät jäljelle.
Lisäksi autamme aina asiakkaitamme PVS-Studion perustamisessa, jos ongelmia ilmenee. Lisäksi oli tapauksia, joissa itse eliminoimme vääriä varoituksia ja korjasimme virheet []. Varmuuden vuoksi päätin mainita, että tämä vaihtoehto laajennettuun yhteistyöhön on myös mahdollinen :).
Räikkä menetelmä
On toinenkin mielenkiintoinen tapa parantaa koodin laatua asteittain poistamalla staattisen analysaattorin varoitus. Tärkeintä on, että varoitusten määrä voi vain pienentyä.
Staattisen analysaattorin antamien varoitusten määrä tallennetaan. Laatuportti on konfiguroitu siten, että nyt voit syöttää vain koodin, joka ei lisää toimintojen määrää. Tämän seurauksena hälytysten määrän asteittainen vähentäminen alkaa analysaattorin säätämisestä ja virheiden korjaamisesta.
Vaikka henkilö haluaisi hieman huijata ja päättäisi ohittaa laatuportin, ei poistamalla varoituksia uudesta koodistaan, vaan parantamalla vanhaa kolmannen osapuolen koodia, tämä ei ole pelottavaa. Silti räikkä pyörii yhteen suuntaan, ja vähitellen vikojen määrä vähenee. Vaikka henkilö ei haluaisi korjata omia uusia vikojaan, hänen on silti parannettava jotain naapurikoodissa. Jossain vaiheessa helpot tavat vähentää varoitusten määrää päättyvät, ja tulee kohta, jolloin todelliset viat korjataan.
Tätä menetelmää kuvataan yksityiskohtaisemmin Ivan Ponomarevin erittäin mielenkiintoisessa artikkelissa "", jonka suosittelen lukemista kaikille, jotka ovat kiinnostuneita koodin laadun parantamisesta.
Artikkelin kirjoittajalla on myös raportti tästä aiheesta: "".
Johtopäätös
Toivon, että tämän artikkelin jälkeen lukijat hyväksyvät staattiset analyysityökalut paremmin ja haluavat ottaa ne käyttöön kehitysprosessissa. Jos sinulla on kysyttävää, olemme aina valmiina staattisen analysaattorimme PVS-Studio käyttäjiä ja apua sen toteuttamisessa.
On muitakin tyypillisiä epäilyksiä siitä, voiko staattinen analyysi todella olla kätevää ja hyödyllistä. Yritin hälventää suurimman osan näistä epäilyistä julkaisussa "Syyt ottaa PVS-Studio staattinen koodianalysaattori kehitysprosessiin" [].
Kiitos huomiosta ja tule ja kokeile PVS-Studio-analysaattoria.
Muita linkkejä
- Andrei Karpov.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-studio. Dokumentointi. .
- Andrei Karpov. .
- PVS-studio. Dokumentointi. .
- Ivan Andryashin. .
- Pavel Eremeev, Svjatoslav Razmyslov. .
- Andrei Karpov. .
Jos haluat jakaa tämän artikkelin englanninkielisen yleisön kanssa, käytä käännöslinkkiä: Andrey Karpov. .
Lähde: will.com