Et ass einfach e statesche Code Analyser ze probéieren. Awer et ëmzesetzen, besonnesch an der Entwécklung vun engem groussen alen Projet, erfuerdert Fäegkeet. Wann et falsch gemaach gëtt, kann den Analysator Aarbecht addéieren, d'Entwécklung verlangsamen an d'Team demotivéieren. Loosst eis kuerz iwwer schwätzen wéi Dir d'Integratioun vun der statescher Analyse an den Entwécklungsprozess richteg unzegoen an se als Deel vum CI / CD ze benotzen.
Aféierung
Viru kuerzem gouf meng Opmierksamkeet op d'Publikatioun gezunn "". Engersäits ass dat e gudden Artikel, deen et derwäert ass, sech ze kennenzeléieren. Op der anerer Säit schéngt et mir, datt et nach ëmmer keng komplett Äntwert gëtt, wéi een statesch Analyse schmerzlos an engem Projet mat vill ëmsetzt. vum Legacy Code.Den Artikel seet datt Dir technesch Scholden akzeptéiere kënnt an nëmmen un neie Code schaffen, awer et gëtt keng Äntwert op wat Dir spéider mat dëser technescher Schold maache kënnt.
Eis PVS-Studio-Team bitt seng Vue op dëst Thema. Loosst eis kucken wéi de Problem vun der Ëmsetzung vun engem statesche Code Analyser an der éischter Plaz entsteet, wéi dëse Problem ze iwwerwannen, a wéi schmerzlos graduell technesch Scholden eliminéiert ginn.
Problemer
Et ass normalerweis net schwéier ze starten a kucken wéi e statesche Analysator funktionnéiert []. Dir kënnt interessant Feeler oder souguer grujeleg potenziell Schwachstelle am Code gesinn. Dir kënnt souguer eppes fixéieren, awer da ginn vill Programméierer op.
All statesch Analysatoren produzéieren falsch Positiver. Dëst ass eng Feature vun der statesch Code Analyse Methodologie, an näischt kann doriwwer gemaach ginn. Am allgemenge Fall ass dëst en onléisbare Problem, wéi bestätegt vum Rice's Theorem []. Maschinn Léieren Algorithmen wäerten och net hëllefen []. Och wann eng Persoun net ëmmer kann soen ob dësen oder deen Code falsch ass, da sollt Dir dëst net vum Programm erwaarden :).
Falsch Positiver si kee Problem wann de statesche Analysator scho konfiguréiert ass:
- Behënnert irrelevant Regel setzt;
- E puer irrelevant Diagnostik goufen behënnert;
- Wa mir iwwer C oder C++ schwätzen, da gi Makroen markéiert, déi spezifesch Konstruktiounen enthalen, déi onnëtz Warnungen op all Plaz verursaachen, wou esou Makroen benotzt ginn;
- Eegent Funktiounen sinn markéiert déi Aktiounen ausféieren ähnlech wéi Systemfunktiounen (seng eegen Analog memcpy oder printf) [];
- Falsch Positiver sinn speziell behënnert mat Kommentaren;
- An esou weider.
An dësem Fall kënne mir e nidderegen falsche positiven Taux vun ongeféier 10-15% erwaarden []. An anere Wierder, 9 vun 10 Analyser Warnungen weisen e richtege Problem am Code, oder op d'mannst "staark Geroch Code." Averstanen, dëst Szenario ass extrem agreabel, an den Analyser ass e richtege Frënd vum Programméierer.
A Wierklechkeet, an engem grousse Projet, wäert d'éischt Bild komplett anescht sinn. Den Analyser erausginn Honnerte oder Dausende vun Warnungen fir Legacy Code. Et ass onméiglech séier ze verstoen wéi eng vun dësen Warnungen relevant sinn a wéi eng net. Et ass irrational fir sech ze sëtzen a mat all dës Warnungen unzefänken, well d'Haaptaarbecht an dësem Fall fir Deeg oder Wochen ophält. Typesch kann en Team sech esou en Szenario net leeschten. Et wäert och eng riesech Unzuel vun Differenzen sinn, déi d'Verännerungsgeschicht verwinnt. A séier Mass Redaktioun vun esou vill Fragmenter am Code wäert zwangsleefeg zu neie Schreiffeeler a Feeler Resultat.
A virun allem, esou e Feat am Kampf géint Warnungen mécht wéineg Sënn. Averstanen datt well de Projet fir vill Joren erfollegräich leeft, déi meescht vun de kritesche Feeler an et scho korrigéiert goufen. Jo, dës Fixer ware ganz deier, hu missen debugged ginn, hunn negativ Benotzer Feedback iwwer Käfere kritt, a sou weider. E statesche Analysator hëlleft vill vun dëse Feeler an der Kodéierungsstadium ze fixéieren, séier a bëlleg. Awer am Moment, déi eng oder aner Manéier, sinn dës Feeler fixéiert ginn, an den Analyser entdeckt haaptsächlech net kritesch Feeler am alen Code. Dëse Code kann net benotzt ginn, et ka ganz selten benotzt ginn, an e Feeler an et kann net zu merkbare Konsequenze féieren. Vläicht iergendwou ass de Schatten vum Knäppchen déi falsch Faarf, awer dëst stéiert net mat jidderengem d'Benotzung vum Produkt.
Natierlech sinn och kleng Feeler nach ëmmer Feeler. An heiansdo kann e Feeler eng richteg Schwachstelle verstoppen. Wéi och ëmmer, alles opzeginn an Deeg/Wochen ze verbréngen mat Mängel déi sech kaum manifestéieren, gesäit aus wéi eng zweifelhaft Iddi.
Programméierer kucken, kuckt, kuckt all dës Warnungen iwwer den alen Aarbechtscode ... A si denken: mir kënnen ouni statesch Analyse maachen. Loosst eis e puer nei nëtzlech Funktionalitéit schreiwen.
Op hir Manéier si se richteg. Si stelle fest, datt si fir d'éischt iergendwéi all dës Warnungen lass musse loossen. Nëmmen da kënne se vum regelméissege Gebrauch vum Code Analyser profitéieren. Soss wäerten nei Warnungen einfach an al erdrénken, a kee wäert op si oppassen.
Dëst ass déiselwecht Analogie wéi mat Compiler Warnungen. Et ass net ouni Grond datt se recommandéieren d'Zuel vun de Compiler Warnungen op 0 ze halen. Wann et 1000 Warnunge gëtt, da wann et 1001 sinn, da wäert keen oppassen op et, an et ass net kloer wou Dir dës neist Warnung kuckt.
Dat Schlëmmst an dëser Geschicht ass wann een vun uewen am Moment Iech forcéiert statesch Code Analyse ze benotzen. Dëst wäert d'Equipe nëmmen demotivéieren, well aus hirer Siicht gëtt et zousätzlech bürokratesch Komplexitéit déi nëmmen am Wee stitt. Keen wäert d'Rapporte vum Analyser kucken, an all Notzung wäert nëmmen "op Pabeier" sinn. Déi. Formell ass d'Analyse an den DevOps-Prozess agebaut, awer an der Praxis profitéiert dat kee Mënsch. Mir héieren detailléiert Geschichten op Stänn vun Konferenz Participanten. Sou eng Erfarung kann Programméierer decouragéieren fir statesch Analyse-Tools fir eng laang Zäit ze benotzen, wann net fir ëmmer.
Ëmsetzung an eliminéiert technesch Schold
Tatsächlech ass et näischt schwéier oder grujeleg iwwer d'statesch Analyse och an e groussen alen Projet aféieren.
CI / CD
Ausserdeem kann den Analysator direkt Deel vum kontinuéierleche Entwécklungsprozess gemaach ginn. Zum Beispill enthält d'PVS-Studio Verdeelung Utilities fir bequem de Bericht am Format ze gesinn deen Dir braucht, an Notifikatiounen un Entwéckler déi problematesch Sektioune vum Code geschriwwen hunn. Fir déi, déi méi interesséiert sinn fir PVS-Studio aus CI/CD Systemer ze lancéieren, recommandéieren ech Iech mat den entspriechende Dokumentatioun an eng Serie vun Artikelen:
Awer loosst eis zréck op d'Fro vun enger grousser Zuel vu falschen Positiven an den éischte Stadien vun der Ëmsetzung vun Code Analyse Tools.
D'Befestegung vun existente technesche Scholden a mat neie Warnungen ëmzegoen
Modern kommerziell statesch Analysatoren erlaben Iech nëmmen nei Warnungen ze studéieren déi an neien oder geännerten Code erschéngen. D'Ëmsetzung vun dësem Mechanismus variéiert, awer d'Essenz ass d'selwecht. Am PVS-Studio statesche Analysator gëtt dës Funktionalitéit wéi follegt ëmgesat.
Fir séier statesch Analyse ze benotzen, proposéiere mir PVS-Studio Benotzer de Mechanismus fir Massendrock vun Warnungen ze benotzen []. Déi allgemeng Iddi ass déi folgend. De Benotzer huet den Analyser gestart a krut vill Warnungen. Well e Projet, deen zënter ville Joren an der Entwécklung ass, lieweg ass, entwéckelen a Sue verdéngt, da wäert et wahrscheinlech net vill Warnungen am Bericht sinn, déi kritesch Mängel uginn. An anere Wierder, kritesch Käfere si schonn op eng oder aner Manéier fixéiert mat méi deier Methoden oder dank Feedback vu Clienten. Deementspriechend kann alles wat den Analyser am Moment fënnt, als technesch Schold ugesi ginn, wat onpraktesch ass ze probéieren direkt ze eliminéieren.
Dir kënnt PVS-Studio soen dës Warnungen irrelevant fir de Moment ze betruechten (späicheren technesch Schold fir spéider), an et wäert se net méi weisen. Den Analyser erstellt eng speziell Datei wou et Informatioun iwwer Feeler späichert déi nach net interessant sinn. An elo wäert PVS-Studio Warnungen nëmme fir nei oder geännert Code erausginn. Ausserdeem gëtt dat alles clever ëmgesat. Wann zum Beispill eng eidel Zeil am Ufank vun der Quellcodedatei bäigefüügt gëtt, da versteet den Analyser datt tatsächlech näischt geännert huet a wäert weider roueg sinn. Dës Markupdatei kann an e Versiounskontrollsystem gesat ginn. De Fichier ass grouss, awer dëst ass kee Problem, well et kee Sënn ass et dacks ze späicheren.
Elo gesinn all Programméierer Warnungen am Zesummenhang mat nëmmen neien oder geännerten Code. Sou kënnt Dir den Analyser benotzen, wéi se soen, vum nächsten Dag. An Dir kënnt spéider op d'technesch Schold zréckkommen, a lues a lues Feeler korrigéieren an den Analyser konfiguréieren.
Also ass den éischte Problem mat der Ëmsetzung vum Analysator an engem grousse alen Projet geléist. Loosst eis elo erausfannen, wat mat technescher Schold ze maachen.
Bug Fixes a Refactoring
Déi einfachst an natierlechst Saach ass eng Zäit ofzesetzen fir massiv ënnerdréckte Analysatorwarnungen ze analyséieren a graduell mat hinnen ëmzegoen. Iergendwou sollt Dir Feeler am Code fixéieren, iergendwou sollt Dir refactor fir den Analyser ze soen datt de Code net problematesch ass. Einfach Beispill:
if (a = b)Déi meescht C++ Compileren an Analysatoren beschwéieren iwwer sou Code, well et eng héich Wahrscheinlechkeet ass datt se tatsächlech wollte schreiwen (a == b). Awer et gëtt en ongeschwaten Accord, an dëst ass normalerweis an der Dokumentatioun bemierkt datt wann et zousätzlech Klammern ass, da gëtt et ugesinn datt de Programméierer sou en Code bewosst geschriwwen huet, an et ass net néideg ze schwieren. Zum Beispill, an der PVS-Studio Dokumentatioun fir Diagnostik et ass kloer geschriwwen datt déi folgend Linn als korrekt a sécher ugesi gëtt:
if ((a = b))En anert Beispill. Ass et an dësem C ++ Code vergiess? briechen oder nët?
case A:
foo();
case B:
bar();
break;De PVS-Studio Analyser wäert hei eng Warnung erausginn . Dëst kann net e Feeler sinn, an deem Fall sollt Dir dem Parser en Hiweis ginn andeems Dir den Attribut derbäigesat oder zum Beispill __attribute__((fallthrough)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Et kann gesot ginn datt sou Code Ännerungen de Feeler net fixéieren. Jo, dëst ass wouer, awer et mécht zwou nëtzlech Saachen. Als éischt gëtt den Analyser Bericht vu falsche Positiven lass. Zweetens gëtt de Code méi verständlech fir d'Leit, déi an hirem Ënnerhalt involvéiert sinn. An dat ass ganz wichteg! Fir dëst eleng ass et derwäert kleng Refaktoréierungen auszeféieren fir de Code méi kloer a méi einfach ze pflegen. Well den Analyser net versteet ob "Paus" gebraucht gëtt oder net, ass et och onkloer fir Matbierger Programméierer.
Zousätzlech zu Bugfixes a Refactorings, kënnt Dir speziell offensichtlech falsch Analyserwarnungen ënnerdrécken. E puer irrelevant Diagnostik kënne behënnert ginn. Zum Beispill, een denkt datt Warnungen sënnlos sinn iwwer Schwammen / duebel Wäerter vergläichen. An e puer klassifizéieren se als wichteg a wäertvoll ze studéieren []. Wéi eng Warnungen als relevant ugesi ginn a wéi eng net ass un d'Entwécklungsteam ze entscheeden.
Et ginn aner Weeër fir falsch Alarmer z'ënnerhalen. Zum Beispill gouf Makromarkup virdru erwähnt. All dëst ass méi detailléiert an der Dokumentatioun beschriwwen. Déi wichtegst Saach ass ze verstoen datt wann Dir graduell a systematesch Approche mat falsche Positiven ze schaffen, et ass näischt falsch mat hinnen. Déi grouss Majoritéit vun oninteressante Warnungen verschwannen no der Konfiguratioun, an nëmme Plazen, déi wierklech virsiichteg Studie erfuerderen an e puer Ännerungen am Code bleiwen.
Och hëllefe mir ëmmer eise Clienten PVS-Studio opzebauen wann Schwieregkeeten entstinn. Ausserdeem goufen et Fäll wou mir selwer falsch Warnungen eliminéiert a Feeler korrigéiert hunn []. Just am Fall hunn ech beschloss ze ernimmen datt dës Optioun fir verlängert Zesummenaarbecht och méiglech ass :).
Ratchet Method
Et gëtt eng aner interessant Approche fir d'Codequalitéit graduell ze verbesseren andeems d'statesch Analysator Warnung eliminéiert gëtt. Déi ënnescht Linn ass datt d'Zuel vun den Warnungen nëmmen erofgoe kann.
D'Zuel vun den Warnungen, déi vum statesche Analysator ausgestallt goufen, gëtt opgeholl. Qualitéitspaart ass sou konfiguréiert datt Dir elo nëmmen e Code gitt, deen d'Zuel vun den Operatiounen net erhéicht. Als Resultat fänkt de Prozess fir d'Zuel vun den Alarmer graduell ze reduzéieren andeems den Analysator ugepasst gëtt a Feeler korrigéiert.
Och wann eng Persoun e bësse wëll fuddelen an decidéiert de Qualitéitspaart ze passéieren net andeems d'Warnungen a sengem neie Code eliminéiert ginn, mee duerch d'Verbesserung vum alen Drëtt-Partei-Code, ass dëst net Angscht. All déiselwecht rotéiert de Ratchet an eng Richtung, a lues a lues wäert d'Zuel vun de Mängel erofgoen. Och wann eng Persoun seng eegen nei Mängel net wëllt fixéieren, muss hien nach eppes am Nopeschcode verbesseren. Irgendwann sinn déi einfach Weeër fir d'Zuel vun den Warnungen ze reduzéieren op en Enn, an et kënnt e Punkt wou richteg Bugs fixéiert ginn.
Dës Methodik gëtt méi detailléiert an engem ganz interessanten Artikel vum Ivan Ponomarev beschriwwen "", déi ech recommandéieren fir jiddereen ze liesen, deen interesséiert ass fir d'Codequalitéit ze verbesseren.
Den Auteur vum Artikel huet och e Bericht iwwer dëst Thema: "".
Konklusioun
Ech hoffen, datt no dësem Artikel d'Lieser méi statesch Analyse-Tools akzeptéieren an se wëllen an den Entwécklungsprozess ëmsetzen. Wann Dir Froen hutt, si mir ëmmer prett Benotzer vun eisem statesche Analysator PVS-Studio an Hëllef bei der Ëmsetzung.
Et ginn aner typesch Zweifel ob statesch Analyse wierklech praktesch an nëtzlech ka sinn. Ech hu probéiert déi meescht vun dësen Zweifel an der Verëffentlechung "Grënn fir de PVS-Studio statesche Code Analyser an den Entwécklungsprozess anzeféieren" [].
Merci fir Är Opmierksamkeet a kommt a probéiert de PVS-Studio Analyser.
Zousätzlech Links
- Andrey Karpov.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-Studio. Dokumentatioun. .
- Andrey Karpov. .
- PVS-Studio. Dokumentatioun. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Andrey Karpov. .
Wann Dir dësen Artikel mat engem engleschsproochege Publikum wëllt deelen, benotzt w.e.g. den Iwwersetzungslink: Andrey Karpov. .
Source: will.com