Dit is maklik om 'n statiese kode-ontleder te probeer. Maar om dit te implementeer, veral in die ontwikkeling van 'n groot ou projek, verg vaardigheid. As dit verkeerd gedoen word, kan die ontleder werk byvoeg, ontwikkeling vertraag en die span demotiveer. Kom ons praat kortliks oor hoe om die integrasie van statiese analise in die ontwikkelingsproses behoorlik te benader en dit as deel van CI/CD te begin gebruik.
Inleiding
Onlangs is my aandag gevestig op die publikasie "". Aan die een kant is dit 'n goeie artikel wat die moeite werd is om kennis te maak. Aan die ander kant lyk dit vir my dat dit steeds nie 'n volledige antwoord gee oor hoe om statiese analise pynloos in 'n projek met baie te implementeer nie. van nalatenskapkode. Die artikel sê dat Jy tegniese skuld kan aanvaar en net aan nuwe kode kan werk, maar daar is geen antwoord op wat om later met hierdie tegniese skuld te doen nie.
Ons PVS-Studio-span bied sy siening oor hierdie onderwerp. Kom ons kyk hoe die probleem met die implementering van 'n statiese kode-ontleder in die eerste plek ontstaan, hoe om hierdie probleem te oorkom, en hoe om tegniese skuld geleidelik pynloos uit te skakel.
Probleem
Dit is gewoonlik nie moeilik om te begin en te sien hoe 'n statiese ontleder werk nie []. Jy kan interessante foute of selfs skrikwekkende potensiële kwesbaarhede in die kode sien. Jy kan selfs iets regmaak, maar dan gee baie programmeerders op.
Alle statiese ontleders produseer vals positiewe. Dit is 'n kenmerk van die statiese kode-analise-metodologie, en niks kan daaraan gedoen word nie. In die algemene geval is dit 'n onoplosbare probleem, soos bevestig deur Rice se stelling []. Masjienleeralgoritmes sal ook nie help nie []. Selfs as 'n persoon nie altyd kan weet of hierdie of daardie kode verkeerd is nie, moet jy dit nie van die program verwag nie :).
Vals positiewe is nie 'n probleem as die statiese ontleder reeds opgestel is nie:
- Gedeaktiveerde irrelevante reëlstelle;
- Sommige irrelevante diagnostiek is gedeaktiveer;
- As ons van C of C++ praat, dan word makros opgemerk wat spesifieke konstrukte bevat wat veroorsaak dat nuttelose waarskuwings op elke plek verskyn waar sulke makros gebruik word;
- Eie funksies word gemerk wat aksies uitvoer soortgelyk aan stelselfunksies (sy eie analoog memcpy of printf) [];
- Vals positiewes word spesifiek gedeaktiveer deur opmerkings te gebruik;
- En so aan.
In hierdie geval kan ons 'n lae vals positiewe koers van ongeveer 10-15% verwag []. Met ander woorde, 9 uit 10 ontlederwaarskuwings sal 'n werklike probleem in die kode aandui, of ten minste "sterk-ruikende kode." Stem saam, hierdie scenario is uiters aangenaam, en die ontleder is 'n ware vriend van die programmeerder.
In werklikheid, in 'n groot projek, sal die aanvanklike prentjie heeltemal anders wees. Die ontleder reik honderde of duisende waarskuwings vir verouderde kode uit. Dit is onmoontlik om vinnig te verstaan watter van hierdie waarskuwings relevant is en watter nie. Dit is irrasioneel om te gaan sit en al hierdie waarskuwings te begin hanteer, aangesien die hoofwerk in hierdie geval vir dae of weke sal ophou. Tipies kan 'n span nie so 'n scenario bekostig nie. Daar sal ook 'n groot aantal verskille wees wat die veranderingsgeskiedenis bederf. En vinnige massa redigering van soveel fragmente in die kode sal onvermydelik lei tot nuwe tikfoute en foute.
En die belangrikste is dat so 'n prestasie in die stryd teen waarskuwings min sin maak. Stem saam dat aangesien die projek al baie jare suksesvol aan die gang is, die meeste van die kritieke foute daarin reeds reggestel is. Ja, hierdie regstellings was baie duur, moes ontfout word, het negatiewe gebruikersterugvoer oor foute ontvang, ensovoorts. 'n Statiese ontleder sal help om baie van hierdie foute in die koderingstadium vinnig en goedkoop op te los. Maar op die oomblik, op een of ander manier, is hierdie foute reggestel, en die ontleder bespeur hoofsaaklik nie-kritieke foute in die ou kode. Hierdie kode mag dalk nie gebruik word nie, dit kan baie selde gebruik word, en 'n fout daarin mag dalk nie tot merkbare gevolge lei nie. Miskien is die skaduwee van die knoppie iewers die verkeerde kleur, maar dit meng nie in met enigiemand se gebruik van die produk nie.
Natuurlik is selfs geringe foute steeds foute. En soms kan 'n fout 'n werklike kwesbaarheid verberg. Dit lyk egter na 'n twyfelagtige idee om alles op te gee en dae/weke te spandeer om defekte te hanteer wat skaars manifesteer.
Programmeerders kyk, kyk, kyk na al hierdie waarskuwings oor die ou werkende kode... En hulle dink: ons kan sonder statiese ontleding klaarkom. Kom ons gaan skryf 'n paar nuwe nuttige funksionaliteit.
Op hul eie manier is hulle reg. Hulle dink eers dat hulle op een of ander manier van al hierdie waarskuwings ontslae moet raak. Eers dan sal hulle voordeel kan trek uit gereelde gebruik van die kode-ontleder. Andersins sal nuwe waarskuwings eenvoudig in oues verdrink, en niemand sal daaraan aandag gee nie.
Dit is dieselfde analogie as met samestellerwaarskuwings. Dit is nie sonder rede dat hulle aanbeveel om die aantal samestellerwaarskuwings op 0 te hou nie. As daar 1000 waarskuwings is, sal niemand, wanneer daar 1001 is, daaraan aandag gee nie, en dit is nie duidelik waar om hierdie nuutste waarskuwing te soek nie.
Die ergste ding in hierdie storie is as iemand van bo jou op hierdie oomblik dwing om statiese kode-analise te gebruik. Dit sal die span net demotiveer, aangesien daar uit hul oogpunt bykomende burokratiese kompleksiteit sal wees wat net in die pad staan. Niemand sal na die ontleder se verslae kyk nie, en alle gebruik sal slegs "op papier" wees. Dié. Formeel word analise in die DevOps-proses ingebou, maar in die praktyk baat dit niemand nie. Ons het gedetailleerde stories by stalletjies van konferensiegangers gehoor. So 'n ervaring kan programmeerders ontmoedig om vir 'n lang tyd, indien nie vir ewig, statiese analise-instrumente te gebruik nie.
Implementering en uitskakeling van tegniese skuld
Trouens, daar is niks moeilik of skrikwekkend daaraan om statiese analise selfs in 'n groot ou projek in te voer nie.
CI / CD
Boonop kan die ontleder onmiddellik deel gemaak word van die deurlopende ontwikkelingsproses. Byvoorbeeld, die PVS-Studio-verspreiding bevat nutsprogramme om die verslag gerieflik te bekyk in die formaat wat jy benodig, en kennisgewings aan ontwikkelaars wat problematiese dele van die kode geskryf het. Vir diegene wat meer belangstel in die bekendstelling van PVS-Studio vanaf CI/CD-stelsels, beveel ek aan dat u uself vergewis van die ooreenstemmende dokumentasie en 'n reeks artikels:
Maar kom ons keer terug na die kwessie van 'n groot aantal vals positiewe in die eerste stadiums van die implementering van kode-analise-instrumente.
Regstelling van bestaande tegniese skuld en hantering van nuwe waarskuwings
Moderne kommersiële statiese ontleders laat jou toe om slegs nuwe waarskuwings te bestudeer wat in nuwe of veranderde kode verskyn. Die implementering van hierdie meganisme verskil, maar die essensie is dieselfde. In die PVS-Studio statiese ontleder word hierdie funksionaliteit soos volg geïmplementeer.
Om vinnig statiese analise te begin gebruik, stel ons voor PVS-Studio-gebruikers gebruik die meganisme vir massa-onderdrukking van waarskuwings []. Die algemene idee is die volgende. Die gebruiker het die ontleder geloods en baie waarskuwings ontvang. Aangesien 'n projek wat al vir baie jare in ontwikkeling is, lewendig is, ontwikkel en geld verdien, sal daar heel waarskynlik nie baie waarskuwings in die verslag wees wat kritieke gebreke aandui nie. Met ander woorde, kritieke foute is reeds op een of ander manier reggestel deur duurder metodes of danksy terugvoer van kliënte. Gevolglik kan alles wat die ontleder tans vind, as tegniese skuld beskou word, wat onprakties is om dadelik te probeer uitskakel.
Jy kan vir PVS-Studio sê om hierdie waarskuwings vir eers as irrelevant te beskou (spaar tegniese skuld vir later), en dit sal dit nie meer wys nie. Die ontleder skep 'n spesiale lêer waar dit inligting stoor oor foute wat nog nie interessant is nie. En nou sal PVS-Studio slegs waarskuwings uitreik vir nuwe of veranderde kode. Boonop word dit alles slim geïmplementeer. As, byvoorbeeld, 'n leë reël aan die begin van die bronkode-lêer bygevoeg word, dan verstaan die ontleder dat, in werklikheid, niks verander het nie, en sal voortgaan om stil te wees. Hierdie opmaaklêer kan in 'n weergawebeheerstelsel geplaas word. Die lêer is groot, maar dit is nie 'n probleem nie, aangesien dit geen sin is om dit gereeld te stoor nie.
Nou sal alle programmeerders waarskuwings sien wat slegs verband hou met nuwe of veranderde kode. U kan dus die ontleder, soos hulle sê, vanaf die volgende dag begin gebruik. En jy kan later terugkeer na tegniese skuld, en foute geleidelik regstel en die ontleder instel.
Dus, die eerste probleem met die implementering van die ontleder in 'n groot ou projek is opgelos. Laat ons nou uitvind wat om met tegniese skuld te doen.
Foutoplossings en herfaktorerings
Die eenvoudigste en natuurlikste ding is om tyd opsy te sit om massief onderdrukte ontlederwaarskuwings te ontleed en dit geleidelik te hanteer. Iewers moet jy foute in die kode regmaak, iewers moet jy herfaktor om die ontleder te vertel dat die kode nie problematies is nie. Eenvoudige voorbeeld:
if (a = b)Die meeste C++ samestellers en ontleders kla oor sulke kode, aangesien daar 'n groot waarskynlikheid is dat hulle eintlik wou skryf (a == b). Maar daar is 'n onuitgesproke ooreenkoms, en dit word gewoonlik in die dokumentasie opgemerk, dat as daar bykomende hakies is, word dit beskou dat die programmeerder doelbewus sulke kode geskryf het, en dit hoef nie te vloek nie. Byvoorbeeld, in die PVS-Studio dokumentasie vir diagnostiek dit is duidelik geskryf dat die volgende reël as korrek en veilig beskou sal word:
if ((a = b))Nog 'n voorbeeld. Is dit in hierdie C++-kode vergeet? breek of nie?
case A:
foo();
case B:
bar();
break;Die PVS-Studio-ontleder sal hier 'n waarskuwing uitreik . Dit is dalk nie 'n fout nie, in welke geval jy die ontleder 'n wenk moet gee deur die kenmerk by te voeg of byvoorbeeld __kenmerk__((deurval)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Daar kan gesê word dat sulke kodeveranderings nie die fout regstel nie. Ja, dit is waar, maar dit doen twee nuttige dinge. Eerstens raak die ontlederverslag ontslae van vals positiewes. Tweedens word die kode meer verstaanbaar vir die mense wat by die instandhouding daarvan betrokke is. En dit is baie belangrik! Hiervoor alleen is dit die moeite werd om klein herfaktorerings uit te voer om die kode duideliker en makliker te maak om te onderhou. Aangesien die ontleder nie verstaan of "breek" nodig is of nie, sal dit ook vir medeprogrammeerders onduidelik wees.
Benewens foutoplossings en herfaktorings, kan u spesifiek duidelike vals ontlederwaarskuwings onderdruk. Sommige irrelevante diagnostiek kan gedeaktiveer word. Byvoorbeeld, iemand dink waarskuwings is nutteloos oor die vergelyking van dryf-/dubbelwaardes. En sommige klassifiseer hulle as belangrik en waardig om te bestudeer []. Watter waarskuwings as relevant beskou word en watter nie, is aan die ontwikkelingspan om te besluit.
Daar is ander maniere om vals waarskuwings te onderdruk. Byvoorbeeld, makro-opmerk is vroeër genoem. Dit alles word in meer besonderhede in die dokumentasie beskryf. Die belangrikste ding is om te verstaan dat as jy geleidelik en sistematies aanpak om met vals positiewes te werk, is daar niks fout daarmee nie. Die oorgrote meerderheid oninteressante waarskuwings verdwyn na konfigurasie, en slegs plekke wat regtig noukeurige studie en 'n paar veranderinge in die kode vereis, bly oor.
Ons help ook altyd ons kliënte met die opstel van PVS-Studio as enige probleme opduik. Boonop was daar gevalle waar ons self vals waarskuwings uitgeskakel en foute reggestel het []. Net vir ingeval, ek het besluit om te noem dat hierdie opsie vir uitgebreide samewerking ook moontlik is :).
Ratchet metode
Daar is nog 'n interessante benadering om kodekwaliteit geleidelik te verbeter deur die statiese ontlederwaarskuwing uit te skakel. Die slotsom is dat die aantal waarskuwings net kan afneem.
Die aantal waarskuwings wat deur die statiese ontleder uitgereik word, word aangeteken. Kwaliteithek is so gekonfigureer dat jy nou net 'n kode kan invoer wat nie die aantal bewerkings verhoog nie. As gevolg hiervan begin die proses om die aantal alarms geleidelik te verminder deur die ontleder aan te pas en foute reg te stel.
Selfs as 'n persoon 'n bietjie wil kul en besluit om die kwaliteitshek verby te gaan, nie deur waarskuwings in sy nuwe kode uit te skakel nie, maar deur die ou derdeparty-kode te verbeter, is dit nie skrikwekkend nie. Die ratel draai egter in een rigting, en geleidelik sal die aantal defekte afneem. Selfs as 'n persoon nie sy eie nuwe gebreke wil regmaak nie, sal hy steeds iets in die naburige kode moet verbeter. Op 'n stadium eindig die maklike maniere om die aantal waarskuwings te verminder, en daar kom 'n punt wanneer regte foute reggestel sal word.
Hierdie metodologie word in meer besonderhede beskryf in 'n baie interessante artikel deur Ivan Ponomarev "", wat ek aanbeveel om te lees vir enigiemand wat belangstel om kodekwaliteit te verbeter.
Die skrywer van die artikel het ook 'n verslag oor hierdie onderwerp: "".
Gevolgtrekking
Ek hoop dat lesers na hierdie artikel meer statiese analise-instrumente sal aanvaar en dit in die ontwikkelingsproses sal wil implementeer. As jy enige vrae het, is ons altyd gereed gebruikers van ons statiese ontleder PVS-Studio en help met die implementering daarvan.
Daar is ander tipiese twyfel oor of statiese analise werklik gerieflik en nuttig kan wees. Ek het die meeste van hierdie twyfel probeer uit die weg ruim in die publikasie "Redes om die PVS-Studio statiese kode-ontleder in die ontwikkelingsproses bekend te stel" [].
Dankie vir jou aandag en kom en probeer die PVS-Studio-ontleder.
Bykomende skakels
- Andrey Karpov.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-ateljee. Dokumentasie. .
- Andrey Karpov. .
- PVS-ateljee. Dokumentasie. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Andrey Karpov. .
As jy hierdie artikel met 'n Engelssprekende gehoor wil deel, gebruik asseblief die vertaalskakel: Andrey Karpov. .
Bron: will.com