{"id":32848,"date":"2019-10-31T21:49:16","date_gmt":"2019-10-31T18:49:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi\/"},"modified":"2019-10-31T21:49:16","modified_gmt":"2019-10-31T18:49:16","slug":"vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi","title":{"rendered":"Rakendage staatiline anal\u00fc\u00fcs protsessi, mitte \u00e4rge otsige selle abil vigu","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Selle artikli kirjutamiseks inspiratsiooni andis mulle suur hulk statilise anal\u00fc\u00fcsi materjale, mis silma hakkasid. Esiteks, see on <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/company\/pvs-studio\/blog\/\">PVS-studio blogi<\/a><\/noindex>, mis aktiivselt edendab end Habras, osaledes nende t\u00f6\u00f6riista avatud l\u00e4htekoodiga projektides leiduvate vigade \u00fclevaadetes. Hiljuti on PVS-studio realiseerinud <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/company\/pvs-studio\/blog\/436496\/\">Java toe<\/a><\/noindex>, ja loomulikult ei saanud IntelliJ IDEA arendajad, kelle sisseehitatud anal\u00fcsaator on t\u00e4na t\u00f5en\u00e4oliselt k\u00f5ige arenenum Java jaoks, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/company\/JetBrains\/blog\/436278\/\">\u00fcmber j\u00e4\u00e4da<\/a><\/noindex>. <\/p>\n<p>Selliste \u00fclevaadete lugemisel tekib tunne, et tegu on maagilise eliksiiriga: vajuta nuppu ja voil\u00e0 \u2014 defektide nimekiri on su silme ees. Tundub, et anal\u00fcsaatorite t\u00e4iustamisel tuvastatakse automaatselt \u00fcha rohkem ja rohkem vigu ning neid roboteid skaneeritud tooted muutuvad meiepoolse vaevata \u00fcha paremaks.<\/p>\n<p>Aga maagilisi eliksiire ei ole olemas. Soovin r\u00e4\u00e4kida sellest, millest tavaliselt ei r\u00e4\u00e4gita postitustes, mis \u00fctlevad \"siin on, milliseid asju v\u00f5ib meie robot leida\": mida anal\u00fcsaatorid ei suuda teha, milline on nende t\u00f5eline roll ja koht tarkvara tarnimise protsessis ning kuidas neid \u00f5igesti rakendada.<\/p>\n<p><img decoding=\"async\" alt=\"Rakendage staatiline anal\u00fc\u00fcs protsessi, mitte \u00e4rge otsige selle abil vigu\" src=\"\/wp-content\/uploads\/2019\/05\/2a0339f10edcaed3310676ab6e2f975a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Hammasratas (allikas: <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%A5%D1%80%D0%B0%D0%BF%D0%BE%D0%B2%D0%BE%D0%B9_%D0%BC%D0%B5%D1%85%D0%B0%D0%BD%D0%B8%D0%B7%D0%BC#\/media\/File:Sperrklinke_Schema.svg\">Wikipeedia<\/a><\/noindex>).<\/i><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>) Mida statilised anal\u00fcsaatorid kunagi ei suuda<\/h2>\n<p>\nMis on, praktiliselt vaadates, l\u00e4htekoodi anal\u00fc\u00fcs? Me esitame teatud l\u00e4htekoodid ning saame l\u00fchikese aja jooksul (k\u00f5vasti l\u00fchem aeg kui testide k\u00e4itamine) m\u00f5ned \u00fclevaated meie s\u00fcsteemi kohta. P\u00f5him\u00f5tteline ja matemaatiliselt \u00fcletamatu piirang on see, et me saame sel viisil vaid \u00fcsna kitsast teabe klassi.<\/p>\n<p>Kuulsaim n\u00e4ide probleemist, mida ei saa lahendada staatilise anal\u00fc\u00fcsi abil on <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Halting_problem\">peatuse probleem<\/a><\/noindex>: see on teoreem, mis t\u00f5estab, et ei ole v\u00f5imalik v\u00e4lja t\u00f6\u00f6tada \u00fcldist algoritmi, mis m\u00e4\u00e4raks programmeri l\u00e4htekoodi p\u00f5hjal, kas see satub l\u00f5ksu v\u00f5i l\u00f5petab m\u00f5istliku aja jooksul. Selle teoreemi laiendus on <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Rice%27s_theorem\">Reysi teoreem<\/a><\/noindex>, v\u00e4itmine, et on olemas algoritmiliselt lahendamatu probleem, mis m\u00e4\u00e4rab, kas mingi programm arvutab mingit mitte triviaalset omadust arvutavatest funktsioonidest. N\u00e4iteks ei ole v\u00f5imalik kirjutada anal\u00fcsaatorit, mis suudaks igast l\u00e4htekoodist m\u00e4\u00e4rata, kas anal\u00fc\u00fcsitav programm on algoritmi rakendamine, mis arvutab n\u00e4iteks tervete arvude ruutu.<\/p>\n<p>Seega on staatiliste anal\u00fcsaatorite funktsionaalsusel \u00fcletamatud piirangud. Staatiline anal\u00fcsaator ei suuda kunagi k\u00f5igis olukordades kindlaks teha selliseid asju nagu n\u00e4iteks \u201enull pointer exception\u201d nendes keeltes, mis lubavad nulli v\u00e4\u00e4rtust, v\u00f5i igas olukorras kindlaks teha \u201eattribute not found\u201d nendes keeltes, kus on d\u00fcnaamiline t\u00fcpiseerimine. K\u00f5ik, mida parim staatiline anal\u00fcsaator suudab, on tuvastada erandeid, mille arv k\u00f5ikide v\u00f5imalike probleemide seas teie l\u00e4htekoodis on \u00fclepingutamine, meres tilgake.<\/p>\n<h2>Staatiline anal\u00fc\u00fcs ei ole vigade otsimine<\/h2>\n<p>\n\u00dclaltoodust j\u00e4reldub: staatiline anal\u00fc\u00fcs ei ole vahend programmide defektide arvu v\u00e4hendamiseks. Julgen v\u00e4ita, et kui seda esmakordselt teie projektis rakendada, leiab ta koodist \u201ehuvitavaid\u201d kohti, kuid t\u00f5en\u00e4oliselt ei tuvastada \u00fchtki defekti, mis m\u00f5jutaks teie programmi t\u00f6\u00f6 kvaliteeti.<\/p>\n<p>Automaatsete anal\u00fcsaatorite leidudest on h\u00e4mmastavad n\u00e4ited, kuid \u00e4rge unustage, et need n\u00e4ited on leitud, skannides suurt hulka suures koguses koodibaase. Samuti nagu h\u00e4kkerid, kellel on v\u00f5imalus testida mitmeid lihtsaid paroole paljude kontode puhul, leiavad nad l\u00f5puks need kontod, kus on lihtne parool.<\/p>\n<p>Kas see t\u00e4hendab, et staatilist anal\u00fc\u00fcsi ei tasu rakendada? Loomulikult mitte! Ja t\u00e4pselt sama p\u00f5hjus, miks tasub kontrollida iga uut parooli, et see ei satuks \u201elihtsate\u201d paroolide mustrisse.<\/p>\n<h2>Staatiline anal\u00fc\u00fcs on rohkem kui vigade otsimine<\/h2>\n<p>\nTegelikult on anal\u00fc\u00fcsiga praktiliselt lahendatavad probleemid palju laiemad. L\u00f5ppkokkuv\u00f5ttes on staatiline anal\u00fc\u00fcs j\u00e4rgmine: igasugune l\u00e4htefailide kontrollimine, mis toimub enne nende k\u00e4ivitamist. Siin on m\u00f5ned asjad, mida saab teha:<\/p>\n<ul>\n<li> Koodistandardite kontrollimine laiemas m\u00f5ttes. See h\u00f5lmab nii vormindamise kontrolli kui ka t\u00fchjade\/\u00fclesannete sulgude otsimist, k\u00fcnniste seadmist m\u00f5\u00f5dikutele nagu ridade arv\/l\u00e4bivaatamiste keerukuse tase jne \u2013 k\u00f5ike, mis potentsiaalselt raskendab koodi loetavust ja hooldamist. Java puhul on selleks t\u00f6\u00f6riistaks Checkstyle, Pythonis aga flake8. Selliseid programme nimetatakse tavaliselt \"lintereiks\".<\/li>\n<li>Anal\u00fc\u00fcsitav ei ole ainult k\u00e4ivitatav kood. Ressurssfailid, nagu JSON, YAML, XML, .properties, v\u00f5ivad (ja peavad!) olema automaatselt kontrollitud kehtivuse osas. L\u00f5ppude l\u00f5puks on parem teada saada, et mingite paaritute jutum\u00e4rkide t\u00f5ttu on JSON-struktuur rikkunud varakult Pull Requesti automaatse kontrollimise k\u00e4igus, kui testimisel v\u00f5i t\u00f6\u00f6 ajal? Vastavad t\u00f6\u00f6riistad on olemas: n\u00e4iteks, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/adrienverge\/yamllint\">YAMLlint<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/zaach\/jsonlint\">JSONLint<\/a><\/noindex>.<\/li>\n<li> Kompileerimine (v\u00f5i parsimine d\u00fcnaamilistes programmeerimiskeeltes) on samuti statilise anal\u00fc\u00fcsi liik. Reeglina suudavad kompilaatorid anda hoiatusi, mis viitavad probleemidele l\u00e4htekoodi kvaliteediga, ja neid ei tohiks ignoreerida.<\/li>\n<li>M\u00f5nikord ei ole kompileerimine ainult k\u00e4ivitatava koodi kompileerimine. N\u00e4iteks, kui teie dokumentatsioon on vormingus <noindex><a rel=\"nofollow\" href=\"https:\/\/asciidoctor.org\/\">AsciiDoctor<\/a><\/noindex>, siis AsciiDoctor (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/asciidoctor\/asciidoctor-maven-plugin\">Maven plugin<\/a><\/noindex>) v\u00f5ib muuta selle HTML-iks\/PDF-iks ja anda hoiatusi, n\u00e4iteks rikutud sisemiste linkide kohta. Ja see on oluline p\u00f5hjus, et mitte aktsepteerida Pull Requesti muudatustega dokumentatsioonis.<\/li>\n<li>\u00d5igekirjakontroll on samuti statilise anal\u00fc\u00fcsi liik. Utiliit <noindex><a rel=\"nofollow\" href=\"http:\/\/aspell.net\/\">aspell<\/a><\/noindex> on v\u00f5imeline kontrollima \u00f5igekirja mitte ainult dokumentatsioonis, vaid ka programmide l\u00e4htekoodis (kommentaarides ja v\u00e4\u00e4rtustes) erinevates programmeerimiskeeltes, sealhulgas C\/C++, Java ja Python. \u00d5igekirja viga kasutajaliideses v\u00f5i dokumentatsioonis on samuti defekt!<\/li>\n<li>Konfiguratsioonitestid (mida see t\u00e4hendab \u2013 vt. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=KaeEjsAjV6A&amp;index=30&amp;list=PLsVTVVvrKX9tuYyCtL8mASB6IOaa-kRCA&amp;t=0s\">see<\/a><\/noindex> ja <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=Tk_nmV-mWOA\">see<\/a><\/noindex> aruandeid), kuigi neid t\u00e4idetakse modulaarsete testide k\u00e4itamisest nagu pytest, on tegelikult ka statilise anal\u00fc\u00fcsi liik, kuna nad ei t\u00e4ida l\u00e4htekoodi oma t\u00e4itmise k\u00e4igus.<\/li>\n<\/ul>\n<p>\nNagu n\u00e4eme, on veaotsing selle nimekirja k\u00f5ige v\u00e4hem oluline roll, samas kui k\u00f5ik muu on kergesti k\u00e4tte saadav tasuta avatud l\u00e4htekoodi t\u00f6\u00f6riistade abil.<\/p>\n<p>Millised nendest staatilise anal\u00fc\u00fcsi t\u00fc\u00fcbist tuleks teie projektis rakendada? Muidugi, k\u00f5ik, mida rohkem - seda parem! Peamine on see \u00f5igesti rakendada, millest r\u00e4\u00e4gitakse edasi.<\/p>\n<h2>Tarnetoru kui mitmestastline filter ja staatiline anal\u00fc\u00fcs kui selle esimene kaskaad<\/h2>\n<p>\nPideva integreerimise klassikaline metafoor on voolikutoru (pipeline), mille kaudu liiguvad muudatused - alates l\u00e4htekoodist kuni tootmisse toimetamiseni. Selle konveieri standardne etappide jada n\u00e4eb v\u00e4lja j\u00e4rgmine:<\/p>\n<ol>\n<li>staatiline anal\u00fc\u00fcs<\/li>\n<li>kompileerimine<\/li>\n<li>moodulitestid<\/li>\n<li>integreerimistestid<\/li>\n<li>kasutajaliidese testid<\/li>\n<li>k\u00e4ed-\u00fclesanne kontroll<\/li>\n<\/ol>\n<p>\nKonveieril N-ndal etapil tagasi l\u00fckatud muudatused ei edastata etapile N+1.<\/p>\n<p>Miks just nii, mitte teisiti? Testimise osas konveieril saavad testijad teada laialdaselt tuntud testimise p\u00fcramiidist.<\/p>\n<p><img decoding=\"async\" alt=\"Rakendage staatiline anal\u00fc\u00fcs protsessi, mitte \u00e4rge otsige selle abil vigu\" src=\"\/wp-content\/uploads\/2019\/05\/f155307fd4c1663800843c394098ea6f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Testimise p\u00fcramiid. Allikas: <noindex><a rel=\"nofollow\" href=\"https:\/\/martinfowler.com\/bliki\/TestPyramid.html\">artikkel<\/a><\/noindex> Martin Fowler.<\/i><\/p>\n<p>Selle p\u00fcramiidi alumises osas on testid, mida on lihtsam kirjutada, mis t\u00e4idetakse kiiremini ja millel ei ole valeh\u00e4irete kalduvust. Seet\u00f5ttu peaks neid olema rohkem, nad peaksid katma rohkem koodi ja neid tuleks t\u00e4ita esimesena. P\u00fcramiidi \u00fclaosas on olukord vastupidine, seega peaks integreerimistestide ja kasutajaliidese testide arv olema v\u00e4hendatud vajalikule miinimumile. Inimene selles ahelas on k\u00f5ige kallim, aeglasem ja ebausaldusv\u00e4\u00e4rsem ressurss, seet\u00f5ttu on ta viimases positsioonis ja teeb t\u00f6\u00f6d ainult siis, kui eelnevad etapid ei leidnud defekte. Kuid selliste p\u00f5him\u00f5tete kohaselt ehitatakse konveier ka osades, mis ei ole otseselt seotud testimisega!<\/p>\n<p>Tahaksin pakkuda analoogiat mitmestastilise vee filtreerimise s\u00fcsteemiga. Sisse saavad m\u00e4\u00e4rdunud vesi (defektidega muudatused), v\u00e4ljundis peame saama puhtat vett, kus k\u00f5ik soovimatud saasteained on eemaldatud.<\/p>\n<p><img decoding=\"async\" alt=\"Rakendage staatiline anal\u00fc\u00fcs protsessi, mitte \u00e4rge otsige selle abil vigu\" src=\"\/wp-content\/uploads\/2019\/05\/76b5be8f13d55c16970d67e09767a045.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Mitmestaline filter. Allikas: <noindex><a rel=\"nofollow\" href=\"https:\/\/commons.wikimedia.org\/wiki\/File:Milli-Q_Water_filtration_station.JPG\">Wikimedia Commons<\/a><\/noindex><\/i><\/p>\n<p>Nagu teada, projekteeritakse puhastusfilter nii, et iga j\u00e4rgmine kaskaad suudab eraldada \u00fcha v\u00e4iksema fraktsiooni saasteaineid. Seejuures on Coarse-filter kaskaadidel suurem l\u00e4bilaskev\u00f5ime ja madalam hind. Meie analoogias t\u00e4hendab see, et sisendquality gates'on suurema j\u00f5udlusega, vajavad v\u00e4hem pingutust k\u00e4ivitamiseks ja on ise t\u00f6\u00f6re\u017eiimis n\u00f5udlikumad \u2014 ja just sellises j\u00e4rjestuses nad on paigutatud. Staatilise anal\u00fc\u00fcsi roll, mis, nagu me n\u00fc\u00fcd m\u00f5istame, suudab eraldada vaid k\u00f5ige j\u00e4medamad vead \u2014 on nagu riba<\/p>\n<p>Staatiline anal\u00fc\u00fcs iseenesest ei paranda l\u00f5ppkvaliteeti, nagu<\/p>\n<p>Riba eesm\u00e4rk on vabastada j\u00e4rgmised kaskaadid k\u00f5ige j\u00e4medamate vigade p\u00fc\u00fcdmisest. N\u00e4iteks ei tohiks code review tegija v\u00e4hemalt t\u00e4helepanu juhtida vale vorminduse ega kehtestatud kodeerimisnormide rikkumise (nt liigsete sulgude v\u00f5i liiga s\u00fcgavate harustikeringide). NPE-viisid peaks p\u00fc\u00fcdma moodulitestid, kuid kui anal\u00fcsaator juba enne testi \u00fctleb meile, et t\u00f5rge tuleb kindlasti esile \u2014 kiirendab see oluliselt selle parandamist.<\/p>\n<p>Arvan, et n\u00fc\u00fcd on selge, miks staatiline anal\u00fc\u00fcs ei paranda toote kvaliteeti, kui seda rakendatakse episoodiliselt, ja peaks olema pidevalt rakendatud, et t\u00f5rjuda muudatusi, millel on j\u00e4medad vead. K\u00fcsimus, kas staatilise anal\u00fcsaatori rakendamine parandab teie toote kvaliteeti, on ligikaudu v\u00f5rreldav k\u00fcsimusega, kas<\/p>\n<h2>J\u00e4tkamine p\u00e4randi projekti<\/h2>\n<p>\nOluline praktiline k\u00fcsimus: kuidas rakendada staatilist anal\u00fc\u00fcsi pideva integreerimise protsessis kui \"quality gate\"? Automaatsete testide puhul on k\u00f5ik selge: on olemas testide kogum, mille eba\u00f5nnestumine on piisav p\u00f5hjus, et arvata, et ehitus ei l\u00e4inud quality gate'ist l\u00e4bi. Katse kehtestada gate staatilise anal\u00fc\u00fcsi tulemuste p\u00f5hjal eba\u00f5nnestub: legacy-koodil on anal\u00fc\u00fcsi hoiatuste arv liiga suur, neid ei saa t\u00e4ielikult ignoreerida, kuid toote tarnimist on v\u00f5imatu peatada ainult seet\u00f5ttu, et selles on anal\u00fcsaatori hoiatuseid.<\/p>\n<p>Esimese rakendamise korral annab anal\u00fcsaator igasugustes projektides tohutul hulgal hoiatuseid, mille enamiku seos toote \u00f5igete funktsioonidega on t\u00fchine. K\u00f5iki neid m\u00e4rkusi korraga parandada ei ole v\u00f5imalik, ja paljusid ei peagi parandama. L\u00f5ppude l\u00f5puks, me ju teame, et meie toode t\u00f6\u00f6tab kokkuv\u00f5ttes kenasti, ja enne staatilise anal\u00fc\u00fcsi rakendamist!<\/p>\n<p>Kokkuv\u00f5ttes piirdutakse paljudes juhtudes staatilise anal\u00fc\u00fcsi episoodilise kasutamisega v\u00f5i kasutatakse seda vaid teavitamise re\u017eiimis, kus ehitamisel v\u00e4ljastatakse lihtsalt anal\u00fcsaatori aruanne. See on ekvivalent kogu anal\u00fc\u00fcsi puudumisele, sest kui meil on juba hulk hoiatuseid, j\u00e4\u00e4b koodi muutmisel veel \u00fche (kas v\u00f5i t\u00f5sise) hoiatuse ilmumine m\u00e4rkamatuks.<\/p>\n<p>On teada j\u00e4rgmised meetodid quality gate'ide seadmiseks:<\/p>\n<ul>\n<li>Koguhulga hoiatuste v\u00f5i hoiatuste arvu, mis jagatakse koodiread, piirm\u00e4\u00e4ra seadmine. See t\u00f6\u00f6tab halvasti, kuna selline gate laseb vabalt l\u00e4bi muudatused, kus on uued vead, kuni nende limiit on \u00fcletatud.<\/li>\n<li>Koodi k\u00f5igi vanade hoiatuste fikseerimine kindlal hetkel kui ignoreerituks, ja uute hoiatuste ilmnemisel buildiprotsessi keeldumine. Sellist funktsionaalsust pakuvad PVS-studio ja m\u00f5ned veebiteenused, n\u00e4iteks Codacy. Ma pole PVS-studios t\u00f6\u00f6tanud, aga minu kogemus Codacyga n\u00e4itab, et nende suurim probleem on see, et m\u00e4\u00e4rata, mis on 'vana' ja mis on 'uus' viga - see on \u00fcsna keeruline ja mitte alati \u00f5igesti toimiv algoritm, eriti kui failid muutuvad v\u00f5i on \u00fcmber nimetatud. Minu m\u00e4letamist m\u00f6\u00f6da v\u00f5is Codacy j\u00e4tta uued hoiatused pull requestis t\u00e4helepanuta, samas kui nad keeldusid pull requestist hoiatuste t\u00f5ttu, mis ei olnud seotud selle PR-i koodimuudatustega.<\/li>\n<li>Minu arvates on k\u00f5ige t\u00f5husam lahendus see, mis on toodud raamatus <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Continuous-Delivery-Deployment-Automation-Addison-Wesley\/dp\/0321601912\">Continuous Delivery<\/a><\/noindex> \u00abratcheting\u00bb meetod. Peamine idee seisneb selles, et iga v\u00e4ljaande omaduseks on staatilise anal\u00fc\u00fcsi hoiatuste arv, ja lubatud on vaid sellised muudatused, mis ei suurenda \u00fcldiselt hoiatuste arvu.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Ratta mehhanism<\/h2>\n<p>\nSee t\u00f6\u00f6tab j\u00e4rgmiselt:<\/p>\n<ol>\n<li>Esialgses etapis pannakse v\u00e4ljaande metadatas kirja hoiatuste arv koodis, mille anal\u00fcsaatorid on leidnud. Nii et kui p\u00f5hilist haru builditakse, registreeritakse teie repoteerimishalduris mitte lihtsalt 'v\u00e4ljaanne 7.0.2', vaid 'v\u00e4ljaanne 7.0.2, mis sisaldab 100500 Checkstyle-hoiatust'. Kui kasutate arenenud repoteerimishaldurit (n\u00e4iteks Artifactory), on selliste metadatade s\u00e4ilitamine teie v\u00e4ljaande kohta lihtne.<\/li>\n<li>N\u00fc\u00fcd iga pull request buildimise ajal v\u00f5rdleb saadud hoiatuste arvu praeguses v\u00e4ljaandes oleva arvuga. Kui PR toob kaasa selle arvu suurenemise, siis kood ei l\u00e4bige kvaliteeditesti staatilise anal\u00fc\u00fcsi osas. Kui hoiatuste arv v\u00e4heneb v\u00f5i ei muutu, siis see l\u00e4bib.<\/li>\n<li>J\u00e4rgmise v\u00e4ljaande puhul pannakse uuesti arvestatud hoiatuste arv v\u00e4ljaande metadatas kirja.<\/li>\n<\/ol>\n<p>\nNii v\u00e4hehaaval, kuid j\u00e4rjepidevalt (nagu t\u00f6\u00f6tades ratta kerimismehhanismiga) hakkab hoiatuste arv suunduma nulli. Muidugi saab s\u00fcsteemi petta, sisestades uue hoiatusena, kuid parandades kellegi teise. See on normaalne, kuna pikaajaliselt toob see tulemusi: hoiatused parandatakse tavaliselt mitte \u00fckshaaval, vaid kohe teatud t\u00fc\u00fcpi r\u00fchmana, ja k\u00f5ik kergesti k\u00f5rvaldatavad hoiatused kaovad \u00fcsna kiiresti.<\/p>\n<p>Sellel joonisel on n\u00e4idatud Checkstyle'i hoiatuste koguarv kuue kuu jooksul sellise \u201eratta\u201d t\u00f6\u00f6 ajal <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/CourseOrchestra\/celesta\">\u00fches meie OpenSource projektist<\/a><\/noindex>. Hoiatuste arv v\u00e4henes kordades, ning see juhtus loomulikult, koos toote arendamisega!<\/p>\n<p><img decoding=\"async\" alt=\"Rakendage staatiline anal\u00fc\u00fcs protsessi, mitte \u00e4rge otsige selle abil vigu\" src=\"\/wp-content\/uploads\/2019\/05\/9529bb2fb32187057088e8d2c4203333.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKatan selle meetodi muudetud versiooni, lugedes hoiatuseid eraldi projekti moodulite ja anal\u00fc\u00fcsit\u00f6\u00f6riistade l\u00f5ikes, genereeritud YAML-fail metaandmetega koostamise kohta n\u00e4eb v\u00e4lja umbes selline:<\/p>\n<pre><code class=\"plaintext\">celesta-sql:\n  checkstyle: 434\n  spotbugs: 45\ncelesta-core:\n  checkstyle: 206\n  spotbugs: 13\ncelesta-maven-plugin:\n  checkstyle: 19\n  spotbugs: 0\ncelesta-unit:\n  checkstyle: 0\n  spotbugs: 0\n<\/code><\/pre>\n<p>\nIgas arenenud CI-s\u00fcsteemis saab \u201eratast\u201d rakendada mistahes staatiliste anal\u00fc\u00fcsit\u00f6\u00f6de jaoks, toetudes mitte pistikprogrammidele ega kolmandate osapoolte t\u00f6\u00f6riistadele. Iga anal\u00fcsaator genereerib oma aruande lihttekstiformaadis v\u00f5i XML-formaadis, mida on lihtne anal\u00fc\u00fcsida. J\u00e4\u00e4b vaid kirjutada vajalik loogika CI-skripti. Kuidas see on meie open source projektides Jenkins'i ja Artifactory baasil teostatud, saad vaadata <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/CourseOrchestra\/2bass\/blob\/dev\/Jenkinsfile\">siin<\/a><\/noindex> v\u00f5i <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/CourseOrchestra\/celesta\/blob\/dev\/Jenkinsfile\">siin<\/a><\/noindex>. M\u00f5lemad n\u00e4ited s\u00f5ltuvad raamatukogust <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/inponomarev\/ratchetlib\">ratchetlib<\/a><\/noindex>: meetod <code>countWarnings()<\/code> loendab tavaliselt xml-silte failides, mille genereerivad Checkstyle ja Spotbugs, ning <code>compareWarningMaps()<\/code> rakendab selle \u201eratta\u201d, visates vea juhul, kui hoiatusi m\u00f5nes kategoorias on rohkem.<\/p>\n<p>Huvitav \u00abratta\u00bb teostuse variant on kommenteerimise, tekstiliteraalide ja dokumentatsiooni \u00f5igekirja kontrollimise anal\u00fc\u00fcs aspelliga. Nagu teada, ei ole \u00f5igekirjakontrolli k\u00e4igus k\u00f5ik tundmatud standardileksikonile s\u00f5nad valed, need v\u00f5ivad olla lisatud kasutaja s\u00f5nastikku. Kui teha kasutaja s\u00f5nastik projekti l\u00e4htekoodi osaks, siis v\u00f5ib \u00f5igekirjakontrolli kvaliteedi t\u00f5kendi s\u00f5nastada j\u00e4rgmiselt: aspelli k\u00e4itamine standard- ja kasutaja s\u00f5nastikuga. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/CourseOrchestra\/celesta\/blob\/271dcfc8dc3ad65ac2d1dcaa39b7fd3ea8fb5891\/Jenkinsfile#L36\">ei tohi<\/a><\/noindex> leida \u00f5igekirjavigu.<\/p>\n<h2>Anal\u00fcsaatori versiooni fikseerimise t\u00e4htsus<\/h2>\n<p>\nKokkuv\u00f5ttes tuleb m\u00e4rkida j\u00e4rgmist: \u00fcksk\u00f5ik kuidas te anal\u00fc\u00fcsi oma tarnetorusse rakendate, peab anal\u00fcsaatori versioon olema fikseeritud. Kui lubada anal\u00fcsaatori automaatne uuendamine, v\u00f5ivad j\u00e4rgmise pull requests'i koondamisel \u00abilma j\u00e4\u00e4da\u00bb uued defektid, mis ei ole seotud koodi muutmisega, vaid sellega, et uus anal\u00fcsaator suudab lihtsalt leida rohkem defekte - ja see rikub teie pull requests'i vastuv\u00f5tu protsessi. Anal\u00fcsaatori uuendus peab olema teadlik tegu. Siiski, iga ehituskomponendi versiooni range fikseerimine on \u00fcldiselt vajalik n\u00f5ue ja see on eraldi vestlusteema.<\/p>\n<h2>J\u00e4reldused<\/h2>\n<p><\/p>\n<ul>\n<li>Statistiline anal\u00fc\u00fcs ei leia teile vigu ja ei paranda teie toote kvaliteeti \u00fche korra rakendamise tulemusena. Positiivne efekt kvaliteedile tekib ainult pideva rakendamise l\u00e4bi tarnimisprotsessi.<\/li>\n<li>Vigade otsimine ei ole anal\u00fc\u00fcsi peamine eesm\u00e4rk, enamus kasulikest funktsioonidest on kergesti k\u00e4ttesaadavad avatud l\u00e4htekoodiga t\u00f6\u00f6riistades.<\/li>\n<li>Rakendage kvaliteedi t\u00f5kked statistilise anal\u00fc\u00fcsi tulemuste p\u00f5hjal tarnetoru esimesel etapil, kasutades \u00abratast\u00bb legacy-koodi jaoks.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Viidatud lingid<\/h2>\n<p><\/p>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Continuous-Delivery-Deployment-Automation-Addison-Wesley\/dp\/0321601912\">Continuous Delivery<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=8Cx3LHNjI24\">A. Kudrjavtsev: Programmi anal\u00fc\u00fcs: kuidas m\u00f5ista, et oled hea programmeerija<\/a><\/noindex> ettekanne erinevatest koodianal\u00fc\u00fcsi meetoditest (mitte ainult statistilistest!)<\/li>\n<\/ol>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/436868\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u044d\u0442\u0443 \u0441\u0442\u0430\u0442\u044c\u044e \u043c\u0435\u043d\u044f \u0441\u043f\u043e\u0434\u0432\u0438\u0433\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u043e \u0441\u0442\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0430\u043d\u0430\u043b\u0438\u0437\u0435, \u0432\u0441\u0451 \u0447\u0430\u0449\u0435 \u043f\u043e\u043f\u0430\u0434\u0430\u044e\u0449\u0438\u0445\u0441\u044f \u043d\u0430 \u0433\u043b\u0430\u0437\u0430. \u0412\u043e-\u043f\u0435\u0440\u0432\u044b\u0445, \u044d\u0442\u043e \u0431\u043b\u043e\u0433 PVS-studio, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u043f\u0440\u043e\u0434\u0432\u0438\u0433\u0430\u0435\u0442 \u0441\u0435\u0431\u044f \u043d\u0430 \u0425\u0430\u0431\u0440\u0435 \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 \u043e\u0431\u0437\u043e\u0440\u043e\u0432 \u043e\u0448\u0438\u0431\u043e\u043a, \u043d\u0430\u0439\u0434\u0435\u043d\u043d\u044b\u0445 \u0438\u0445 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0432 \u043f\u0440\u043e\u0435\u043a\u0442\u0430\u0445 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u043a\u043e\u0434\u043e\u043c. \u041d\u0435\u0434\u0430\u0432\u043d\u043e PVS-studio \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043b\u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0443 Java, \u0438, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0438 IntelliJ IDEA, \u0447\u0435\u0439 \u0432\u0441\u0442\u0440\u043e\u0435\u043d\u043d\u044b\u0439 \u0430\u043d\u0430\u043b\u0438\u0437\u0430\u0442\u043e\u0440 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f, \u043d\u0430\u0432\u0435\u0440\u043d\u043e\u0435, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24622,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32848","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u044d\u0442\u0443 \u0441\u0442\u0430\u0442\u044c\u044e \u043c\u0435\u043d\u044f \u0441\u043f\u043e\u0434\u0432\u0438\u0433\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u043e \u0441\u0442\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0430\u043d\u0430\u043b\u0438\u0437\u0435, \u0432\u0441\u0451 \u0447\u0430\u0449\u0435 \u043f\u043e\u043f\u0430\u0434\u0430\u044e\u0449\u0438\u0445\u0441\u044f \u043d\u0430 \u0433\u043b\u0430\u0437\u0430.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0412\u043d\u0435\u0434\u0440\u044f\u0439\u0442\u0435 \u0441\u0442\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0430\u043d\u0430\u043b\u0438\u0437 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441, \u0430 \u043d\u0435 \u0438\u0449\u0438\u0442\u0435 \u0441 \u0435\u0433\u043e \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0431\u0430\u0433\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u044d\u0442\u0443 \u0441\u0442\u0430\u0442\u044c\u044e \u043c\u0435\u043d\u044f \u0441\u043f\u043e\u0434\u0432\u0438\u0433\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u043e \u0441\u0442\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0430\u043d\u0430\u043b\u0438\u0437\u0435, \u0432\u0441\u0451 \u0447\u0430\u0449\u0435 \u043f\u043e\u043f\u0430\u0434\u0430\u044e\u0449\u0438\u0445\u0441\u044f \u043d\u0430 \u0433\u043b\u0430\u0437\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:49:16+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:49:16+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Rakendage statistilise anal\u00fc\u00fcsi protsessi, mitte \u00e4rge otsige selle abil vigu | ProHoster","description":"Seda artiklit kirjutama innustas mind suur hulk materjale, mis k\u00e4sitlevad statistilist anal\u00fc\u00fcsi ja mis j\u00e4rjest sagedamini silma ette satuvad.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u043d\u0435\u0434\u0440\u044f\u0439\u0442\u0435 \u0441\u0442\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0430\u043d\u0430\u043b\u0438\u0437 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441, \u0430 \u043d\u0435 \u0438\u0449\u0438\u0442\u0435 \u0441 \u0435\u0433\u043e \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0431\u0430\u0433\u0438 | ProHoster","og:description":"\u041d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u044d\u0442\u0443 \u0441\u0442\u0430\u0442\u044c\u044e \u043c\u0435\u043d\u044f \u0441\u043f\u043e\u0434\u0432\u0438\u0433\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u043e \u0441\u0442\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0430\u043d\u0430\u043b\u0438\u0437\u0435, \u0432\u0441\u0451 \u0447\u0430\u0449\u0435 \u043f\u043e\u043f\u0430\u0434\u0430\u044e\u0449\u0438\u0445\u0441\u044f \u043d\u0430 \u0433\u043b\u0430\u0437\u0430.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:49:16+00:00","article:modified_time":"2019-10-31T18:49:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32848","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 12:50:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:51:27","updated":"2026-01-21 12:50:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/32848","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=32848"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/32848\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/24622"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=32848"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=32848"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=32848"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}