Estas facile provi statikan kodan analizilon. Sed por efektivigi ĝin, precipe en la disvolviĝo de granda malnova projekto, postulas lertecon. Se farite malĝuste, la analizilo povas aldoni laboron, bremsi evoluon kaj malmotivigi la teamon. Ni mallonge parolu pri kiel ĝuste aliri la integriĝon de senmova analizo en la evoluprocezon kaj ekuzi ĝin kiel parton de CI/CD.
Enkonduko
Lastatempe mia atento estis altigita al la publikigo "". Unuflanke, ĉi tio estas bona artikolo, kun kiu indas konatiĝi. Aliflanke, ŝajnas al mi, ke ĝi ankoraŭ ne donas kompletan respondon pri kiel senpere efektivigi statikan analizon en projekto kun multe de hereda kodo.La artikolo diras, ke Vi povas akcepti teknikan ŝuldon kaj labori nur pri nova kodo, sed ne ekzistas respondo pri tio, kion fari kun ĉi tiu teknika ŝuldo poste.
Nia teamo de PVS-Studio proponas sian vidon pri ĉi tiu temo. Ni rigardu kiel la problemo de efektivigo de senmova koda analizilo ekestas unue, kiel venki ĉi tiun problemon, kaj kiel sendolore iom post iom forigi teknikan ŝuldon.
Temoj
Kutime ne estas malfacile lanĉi kaj vidi kiel funkcias senmova analizilo []. Vi eble vidos interesajn erarojn aŭ eĉ timigajn eblajn vundeblecojn en la kodo. Vi eĉ povas ion ripari, sed tiam multaj programistoj rezignas.
Ĉiuj senmovaj analiziloj produktas falsajn pozitivojn. Ĉi tio estas trajto de la statika koda analiza metodaro, kaj nenio povas esti farita pri ĝi. En la ĝenerala kazo, ĉi tio estas nesolvebla problemo, kiel konfirmite per la teoremo de Rice []. Maŝinlernadaj algoritmoj ankaŭ ne helpos []. Eĉ se homo ne ĉiam povas diri ĉu tiu aŭ alia kodo estas malĝusta, tiam vi ne atendu tion de la programo :).
Falsaj pozitivoj ne estas problemo se la senmova analizilo jam estas agordita:
- Malebligitaj senrilataj reguloj;
- Kelkaj sensignivaj diagnozoj estis malfunkciigitaj;
- Se ni parolas pri C aŭ C++, tiam makrooj estas markitaj, kiuj enhavas specifajn konstrukciojn, kiuj kaŭzas senutilajn avertojn aperi en ĉiu loko kie tiaj makrooj estas uzataj;
- Propraj funkcioj estas markitaj, kiuj plenumas agojn similajn al sistemaj funkcioj (sia propra analogo memcpy aŭ printf) [];
- Falsaj pozitivoj estas specife malŝaltitaj uzante komentojn;
- Kaj tiel plu.
En ĉi tiu kazo, ni povas atendi malaltan malveran pozitivan indicon de ĉirkaŭ 10-15% []. Alivorte, 9 el 10 analiziloj indikos realan problemon en la kodo, aŭ almenaŭ "fortodora kodo". Konsentu, ĉi tiu scenaro estas ege agrabla, kaj la analizilo estas vera amiko de la programisto.
En realeco, en granda projekto, la komenca bildo estos tute malsama. La analizilo eligas centojn aŭ milojn da avertoj por hereda kodo. Estas neeble rapide kompreni, kiuj el ĉi tiuj avertoj estas gravaj kaj kiuj ne. Estas neracie sidiĝi kaj komenci trakti ĉiujn ĉi tiujn avertojn, ĉar la ĉefa laboro en ĉi tiu kazo ĉesos dum tagoj aŭ semajnoj. Tipe, teamo ne povas pagi tian scenaron. Ankaŭ estos grandega nombro da diferencoj, kiuj difektas la ŝanĝhistorion. Kaj rapida amasa redaktado de tiom da fragmentoj en la kodo neeviteble rezultigos novajn tajperarojn kaj erarojn.
Kaj plej grave, tia heroaĵo en la batalo kontraŭ avertoj havas malmulte da senco. Konsentu, ke ĉar la projekto funkcias sukcese dum multaj jaroj, la plej multaj el la kritikaj eraroj en ĝi jam estis korektitaj. Jes, ĉi tiuj korektoj estis tre multekostaj, devis esti sencimigitaj, ricevis negativajn uzantajn rimarkojn pri cimoj, ktp. Senmova analizilo helpus ripari multajn el ĉi tiuj eraroj ĉe la kodiga stadio, rapide kaj malmultekoste. Sed nuntempe, iel aŭ alie, ĉi tiuj eraroj estis riparitaj, kaj la analizilo ĉefe detektas nekritikajn erarojn en la malnova kodo. Ĉi tiu kodo eble ne estas uzata, ĝi povas esti uzata tre malofte, kaj eraro en ĝi eble ne kondukas al rimarkindaj sekvoj. Eble ie la ombro de la butono estas malĝusta koloro, sed ĉi tio ne malhelpas ies uzadon de la produkto.
Kompreneble, eĉ etaj eraroj ankoraŭ estas eraroj. Kaj foje eraro povas kaŝi veran vundeblecon. Tamen, rezigni ĉion kaj pasigi tagojn/semajnojn traktante difektojn kiuj apenaŭ manifestas sin aspektas kiel dubinda ideo.
Programistoj rigardas, rigardu, rigardu ĉiujn ĉi tiujn avertojn pri la malnova laborkodo... Kaj ili pensas: ni povas fari sen statika analizo. Ni iru skribi kelkajn novajn utilajn funkciojn.
Siamaniere ili pravas. Ili supozas, ke unue ili devas iel forigi ĉiujn ĉi tiujn avertojn. Nur tiam ili povos profiti de regula uzo de la kodanalizilo. Alie, novaj avertoj simple dronos en malnovaj, kaj neniu atentos ilin.
Ĉi tio estas la sama analogio kiel kun kompililo avertoj. Ne senkaŭze ili rekomendas konservi la nombron da kompiligaj avertoj ĉe 0. Se estas 1000 avertoj, tiam kiam estas 1001, neniu atentos ĝin, kaj ne estas klare kie serĉi ĉi tiun plej novan averton.
La plej malbona afero en ĉi tiu rakonto estas se iu de supre en ĉi tiu momento devigas vin uzi statikan kodan analizon. Ĉi tio nur malmotivigos la teamon, ĉar el ilia vidpunkto estos plia burokratia komplekseco, kiu nur malhelpas. Neniu rigardos la raportojn de la analizilo, kaj ĉiu uzo estos nur "surpapere". Tiuj. Formale, analizo estas konstruita en la procezon DevOps, sed praktike ĉi tio ne profitas al iu ajn. Ni aŭdis detalajn rakontojn ĉe budoj de kongresanoj. Tia sperto povas malinstigi programistojn uzi statikajn analizilojn dum longa tempo, se ne por ĉiam.
Efektivigo kaj forigo de teknika ŝuldo
Fakte, estas nenio malfacila aŭ timiga pri enkonduko de statika analizo eĉ en granda malnova projekto.
CI / KD
Krome, la analizilo povas tuj fariĝi parto de la kontinua evoluprocezo. Ekzemple, la distribuo PVS-Studio enhavas utilecojn por oportune vidi la raporton en la formato, kiun vi bezonas, kaj sciigojn al programistoj, kiuj skribis problemajn sekciojn de la kodo. Por tiuj, kiuj pli interesiĝas pri lanĉo de PVS-Studio el CI/CD-sistemoj, mi rekomendas, ke vi konatiĝu kun la respondaj dokumentaro kaj serio de artikoloj:
Sed ni revenu al la afero de granda nombro da falsaj pozitivoj ĉe la unuaj etapoj de efektivigado de kodaj analiziloj.
Ripari ekzistantan teknikan ŝuldon kaj trakti novajn avertojn
Modernaj komercaj senmovaj analiziloj permesas vin studi nur novajn avertojn, kiuj aperas en nova aŭ ŝanĝita kodo. La efektivigo de ĉi tiu mekanismo varias, sed la esenco estas la sama. En la senmova analizilo PVS-Studio, ĉi tiu funkcio estas efektivigita jene.
Por rapide komenci uzi statikan analizon, ni sugestas ke uzantoj de PVS-Studio uzu la mekanismon por amasa subpremado de avertoj []. La ĝenerala ideo estas la sekva. La uzanto lanĉis la analizilon kaj ricevis multajn avertojn. Ĉar projekto, kiu disvolviĝis dum multaj jaroj, vivas, disvolviĝas kaj enspezas monon, tiam plej verŝajne ne estos multaj avertoj en la raporto indikante kritikajn difektojn. Alivorte, kritikaj eraroj jam estis riparitaj unumaniere aŭ alie per pli multekostaj metodoj aŭ danke al sugestoj de klientoj. Sekve, ĉio, kion la analizisto nuntempe trovas, povas esti konsiderata teknika ŝuldo, kio estas nepraktika provi tuj forigi.
Vi povas diri al PVS-Studio konsideri ĉi tiujn avertojn senrilataj nuntempe (konservu teknikan ŝuldon por poste), kaj ĝi ne plu montros ilin. La analizilo kreas specialan dosieron, kie ĝi konservas informojn pri eraroj, kiuj ankoraŭ ne estas interesaj. Kaj nun PVS-Studio eligos avertojn nur pri nova aŭ ŝanĝita kodo. Krome, ĉio ĉi estas lerte efektivigita. Se ekzemple malplena linio estas aldonita al la komenco de la fontkoda dosiero, tiam la analizilo komprenas, ke fakte nenio ŝanĝiĝis, kaj daŭre silentos. Ĉi tiu markadosiero povas esti metita en version-kontrolsistemon. La dosiero estas granda, sed ĉi tio ne estas problemo, ĉar ne utilas konservi ĝin ofte.
Nun ĉiuj programistoj vidos avertojn rilatajn nur al nova aŭ ŝanĝita kodo. Tiel, vi povas komenci uzi la analizilon, kiel oni diras, de la sekva tago. Kaj vi povas reveni al teknika ŝuldo poste, kaj iom post iom korekti erarojn kaj agordi la analizilon.
Do, la unua problemo pri la efektivigo de la analizilo en granda malnova projekto estis solvita. Nun ni eltrovu, kion fari kun teknika ŝuldo.
Cimoj korektoj kaj refactorings
La plej simpla kaj plej natura afero estas rezervi iom da tempo por analizi amase subpremitajn analizajn avertojn kaj iom post iom trakti ilin. Ie vi devus ripari erarojn en la kodo, ie vi devus refaktori por diri al la analizilo ke la kodo ne estas problema. Simpla ekzemplo:
if (a = b)Plej multaj C++-kompililoj kaj analiziloj plendas pri tia kodo, ĉar estas alta probableco ke ili fakte volis skribi (a == b). Sed estas nedirita interkonsento, kaj ĉi tio estas kutime notita en la dokumentado, ke se estas pliaj krampoj, tiam oni konsideras, ke la programisto intence skribis tian kodon, kaj ne necesas ĵuri. Ekzemple, en la PVS-Studio dokumentado por diagnozo estas klare skribite, ke la sekva linio estos konsiderata ĝusta kaj sekura:
if ((a = b))Alia ekzemplo. Ĉu ĝi estas forgesita en ĉi tiu C++-kodo? paŭzo aŭ ne?
case A:
foo();
case B:
bar();
break;La analizilo de PVS-Studio eligos averton ĉi tie . Ĉi tio eble ne estas eraro, en kiu kazo vi devus doni al la analizilo sugeston aldonante la atributon aŭ ekzemple __atributo__((fala)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Oni povas diri, ke tiaj kodaj ŝanĝoj ne riparas la cimon. Jes, ĉi tio estas vera, sed ĝi faras du utilajn aferojn. Unue, la analizilo-raporto forigas falsajn pozitivojn. Due, la kodo fariĝas pli komprenebla por la homoj implikitaj en ĝia prizorgado. Kaj ĉi tio estas tre grava! Nur por tio, indas fari negravajn refaktorojn por fari la kodon pli klara kaj pli facile konservebla. Ĉar la analizilo ne komprenas ĉu "rompo" estas bezonata aŭ ne, ĝi ankaŭ estos neklara al kolegaj programistoj.
Krom korektoj kaj refactorings, vi povas specife subpremi evidente malverajn avertojn pri analizilo. Iuj sensignivaj diagnozoj povas esti malŝaltitaj. Ekzemple, iu opinias, ke avertoj estas sencelaj pri komparo de flosaj/duoblaj valoroj. Kaj iuj klasifikas ilin kiel gravajn kaj studindajn []. Kiuj avertoj estas konsiderataj trafaj kaj kiuj ne, decidas la disvolva teamo.
Estas aliaj manieroj subpremi falsajn atentigojn. Ekzemple, makromarkado estis menciita pli frue. Ĉio ĉi estas priskribita pli detale en la dokumentado. La plej grava afero estas kompreni, ke se vi iom post iom kaj sisteme alproksimiĝas al laboro kun falsaj pozitivoj, estas nenio malbona kun ili. La granda plimulto de neinteresaj avertoj malaperas post agordo, kaj restas nur lokoj, kiuj vere postulas zorgan studon kaj iujn ŝanĝojn en la kodo.
Ankaŭ, ni ĉiam helpas niajn klientojn starigi PVS-Studion se aperas iuj malfacilaĵoj. Krome, estis kazoj kiam ni mem forigis falsajn avertojn kaj korektis erarojn []. Por la okazo, mi decidis mencii, ke ankaŭ ĉi tiu opcio por etendita kunlaboro eblas :).
Kliko-metodo
Estas alia interesa aliro por iom post iom plibonigi kodkvaliton per forigo de la senmova analizilo-averto. La fundo estas, ke la nombro da avertoj povas nur malpliiĝi.
La nombro da avertoj eligitaj de la senmova analizilo estas registrita. Kvalita pordego estas agordita tiel, ke nun vi nur povas enigi kodon, kiu ne pliigas la nombron da operacioj. Kiel rezulto, la procezo de iom post iom redukti la nombron da alarmoj komenciĝas ĝustigante la analizilon kaj korektante erarojn.
Eĉ se homo volas iomete trompi kaj decidas preterpasi la kvalitan pordegon ne forigante avertojn en sia nova kodo, sed plibonigante la malnovan trian kodon, ĉi tio ne estas timiga. Tamen, la klako turniĝas en unu direkto, kaj iom post iom la nombro da difektoj malpliiĝos. Eĉ se homo ne volas ripari siajn proprajn novajn difektojn, li ankoraŭ devos plibonigi ion en la najbara kodo. Iam, la facilaj manieroj redukti la nombron da avertoj finiĝas, kaj venas punkto, kiam veraj eraroj estos korektitaj.
Ĉi tiu metodaro estas priskribita pli detale en tre interesa artikolo de Ivan Ponomarev "", kiun mi rekomendas legi al iu ajn interesita pri plibonigi kodkvaliton.
La verkinto de la artikolo ankaŭ havas raporton pri ĉi tiu temo: "".
konkludo
Mi esperas, ke post ĉi tiu artikolo, legantoj pli akceptos statikajn analizajn ilojn kaj volos efektivigi ilin en la disvolvan procezon. Se vi havas demandojn, ni ĉiam pretas uzantoj de nia senmova analizilo PVS-Studio kaj helpu pri ĝia efektivigo.
Estas aliaj tipaj duboj pri ĉu statika analizo vere povas esti oportuna kaj utila. Mi provis forigi la plej multajn el ĉi tiuj duboj en la eldonaĵo "Kialoj por enkonduki la statikan kodan analizilon PVS-Studio en la evoluprocezon" [].
Dankon pro via atento kaj venu kaj provu la analizilon PVS-Studio.
Pliaj ligiloj
- Andrej Karpov.
- Vikipedio. .
- Andrej Karpov, Viktorio Ĥanieva. .
- PVS-Studio. Dokumentado. .
- Andrej Karpov. .
- PVS-Studio. Dokumentado. .
- Ivan Andrjaŝin. .
- Pavel Eremeev, Svjatoslav Razmyslov. .
- Andrej Karpov. .
Se vi volas dividi ĉi tiun artikolon kun anglalingva publiko, bonvolu uzi la tradukan ligilon: Andrey Karpov. .
fonto: www.habr.com