Ech war opgefuerdert dësen Artikel ze schreiwen duerch déi grouss Quantitéit vu Materialien iwwer statesch Analyse déi ëmmer méi op meng Opmierksamkeet kommen. Éischtens, dëst , déi sech aktiv op Habré fördert mat Hëllef vu Bewäertunge vu Feeler, déi vun hirem Tool an Open Source Projeten fonnt goufen. Kuerzem PVS-Studio ëmgesat , an natierlech d'Entwéckler vun IntelliJ IDEA, deem säin agebaute Analyser wahrscheinlech dee modernste fir Java haut ass, .
Wann Dir esou Rezensiounen liest, kritt Dir d'Gefill datt mir iwwer e mageschen Elixir schwätzen: Press de Knäppchen, an hei ass et - eng Lëscht vu Mängel virun Ären Aen. Et schéngt wéi wann Analysatoren verbesseren, méi a méi Bugs automatesch fonnt ginn, an d'Produiten, déi vun dëse Roboteren gescannt ginn, wäerte besser a besser ginn, ouni Effort vun eiser Säit.
Awer et gi keng magesch Elixiren. Ech géif gären iwwer dat schwätzen wat normalerweis net geschwat gëtt a Posts wéi "Hei sinn d'Saachen déi eise Roboter fannen kann": wat Analysatoren net maache kënnen, wat ass hir richteg Roll a Plaz am Software Liwwerungsprozess, a wéi se se korrekt ëmsetzen .
Ratchet (Quelle: ).
Wat statesch Analysatoren ni maache kënnen
Wat ass Quellcode Analyse, aus enger praktescher Siicht? Mir bidden e puer Quellcode als Input, an als Output, a kuerzer Zäit (vill méi kuerz wéi Tester) kréien mir e puer Informatioun iwwer eise System. Déi fundamental a mathematesch oniwwergänglech Begrenzung ass datt mir op dës Manéier nëmmen eng zimlech schmuel Informatiounsklass kréien.
Dat bekanntst Beispill vun engem Problem deen net mat statesch Analyse geléist ka ginn ass : Dëst ass en Theorem deen beweist datt et onméiglech ass en allgemenge Algorithmus z'entwéckelen, deen aus dem Quellcode vun engem Programm kann bestëmmen ob et an enger endlecher Zäit wäert schloen oder ophalen. Eng Ausdehnung vun dësem Theorem ass , déi seet, datt fir all net-trivial Propriétéit vun berechnen Funktiounen, Bestëmmung ob en arbiträr Programm eng Funktioun mat esou Propriétéit evaluéiert ass en algorithmically intractable Problem. Zum Beispill ass et onméiglech en Analysator ze schreiwen, deen aus all Quellcode kann bestëmmen ob de Programm, deen analyséiert gëtt, eng Ëmsetzung vun engem Algorithmus ass, deen zum Beispill de Quadrat vun engem ganzt Zuel berechent.
Also huet d'Funktionalitéit vu statesche Analysatoren oniwwersiichtlech Aschränkungen. E statesche Analysator wäert ni fäeg sinn an alle Fäll esou Saachen z'entdecken wéi zum Beispill d'Optriede vun enger "Null Pointer Ausnam" a Sproochen déi de Wäert vun Null erlaben, oder an alle Fäll d'Optriede vun enger " Attribut net fonnt" an dynamesch getippten Sproochen. Alles wat de fortgeschratt statesche Analysator maache kann ass speziell Fäll ze markéieren, d'Zuel vun deenen, ënner all méigleche Probleemer mat Ärem Quellcode, ass, ouni iwwerdreiwen, e Tropfen am Ozean.
Statesch Analyse ass net iwwer Bugs ze fannen
Vun uewen ass d'Konklusioun: statesch Analyse ass net e Mëttel fir d'Zuel vun de Mängel an engem Programm ze reduzéieren. Ech géif riskéieren ze soen: wann Dir op Äre Projet fir d'éischte Kéier applizéiert gëtt, wäert et "interessant" Plazen am Code fannen, awer, wahrscheinlech, wäert et keng Mängel fannen, déi d'Qualitéit vun Ärem Programm beaflossen.
D'Beispiller vu Mängel, déi automatesch vun Analysatoren fonnt goufen, sinn beandrockend, awer mir sollten net vergiessen datt dës Beispiller fonnt goufen duerch Scannen vun enger grousser Set vu grousse Codebasen. Mam selwechte Prinzip, Hacker, déi d'Méiglechkeet hunn e puer einfache Passwierder op enger grousser Zuel vu Konten ze probéieren, schliisslech fannen déi Konten déi en einfacht Passwuert hunn.
Heescht dat datt statesch Analyse net soll benotzt ginn? Natierlech net! A fir genee dee selwechte Grond datt et derwäert ass all neit Passwuert ze kontrolléieren fir sécher ze sinn datt et an der Stoplëscht vun "einfache" Passwierder abegraff ass.
Statesch Analyse ass méi wéi Bugs ze fannen
Tatsächlech sinn d'Problemer praktesch duerch Analyse geléist vill méi breet. Iwwerhaapt, am Allgemengen, statesch Analyse ass all Verifizéierung vu Quellcoden, déi duerchgefouert ginn ier se lancéiert ginn. Hei sinn e puer Saachen déi Dir maache kënnt:
- Iwwerpréift Kodéierungsstil am breetste Sënn vum Wuert. Dëst beinhalt souwuel d'Formatéierung z'iwwerpréiwen, d'Sich no der Notzung vun eidelen/extra Klammern, d'Schwellen op Metriken ze setzen wéi d'Zuel vun de Linnen / d'cyclomatic Komplexitéit vun enger Method, etc. Am Java ass sou en Tool Checkstyle, am Python - flake8. Programmer vun dëser Klass ginn normalerweis "linters" genannt.
- Net nëmmen ausführbare Code kann analyséiert ginn. Ressourcedateien wéi JSON, YAML, XML, .properties kënnen (a sollen!) automatesch op Validitéit gepréift ginn. No allem ass et besser erauszefannen datt d'JSON Struktur gebrach ass wéinst e puer onpaarte Zitater an enger fréicher Stuf vun der automatescher Pull Request Verifizéierung wéi während Testausféierung oder Lafzäit? Entspriechend Tools si verfügbar: z.B. , .
- Kompilatioun (oder Parsing fir dynamesch Programméierungssproochen) ass och eng Zort statesch Analyse. Am Allgemengen sinn Compiler fäeg Warnungen ze produzéieren déi Probleemer mat der Quellcodequalitéit uginn a sollten net ignoréiert ginn.
- Heiansdo ass d'Kompilatioun méi wéi nëmmen ausführbare Code ze kompiléieren. Zum Beispill, wann Dir Dokumentatioun am Format hutt , dann am Moment wou et an HTML/PDF ëmgewandelt gëtt den AsciiDoctor Handler () kann Warnungen erausginn, zum Beispill iwwer futtis intern Linken. An dëst ass e gudde Grond d'Pull Request net mat Dokumentatiounsännerungen ze akzeptéieren.
- Spellchecking ass och eng Zort statesch Analyse. Utility ass fäeg Schreifweis net nëmmen an der Dokumentatioun ze kontrolléieren, awer och a Programmquellcodes (Kommentaren a literal) a verschiddene Programméierungssproochen, dorënner C/C++, Java a Python. E Schreiffehler an der User Interface oder Dokumentatioun ass och e Defekt!
- Konfiguratiounstester (iwwer wat se sinn - kuckt. и Berichter), obwuel se an enger Eenheetstest Runtime wéi Pytest ausgefouert ginn, sinn tatsächlech och eng Aart vu statesch Analyse, well se keng Quellcodes wärend hirer Ausféierung ausféieren.
Wéi Dir gesitt, spillt d'Sich no Bugs an dëser Lëscht déi mannst wichteg Roll, an alles anescht ass verfügbar andeems Dir gratis Open Source Tools benotzt.
Wéi eng vun dësen Aarte vu statesche Analyse sollt Dir an Ärem Projet benotzen? Natierlech, wat méi, wat besser! Den Haapt Saach ass et richteg ëmzesetzen, déi weider diskutéiert ginn.
Liwwerung Pipeline als Multi-Stage Filter a statesch Analyse als éischt Stuf
Déi klassesch Metapher fir kontinuéierlech Integratioun ass eng Pipeline, duerch déi d'Verännerunge fléissen, vu Quellcode Ännerungen bis zur Liwwerung bis zur Produktioun. D'Standard Sequenz vun Etappen an dëser Pipeline gesäit esou aus:
- statesch Analyse
- Zesummesetzung
- Eenheet Tester
- Integratioun Tester
- UI Tester
- manuell kontrolléieren
Ännerunge refuséiert an der Nth Etapp vun der Pipeline ginn net op Etapp N + 1 transferéiert.
Firwat genee esou an net anescht? Am Testdeel vun der Pipeline erkennen Tester déi bekannte Testpyramid.
Test Pyramid. Quell: Martin Fowler.
Um Enn vun dëser Pyramid sinn Tester déi méi einfach ze schreiwen, méi séier auszeféieren an net eng Tendenz hunn ze versoen. Dofir sollten et méi vun hinnen sinn, si sollten méi Code ofdecken an als éischt ausgefouert ginn. Am Top vun der Pyramid ass de Géigendeel wouer, sou datt d'Zuel vun Integratioun an UI Tester op den néidege Minimum reduzéiert ginn. D'Persoun an dëser Kette ass déi deierste, luesen an onzouverlässegste Ressource, sou datt hien um Enn ass a mécht d'Aarbecht nëmmen wann déi virdrun Etappe keng Mängel fonnt hunn. Wéi och ëmmer, déiselwecht Prinzipien gi benotzt fir eng Pipeline ze bauen an Deeler déi net direkt mam Test verbonne sinn!
Ech wéilt eng Analogie an der Form vun engem Multi-Stage Waasserfiltratiounssystem ubidden. Dreckeg Waasser (Ännerunge mat Mängel) gëtt op den Input geliwwert; um Ausgang musse mir propper Waasser kréien, an deem all ongewollte Verschmotzung eliminéiert gouf.
Multi-Etapp Filter. Quell:
Wéi Dir wësst, sinn d'Botzfiltere sou entworf datt all spéider Kaskade eng ëmmer méi fein Fraktioun vu Verschmotzung filtere kann. Zur selwechter Zäit hu méi gréisser Reinigungskaskaden méi héijen Duerchgang a méi niddreg Käschte. An eiser Analogie heescht dat datt Input Qualitéit Paarte méi séier sinn, manner Effort erfuerderen fir ze starten, a si selwer méi unpretentious an der Operatioun - an dat ass d'Sequenz an där se gebaut ginn. D'Roll vun der statescher Analyse, déi, wéi mir elo verstinn, fäeg sinn nëmmen déi gréissst Mängel ze läschen, ass d'Roll vum "Schlamm" Gitter am Ufank vun der Filterkaskade.
Statesch Analyse selwer verbessert d'Qualitéit vum Endprodukt net, sou wéi e "Schlammfilter" Waasser net drénkbar mécht. An awer, a Verbindung mat aneren Elementer vun der Pipeline, ass seng Wichtegkeet evident. Och wann an engem Multistage Filter d'Ausgangsstadien potenziell fäeg sinn alles opzehuelen wat d'Inputstadien maachen, ass et kloer wéi eng Konsequenzen aus engem Versuch eleng mat Feinreinigungsstadien ze maachen, ouni Inputstadien.
Den Zweck vun der "Schlamm Trap" ass fir spéider Kaskaden ze entlaaschten vu ganz gréisser Mängel. Zum Beispill, op e Minimum, d'Persoun, déi de Code iwwerpréift, sollt net ofgelenkt ginn duerch falsch formatéiert Code a Verstouss géint etabléiert Kodéierungsnormen (wéi extra Klammern oder ze déif nestéiert Filialen). Bugs wéi NPEs sollten duerch Eenheetstester gefaange ginn, awer wann och virum Test den Analysator eis weist datt e Feeler gebonnen ass ze geschéien, wäert dëst seng Fixéierung wesentlech beschleunegen.
Ech gleewen datt et elo kloer ass firwat d'statesch Analyse d'Qualitéit vum Produkt net verbessert wann se heiansdo benotzt gëtt, a soll dauernd benotzt ginn fir Ännerungen mat brutto Mängel ze filteren. D'Fro ob d'Benotzung vun engem statesche Analysator d'Qualitéit vun Ärem Produkt verbessert ass ongeféier gläich wéi d'Fro: "Gitt Waasser aus engem dreckegen Weier an Drénkqualitéit verbessert wann et duerch e Colander passéiert?"
Ëmsetzung an engem Legacy Projet
Eng wichteg praktesch Fro: wéi eng statesch Analyse an de kontinuéierleche Integratiounsprozess als "Qualitéitspaart" ëmzesetzen? Am Fall vun automateschen Tester ass alles offensichtlech: et gëtt eng Rei vun Tester, den Echec vun engem vun hinnen ass genuch Grond ze gleewen datt d'Versammlung net de Qualitéitspaart passéiert. E Versuch fir e Paart op déiselwecht Manéier ze installéieren baséiert op de Resultater vun enger statescher Analyse feelt: et ginn ze vill Analysewarnungen am Legacy Code, Dir wëllt se net komplett ignoréieren, awer et ass och onméiglech fir e Produkt ze verschécken just well et Analyser Warnungen enthält.
Wann Dir fir d'éischte Kéier benotzt, produzéiert den Analyser eng riesech Unzuel vun Warnungen op all Projet, déi grouss Majoritéit vun deenen net mat der richteger Funktioun vum Produkt verbonne sinn. Et ass onméiglech all dës Kommentaren op eemol ze korrigéieren, a vill sinn net néideg. No allem wësse mir datt eise Produkt als Ganzt funktionnéiert, och ier mir eng statesch Analyse agefouert hunn!
Als Resultat, vill sinn limitéiert op heiansdo Notzung vun statesch Analyse, oder benotzen se nëmmen am Informatiounen Modus, wann en Analyser Rapport einfach während Assemblée erausginn. Dëst ass gläichwäerteg mat der Verontreiung vun enger Analyse, well wa mir scho vill Warnungen hunn, da geet d'Optriede vun engem aneren (egal wéi sérieux) beim Code änneren onnotéiert.
Déi folgend Methode fir Qualitéitspaarten aféieren sinn bekannt:
- Eng Limit op d'Gesamtzuel vun den Warnungen setzen oder d'Zuel vun den Warnungen gedeelt duerch d'Zuel vun de Codelinnen. Dëst funktionnéiert schlecht, well sou e Paart fräi Ännerunge mat neie Mängel duerchgoe léisst, soulaang hir Limit net iwwerschratt ass.
- Fixéieren, zu engem bestëmmte Moment, all al Warnungen am Code wéi ignoréiert, a refuséiert ze bauen wann nei Warnungen optrieden. Dës Funktionalitéit gëtt vum PVS-Studio an e puer Online Ressourcen zur Verfügung gestallt, zum Beispill Codacy. Ech hat net d'Méiglechkeet am PVS-Studio ze schaffen, wat meng Erfahrung mat Codacy ugeet, hiren Haaptproblem ass datt d'Bestëmmung wat en "al" ass a wat en "nei" Feeler ass en zimlech komplexen Algorithmus deen net ëmmer funktionnéiert richteg, besonnesch wann Dateie staark geännert oder ëmbenannt ginn. A menger Erfahrung konnt Codacy nei Warnungen an enger Pull-Ufro ignoréieren, a gläichzäiteg net eng Pull-Ufro passéieren wéinst Warnungen déi net mat Ännerungen am Code vun engem bestëmmte PR verbonne sinn.
- Menger Meenung no ass déi effektivst Léisung déi am Buch beschriwwen "Ratchen Method". D'Basis Iddi ass, datt d'Zuel vun statesch Analyse Warnungen e Besëtz vun all Verëffentlechung ass, an nëmmen Ännerungen sinn erlaabt, datt d'total Zuel vun Warnungen net Erhéijung.
Ratchet
Et funktionnéiert esou:
- An der éischter Etapp gëtt e Rekord an de Metadaten iwwer d'Verëffentlechung vun der Unzuel vun Warnungen am Code gemaach, déi vun den Analysatoren fonnt goufen. Also, wann Dir upstream baut, schreift Äre Repository Manager net nëmmen "Verëffentlechung 7.0.2", mee "Verëffentlechung 7.0.2 mat 100500 Checkstyle Warnungen." Wann Dir en erweiderten Repository Manager benotzt (wéi Artifactory), sou Metadaten iwwer Är Verëffentlechung späicheren ass einfach.
- Elo all Pull Ufro, wann gebaut, vergläicht d'Zuel vun de resultéierende Warnungen mat der Unzuel vun den Warnungen, déi an der aktueller Verëffentlechung verfügbar sinn. Wann PR zu enger Erhéijung vun dëser Zuel féiert, da passéiert de Code net de Qualitéitspaart fir statesch Analyse. Wann d'Zuel vun den Warnungen erof geet oder net ännert, da passéiert et.
- Bei der nächster Verëffentlechung gëtt déi nei berechent Unzuel vun Warnungen erëm an de Verëffentlechungsmetadaten opgeholl.
Also lues a lues awer stänneg (wéi wann e Ratchet funktionnéiert), wäert d'Zuel vun den Warnungen op Null tendéieren. Natierlech kann de System täuscht ginn andeems Dir eng nei Warnung agefouert hutt, awer déi vun engem aneren korrigéiert. Dëst ass normal, well iwwer eng laang Distanz et Resultater gëtt: Warnungen korrigéiert, als Regel, net individuell, mä an enger Grupp vun engem bestëmmten Typ op eemol, an all liicht eraushuelbare Warnungen ganz séier eliminéiert.
Dës Grafik weist d'total Zuel vun Checkstyle Warnungen fir sechs Méint Operatioun vun esou engem "ratchet" op . D'Zuel vun den Warnungen ass ëm eng Uerdnung vun der Gréisst erofgaang, an dat ass natierlech geschitt, parallel mat der Produktentwécklung!
Ech benotzen eng modifizéiert Versioun vun dëser Method, getrennt zielen Warnungen duerch Projet Modul an Analyse Outil, doraus zu engem YAML Fichier mat Build Metadaten, datt esou ausgesäit:
celesta-sql:
checkstyle: 434
spotbugs: 45
celesta-core:
checkstyle: 206
spotbugs: 13
celesta-maven-plugin:
checkstyle: 19
spotbugs: 0
celesta-unit:
checkstyle: 0
spotbugs: 0
An all fortgeschratt CI System kann Ratchet fir all statesch Analyse Tools implementéiert ginn ouni op Plugins an Drëtt Partei Tools ze vertrauen. All Analysator produzéiert säin eegene Bericht an engem einfachen Text oder XML Format deen einfach ze analyséieren ass. Alles wat bleift ass déi néideg Logik am CI Skript ze schreiwen. Dir kënnt gesinn wéi dëst an eisen Open Source Projeten ëmgesat gëtt baséiert op Jenkins an Artifactory oder . Béid Beispiller hänke vun der Bibliothéik of : Method countWarnings() zielt xml Tags an Dateien generéiert vu Checkstyle a Spotbugs op déi üblech Manéier, an compareWarningMaps() implementéiert déi selwecht Ratchet, e Feeler geheien wann d'Zuel vun den Warnungen an enger vun de Kategorien eropgeet.
Eng interessant Ëmsetzung vum "Ratchet" ass méiglech fir d'Schreifweis vu Kommentaren, Textwuertwierder an Dokumentatioun mat Aspell ze analyséieren. Wéi Dir wësst, wann Dir d'Schreifweis iwwerpréift, sinn net all Wierder onbekannt am Standardwörterbuch falsch; si kënnen an d'Benotzerwörterbuch bäigefüügt ginn. Wann Dir e personaliséiert Wierderbuch Deel vum Quellcode vum Projet maacht, da kann d'Schreifqualitéitspaart esou formuléiert ginn: Aspell mat engem Standard a personaliséiert Wierderbuch lafen fannen keng Schreiffeeler.
Iwwer d'Wichtegkeet fir d'Analyseversioun ze fixéieren
Als Conclusioun ass de Punkt ze notéieren datt egal wéi Dir Analyse an Är Liwwerungspipeline implementéiert, d'Versioun vum Analyser muss fixéiert ginn. Wann Dir den Analyser erlaabt spontan ze aktualiséieren, da wann Dir déi nächst Pull-Ufro montéiert, kënnen nei Mängel "opstoen", déi net mat Code Ännerungen am Zesummenhang sinn, awer mat der Tatsaach verbonne sinn datt den neien Analyser einfach méi Mängel ze fannen ass - an dëst wäert Äre Prozess briechen fir Pull-Ufroen z'akzeptéieren. Upgrade vun engem Analysator soll eng bewosst Handlung sinn. Wéi och ëmmer, steif Fixatioun vun der Versioun vun all Montagekomponent ass allgemeng eng noutwendeg Fuerderung an en Thema fir eng separat Diskussioun.
Conclusiounen
- Statesch Analyse fënnt keng Bugs fir Iech a wäert d'Qualitéit vun Ärem Produkt net verbesseren als Resultat vun enger eenzeger Applikatioun. E positiven Effekt op d'Qualitéit kann nëmmen duerch seng konstante Gebrauch während der Liwwerung Prozess erreecht ginn.
- Bugs ze fannen ass guer net d'Haaptaufgab vun der Analyse; déi grouss Majoritéit vun nëtzlechen Funktiounen sinn an Opensource Tools verfügbar.
- Ëmsetzen Qualitéit Paarte baséiert op de Resultater vun statesch Analyse op der éischter Etapp vun der Liwwerung Pipeline, mat engem "Ratchet" fir Legacy Code.
Referenze
- Rapport iwwer verschidde Methode vun der Code Analyse (net nëmme statesch!)
Source: will.com