Pagod na sa walang katapusang pagsusuri o pag-debug ng code, minsan iniisip mo kung paano pasimplehin ang iyong buhay. At pagkatapos maghanap ng kaunti, o sa pamamagitan ng hindi sinasadyang pagkatisod dito, makikita mo ang mahiwagang parirala: "Static analysis." Tingnan natin kung ano ito at kung paano ito maaaring makipag-ugnayan sa iyong proyekto.
Sa katunayan, kung sumulat ka sa anumang modernong wika, kung gayon, nang hindi mo namamalayan, pinatakbo mo ito sa pamamagitan ng isang static analyzer. Ang katotohanan ay ang anumang modernong compiler ay nagbibigay, kahit na isang maliit, hanay ng mga babala tungkol sa mga potensyal na problema sa code. Halimbawa, kapag kino-compile ang C++ code sa Visual Studio maaari mong makita ang sumusunod:
Sa output na ito makikita natin na ang variable ay ay hindi kailanman ginamit kahit saan sa function. Kaya sa katotohanan, halos palagi kang gumagamit ng isang simpleng static code analyzer. Gayunpaman, hindi tulad ng mga propesyonal na analyzer tulad ng Coverity, Klocwork o PVS-Studio, ang mga babala na ibinigay ng compiler ay maaari lamang magpahiwatig ng maliit na hanay ng mga problema.
Kung hindi mo alam kung ano ang static na pagsusuri at kung paano ito ipatupad, upang matuto nang higit pa tungkol sa pamamaraang ito.
Bakit kailangan mo ng static na pagsusuri?
Sa maikling salita: acceleration at simplification.
Nagbibigay-daan sa iyo ang static analysis na makahanap ng maraming iba't ibang problema sa code: mula sa maling paggamit ng mga construct ng wika hanggang sa mga typo. Halimbawa, sa halip na
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;Isinulat mo ang sumusunod na code:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Tulad ng nakikita mo, mayroong isang typo sa huling linya. Halimbawa, ang PVS-Studio ay naglalabas ng sumusunod na babala:
Pag-isipang suriin ang kawastuhan ng paggamit ng item na 'y'.
Kung gusto mong ipasok ang iyong mga kamay sa error na ito, subukan ang isang handa na halimbawa sa Compiler Explorer: **.
At tulad ng naiintindihan mo, hindi laging posible na bigyang-pansin kaagad ang mga naturang seksyon ng code, at dahil dito, maaari kang umupo sa pag-debug ng isang magandang oras, na nagtataka kung bakit kakaiba ang lahat.
Gayunpaman, ito ay malinaw na isang pagkakamali. Paano kung sumulat ang developer ng suboptimal na code dahil nakalimutan niya ang ilang subtlety ng wika? O kahit na pinapayagan ito sa code ? Sa kasamaang-palad, ang mga ganitong kaso ay ganap na karaniwan at ang malaking bahagi ng oras ay ginugugol sa pag-debug na partikular na gumagana ang code na naglalaman ng mga typo, karaniwang mga error o hindi natukoy na pag-uugali.
Ito ay para sa mga sitwasyong ito na lumitaw ang static na pagsusuri. Ito ay isang katulong para sa developer na ituturo ang iba't ibang mga problema sa code at ipaliwanag sa dokumentasyon kung bakit hindi kinakailangan na magsulat sa ganitong paraan, kung ano ang maaaring humantong sa at kung paano ayusin ito. Narito ang isang halimbawa ng maaaring hitsura nito: **.
Makakahanap ka ng mas kawili-wiling mga error na maaaring makita ng analyzer sa mga artikulo:
Ngayong nabasa mo na ang materyal na ito at kumbinsido ka sa mga benepisyo ng static na pagsusuri, maaaring gusto mo itong subukan. Ngunit saan magsisimula? Paano magsama ng bagong tool sa iyong kasalukuyang proyekto? At paano ipakilala ang koponan sa kanya? Makakakita ka ng mga sagot sa mga tanong na ito sa ibaba.
Tandaan. Hindi pinapalitan o kanselahin ng static na pagsusuri ang isang kapaki-pakinabang na bagay tulad ng mga pagsusuri sa code. Kinukumpleto nito ang prosesong ito, na tumutulong na mapansin at itama ang mga typo, kamalian, at mapanganib na disenyo nang maaga. Mas produktibo ang pagtuunan ng pansin ang mga pagsusuri ng code sa mga algorithm at kalinawan ng code, sa halip na maghanap ng maling lugar na panaklong o .
0. Pagkilala sa kasangkapan
Nagsisimula ang lahat sa isang trial na bersyon. Sa katunayan, mahirap magpasya na ipakilala ang isang bagay sa proseso ng pag-unlad kung hindi mo pa nakita ang tool nang live bago. Samakatuwid, ang unang bagay na dapat mong gawin ay i-download .
Ano ang matututuhan mo sa yugtong ito:
- Ano ang mga paraan upang makipag-ugnayan sa analyzer;
- Tugma ba ang analyzer sa iyong development environment?
- Anong mga problema ang kasalukuyang mayroon sa iyong mga proyekto?
Pagkatapos mong mai-install ang lahat ng kailangan mo, ang unang bagay na dapat mong gawin ay magpatakbo ng pagsusuri ng buong proyekto (, , ). Sa kaso ng PVS-Studio sa Visual Studio makakakita ka ng katulad na larawan (naki-click):
Ang katotohanan ay ang mga static na analyzer ay karaniwang naglalabas ng isang malaking bilang ng mga babala para sa mga proyekto na may malaking code base. Hindi na kailangang ayusin ang lahat, dahil gumagana na ang iyong proyekto, na nangangahulugan na ang mga problemang ito ay hindi kritikal. Gayunpaman, ikaw at itama ang mga ito kung kinakailangan. Upang gawin ito, kailangan mong i-filter ang output at iwanan lamang ang pinaka maaasahang mga mensahe. Sa plugin ng PVS-Studio para sa Visual Studio, ginagawa ito sa pamamagitan ng pag-filter ayon sa mga antas ng error at kategorya. Para sa pinakatumpak na output, umalis lamang Mataas ΠΈ Pangkalahatan (naki-click din):
Sa katunayan, ang 178 na babala ay mas madaling tingnan kaysa ilang libong...
Sa mga tab Medium ΠΈ Mababa Kadalasan mayroong magagandang babala, ngunit kasama sa mga kategoryang ito ang mga diagnostic na hindi gaanong katumpakan (pagkakatiwalaan). Higit pang impormasyon tungkol sa mga antas ng babala at mga opsyon para sa pagtatrabaho sa ilalim ng Windows ay matatagpuan dito: **.
Ang pagkakaroon ng matagumpay na pagsusuri sa mga pinaka-kagiliw-giliw na mga error (at matagumpay na naitama ang mga ito) ay nagkakahalaga . Ito ay kinakailangan upang ang mga bagong babala ay hindi mawala sa mga luma. Bilang karagdagan, ang isang static na analyzer ay isang katulong para sa programmer, at hindi isang listahan ng mga bug. π
1. Automation
Pagkatapos makilala, oras na para i-configure ang mga plugin at isama sa CI. Dapat itong gawin bago simulan ng mga programmer ang paggamit ng static analyzer. Ang katotohanan ay maaaring makalimutan ng programmer na paganahin ang pagsusuri o hindi nais na gawin ito sa lahat. Upang gawin ito, kailangan mong gawin ang ilang panghuling pagsusuri sa lahat upang ang hindi pa nasubok na code ay hindi makapasok sa pangkalahatang sangay ng pag-unlad.
Ano ang matututuhan mo sa yugtong ito:
- Anong mga opsyon sa automation ang ibinibigay ng tool;
- Compatible ba ang analyzer sa iyong assembly system?
Dahil walang perpektong dokumentasyon, minsan kailangan mong sumulat . Ito ay normal at ikalulugod naming tulungan ka. π
Ngayon ay lumipat tayo sa patuloy na pagsasama-sama (CI) na mga serbisyo. Anumang analyzer ay maaaring ipatupad sa kanila nang walang anumang malubhang problema. Upang gawin ito, kailangan mong lumikha ng isang hiwalay na yugto sa pipeline, na kadalasang matatagpuan pagkatapos ng build at unit test. Ginagawa ito gamit ang iba't ibang mga utility ng console. Halimbawa, ang PVS-Studio ay nagbibigay ng mga sumusunod na kagamitan:
- (pagsusuri ng mga solusyon, C#, C++ na proyekto sa Windows)
- (pagsubaybay sa compilation)
- (pagsusuri ng mga proyekto ng C++ sa Linux / macOS)
- (pagsusuri ng solusyon, mga proyekto ng C# sa Linux / macOS)
- (pagsusuri ng mga proyekto ng Java)
- (report file converter)
Upang maisama ang pagsusuri sa CI, kailangan mong gawin ang tatlong bagay:
- I-install ang analyzer;
- Patakbuhin ang pagsusuri;
- Maghatid ng mga resulta.
Halimbawa, upang mai-install ang PVS-Studio sa Linux (Debian-base), kailangan mong patakbuhin ang mga sumusunod na command:
wget -q -O - https://files.viva64.com/etc/pubkey.txt
| sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
sudo apt-get update -qq
sudo apt-get install -qq pvs-studioSa mga system na nagpapatakbo ng Windows, walang paraan upang mai-install ang analyzer mula sa package manager, ngunit posibleng i-deploy ang analyzer mula sa command line:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsMaaari kang magbasa nang higit pa tungkol sa pag-deploy ng PVS-Studio sa mga system na nagpapatakbo ng Windows **.
Pagkatapos ng pag-install, kailangan mong direktang patakbuhin ang pagsusuri. Gayunpaman, inirerekumenda na gawin lamang ito pagkatapos ng compilation at mga pagsubok na lumipas. Ito ay dahil ang static na pagsusuri ay karaniwang tumatagal ng dalawang beses kaysa sa compilation.
Dahil ang paraan ng paglulunsad ay nakasalalay sa platform at mga tampok ng proyekto, ipapakita ko ang opsyon para sa C++ (Linux) bilang isang halimbawa:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wAng unang utos ay magsasagawa ng pagsusuri, at ang pangalawa kino-convert ang ulat sa format ng teksto, ipinapakita ito sa screen at nagbabalik ng return code maliban sa 0 kung may mga babala. Ang mekanismong tulad nito ay madaling magamit upang harangan ang isang build kapag may mga mensahe ng error. Gayunpaman, maaari mong palaging alisin ang bandila -w at huwag harangan ang isang pagpupulong na naglalaman ng mga babala.
Tandaan. Ang format ng teksto ay hindi maginhawa. Ito ay ibinigay lamang bilang isang halimbawa. Bigyang-pansin ang isang mas kawili-wiling format ng ulat - FullHtml. Pinapayagan ka nitong mag-navigate sa code.
Maaari kang magbasa nang higit pa tungkol sa pag-set up ng pagsusuri sa CI sa artikulong "" (Windows) o ""(Linux).
Okay, na-configure mo ang analyzer sa build server. Ngayon, kung may nag-upload ng hindi pa nasubok na code, mabibigo ang yugto ng pag-verify, at matutukoy mo ang problema, gayunpaman, hindi ito lubos na maginhawa, dahil mas mahusay na suriin ang proyekto hindi pagkatapos na pagsamahin ang mga sangay, ngunit bago nito, sa yugto ng paghiling ng paghila. A.
Sa pangkalahatan, ang pagse-set up ng pagsusuri sa paghiling ng pull ay hindi gaanong naiiba sa karaniwang paglulunsad ng pagsusuri sa CI. Maliban sa pangangailangang makakuha ng listahan ng mga binagong file. Karaniwang makukuha ang mga ito sa pamamagitan ng pagtatanong sa mga pagkakaiba sa pagitan ng mga sangay gamit ang git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listNgayon ay kailangan mong ipasa ang listahang ito ng mga file sa analyzer bilang input. Halimbawa, sa PVS-Studio ito ay ipinatupad gamit ang bandila -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listMaaari mong malaman ang higit pa tungkol sa pagsusuri ng mga pull request **. Kahit na ang iyong CI ay wala sa listahan ng mga serbisyong binanggit sa artikulo, makikita mong kapaki-pakinabang ang pangkalahatang seksyon na nakatuon sa teorya ng ganitong uri ng pagsusuri.
Sa pamamagitan ng pagse-set up ng pagsusuri ng mga pull request, maaari mong i-block ang mga commit na naglalaman ng mga babala, at sa gayon ay lumikha ng hangganan na hindi maaring lampasan ng hindi pa nasusubukang code.
Ang lahat ng ito ay tiyak na mabuti, ngunit nais kong makita ang lahat ng mga babala sa isang lugar. Hindi lamang mula sa static analyzer, kundi pati na rin mula sa mga unit test o mula sa dynamic analyzer. Mayroong iba't ibang mga serbisyo at plugin para dito. Ang PVS-Studio, halimbawa, ay may .
2. Pagsasama sa mga makina ng developer
Ngayon ay oras na para i-install at i-configure ang analyzer para sa pang-araw-araw na paggamit ng development. Sa puntong ito, naging pamilyar ka na sa karamihan ng mga paraan ng pagtatrabaho, kaya matatawag itong pinakamadaling bahagi.
Bilang pinakasimpleng opsyon, maaaring i-install mismo ng mga developer ang kinakailangang analyzer. Gayunpaman, ito ay aabutin ng maraming oras at makaabala sa kanila mula sa pag-unlad, upang maaari mong i-automate ang prosesong ito gamit ang isang installer at ang mga kinakailangang flag. Para sa PVS-Studio mayroong iba't ibang . Gayunpaman, palaging may mga manager ng package, halimbawa, Chocolatey (Windows), Homebrew (macOS) o dose-dosenang mga opsyon para sa Linux.
Pagkatapos ay kakailanganin mong i-install ang mga kinakailangang plugin, halimbawa para sa , , at iba pa
3. Araw-araw na paggamit
Sa yugtong ito, oras na para magsabi ng ilang salita tungkol sa mga paraan para mapabilis ang analyzer sa araw-araw na paggamit. Ang kumpletong pagsusuri ng buong proyekto ay tumatagal ng maraming oras, ngunit gaano kadalas namin binabago ang code sa buong proyekto nang sabay-sabay? Malamang na hindi magkakaroon ng refactoring na napakalaki na agad itong makakaapekto sa buong code base. Ang bilang ng mga file na binago sa isang pagkakataon ay bihirang lumampas sa isang dosena, kaya makatuwirang pag-aralan ang mga ito. Para sa ganoong sitwasyon mayroon . Huwag lamang maalarma, hindi ito isa pang tool. Ito ay isang espesyal na mode na nagbibigay-daan sa iyong pag-aralan lamang ang mga nabagong file at ang kanilang mga dependency, at ito ay awtomatikong nangyayari pagkatapos ng pagbuo kung ikaw ay nagtatrabaho sa isang IDE na may naka-install na plugin.
Kung may nakitang problema ang analyzer sa kamakailang binagong code, ire-report ito nang nakapag-iisa. Halimbawa, sasabihin sa iyo ng PVS-Studio ang tungkol dito gamit ang isang alerto:
Siyempre, hindi sapat ang pagsasabi sa mga developer na gamitin ang tool. Kailangan nating sabihin sa kanila kung ano ito at kung paano ito. Narito, halimbawa, ang mga artikulo tungkol sa mabilis na pagsisimula para sa PVS-Studio, ngunit makakahanap ka ng mga katulad na tutorial para sa anumang tool na gusto mo:
Ang ganitong mga artikulo ay nagbibigay ng lahat ng impormasyong kinakailangan para sa pang-araw-araw na paggamit at hindi tumatagal ng maraming oras. π
Kahit na sa yugto ng pagkilala sa tool, pinigilan namin ang maraming babala sa isa sa mga unang paglulunsad. Sa kasamaang palad, ang mga static na analyzer ay hindi perpekto, kaya paminsan-minsan ay nagbibigay sila ng mga maling positibo. Karaniwang madaling sugpuin ang mga ito; halimbawa, sa PVS-Studio plugin para sa Visual Studio kailangan mo lang mag-click ng isang button:
Gayunpaman, maaari kang gumawa ng higit pa sa pagsugpo sa kanila. Halimbawa, maaari kang mag-ulat ng problema sa suporta. Kung ang maling positibo ay maaaring itama, pagkatapos ay sa hinaharap na mga pag-update ay mapapansin mo na sa bawat oras na may mas kaunti at mas kaunting mga maling positibo na partikular sa iyong codebase.
Pagkatapos ng integration
Kaya't napagdaanan namin ang lahat ng mga yugto ng pagsasama ng static na pagsusuri sa proseso ng pag-unlad. Sa kabila ng kahalagahan ng pag-set up ng mga naturang tool sa CI, ang pinakamahalagang lugar para patakbuhin ang mga ito ay ang computer ng developer. Pagkatapos ng lahat, ang isang static analyzer ay hindi isang hukom na nagsasabi sa isang lugar na malayo sa iyo na ang code ay hindi mabuti. Sa kabaligtaran, ito ay isang katulong na nagsasabi sa iyo kung ikaw ay pagod at nagpapaalala sa iyo kung mayroon kang nakalimutan.
Totoo, nang walang regular na paggamit, ang static na pagsusuri ay malamang na hindi makabuluhang gawing simple ang pag-unlad. Pagkatapos ng lahat, ang pangunahing pakinabang nito para sa isang developer ay hindi nakasalalay sa paghahanap ng kumplikado at kontrobersyal na mga seksyon ng code, ngunit sa kanilang maagang pagtuklas. Sumang-ayon na ang pagtuklas ng problema pagkatapos maipadala ang mga pag-edit para sa pagsubok ay hindi lamang hindi kasiya-siya, ngunit napakatagal din. Ang static na pagsusuri, kapag regular na ginagamit, ay direktang tumitingin sa bawat pagbabago sa iyong computer at nag-uulat ng mga kahina-hinalang lugar habang ginagawa ang code.
At kung ikaw o ang iyong mga kasamahan ay hindi pa rin sigurado kung ito ay nagkakahalaga ng pagpapatupad ng analyzer, pagkatapos ay iminumungkahi ko na simulan mo na ngayong basahin ang artikulo "". Tinutugunan nito ang mga karaniwang alalahanin ng mga developer na aabutin ng static na pagsusuri ang kanilang oras at iba pa.
Kung nais mong ibahagi ang artikulong ito sa isang madla na nagsasalita ng Ingles, mangyaring gamitin ang link ng pagsasalin: Maxim Zvyagintsev. .
Pinagmulan: www.habr.com