Стаміўшыся ад бясконцага code review ці адладкі, часам задумваешся, як бы спрасціць сабе жыццё. І крыху пашукаўшы, ну ці выпадкова натыкнуўшыся, можна ўбачыць чароўнае словазлучэнне: "Статычны аналіз". Давайце паглядзім, што гэта такое і як ён можа ўзаемадзейнічаць з вашым праектам.
Уласна кажучы, калі вы пішаце на які-небудзь сучаснай мове, тады, нават не здагадваючыся аб гэтым, вы прапускалі яго праз статычны аналізатар. Справа ў тым, што любы сучасны кампілятар падае хай і маленечкі, але набор папярэджанняў аб патэнцыйных праблемах у кодзе. Напрыклад, кампілюючы C++ код у Visual Studio вы можаце ўбачыць наступнае:
У гэтай выснове мы бачым, што зменная было так і не была выкарыстана нідзе ў функцыі. Так што насамрэч вы амаль заўсёды карысталіся просценькім статычным аналізатарам кода. Аднак, у адрозненне ад прафесійных аналізатараў, такіх як Coverity, Klocwork ці PVS-Studio, якія прадстаўляюцца кампілятарам папярэджання могуць паказваць толькі на невялікі спектр праблем.
Калі вы не ведаеце, напэўна, што такое статычны аналіз і як яго ўкараняць, , каб больш падрабязна азнаёміцца з гэтай метадалогіяй.
Навошта патрэбен статычны аналіз?
У двух словах: паскарэнне і спрашчэнне.
Статычны аналіз дазваляе знайсці плойму розных праблем у кодзе: пачынальна ад няправільнага выкарыстання канструкцый мовы, сканчаючы памылкамі друку. Напрыклад, замест
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;Вы напісалі наступны код:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Як бачыце, у апошнім радку з'явілася памылка друку. Напрыклад, PVS-Studio выдае наступнае папярэджанне:
Consider reviewing correctness of 'y' item's usage.
Калі жадаеце патыкаць у гэтую памылку рукамі, то паспрабуйце гатовы прыклад на Compiler Explorer: **.
І як вы разумееце, не заўсёды можна звярнуць увагі на падобныя ўчасткі кода адразу і з-за гэтага можна засесці за адладку на добрую гадзіну, здзіўляючыся, чаму ўсё працуе так дзіўна.
Аднак гэта відавочная памылка. А калі распрацоўшчык напісаў неаптымальны код з-за таго, што забыўся якую-небудзь тонкасць мовы? Або ж зусім дапусціў у кодзе ? Нажаль, падобныя выпадкі зусім штодзённыя і ільвіная частка часу марнуецца на тое, каб адладзіць спецыфічна які працуе код, які ўтрымоўвае памылкі друку, тыповыя памылкі ці undefined behavior.
Менавіта для гэтых сітуацый і з'явіўся статычны аналiз. Гэта памагаты для распрацоўніка, які пакажа яму на розныя праблемы ў кодзе і растлумачыць у дакументацыі чаму так пісаць не трэба, да чаго гэта можа прывесці і як гэта выправіць. Вось прыклад як гэта можа выглядаць: **.
Больш цікавых памылак, якія можа выявіць аналізатар, вы можаце знайсці ў артыкулах:
Цяпер, прачытаўшы гэты матэрыял і пераканаўшыся ў карысці статычнага аналізу, вы маглі захацець выпрабаваць яго ў справе. Але з чаго пачаць? Як інтэграваць новы інструмент у бягучы праект? І як пазнаёміць каманду з ім? На гэтыя пытанні вы знойдзеце адказы ніжэй.
Заўвага. Статычны аналіз не замяняе і не адмяняе такую карысную рэч, як агляды кода. Ён дапаўняе гэты працэс, дапамагаючы загадзя заўважыць і выправіць памылкі друку, недакладнасці, небяспечныя канструкцыі. Нашмат прадуктыўней засяродзіцца пры аглядах кода на алгарытмах і зразумеласці кода, а не над выглядваннем не тамака пастаўленай дужкі або .
0. Знаёмства з інструментам
Усё пачынаецца з выпрабавальнай версіі. Сапраўды, складана вырашыцца ўкараняць штосьці ў працэс распрацоўкі, калі ніколі да гэтага не бачыў прылады ўжывую. Таму перш за ўсё варта спампаваць .
Што вы даведаецеся на гэтым этапе:
- Якія ёсць спосабы ўзаемадзеяння з аналізатарам;
- Ці сумяшчальны аналізатар з вашым асяроддзем распрацоўкі;
- Якія праблемы ёсць зараз у вашых праектах.
Пасля таго, як вы ўсталявалі сабе ўсё неабходнае, то перш за ўсё варта запусціць аналіз усяго праекта (, , ). У выпадку з PVS-Studio у Visual Studio вы ўбачыце падобную карціну (клікабельна):
Справа ў тым, што звычайна на праекты з вялікай кодавай базай статычныя аналізатары выдаюць велізарную колькасць папярэджанняў. Няма неабходнасці выпраўляць іх усё, бо ваш праект ужо працуе, а значыць гэтыя праблемы не з'яўляюцца крытычнымі. Аднак вы і выправіць іх пры неабходнасці. Для гэтага трэба адфільтраваць выснову і пакінуць толькі найболей пэўныя паведамленні. У плагіне PVS-Studio для Visual Studio гэта робіцца фільтраваннем па ўзроўнях і катэгорыям памылак. Для найболей дакладнай высновы пакіньце ўключанымі толькі высокая и агульны (таксама клікабельна):
Сапраўды, 178 папярэджанняў прагледзець значна прасцей, чым некалькі тысяч…
Ва ўкладках серада и Нізкі часта трапляюцца добрыя папярэджанні, аднак у гэтыя катэгорыі занесены тыя дыягностыкі, якія маюць меншую дакладнасць (дакладнасць). Падрабязней пра ўзроўні папярэджанняў і варыянты працы пад Windows можна паглядзець тут: **.
Паспяхова прагледзеўшы самыя цікавыя памылкі (і паспяхова выправіўшы іх) варта . Гэта трэба для таго, каб новыя папярэджанні не губляліся сярод старых. Да таго ж статычны аналізатар - гэта памочнік для праграміста, а не спіс для багаў. 🙂
1. Аўтаматызацыя
Пасля знаёмства надыходзіць час налады плагінаў і інтэграцыі ў CI. Гэта неабходна зрабіць да таго, як праграмісты пачнуць выкарыстоўваць статычны аналізатар. Справа ў тым, што праграміст можа забыцца ўключыць аналіз ці зусім не захацець. Для гэтага трэба зрабіць некаторую фінальную праверку за ўсё, каб неправераны код не мог патрапіць у агульную галінку распрацоўкі.
Што вы даведаецеся на дадзеным этапе:
- Якія варыянты аўтаматызацыі дае інструмент;
- Ці сумяшчальны аналізатар з вашай зборачнай сістэмай.
Так як ідэальнай дакументацыі не існуе, часам даводзіцца пісаць у . Гэта нармальна, і мы рады вам дапамагчы. 🙂
А зараз прыступім да сэрвісаў бесперапыннай інтэграцыі (CI). Любы аналізатар можна ўкараніць у іх без якіх-небудзь сур'ёзных праблем. Для гэтага трэба стварыць асобны этап у pipeline, які звычайна знаходзіцца пасля зборкі і юніт-тэстаў. Робіцца гэта пры дапамозе розных кансольных утыліт. Напрыклад, PVS-Studio падае наступныя ўтыліты:
- (аналіз рашэнняў, C#, C++ праектаў на Windows)
- (маніторынг кампіляцыі)
- (аналіз C++ праектаў на Linux / macOS)
- (аналіз рашэнняў, C# праектаў на Linux / macOS)
- (аналіз Java праектаў)
- (канвэртар файлаў справаздачы)
Для інтэграцыі аналізу ў CI трэба зрабіць тры рэчы:
- Устанавіць аналізатар;
- Запусціць аналіз;
- Даставіць вынікі.
Напрыклад, для ўсталёўкі PVS-Studio на Linux (Debian-base) трэба выканаць наступныя каманды:
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-studioУ сістэмах пад кіраваннем Windows адсутнічае магчымасць усталяваць аналізатар з пакетнага мэнэджара, аднак ёсць магчымасць разгарнуць аналізатар з каманднага радка:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsПадрабязней аб разгортванні PVS-Studio у сістэмах пад кіраваннем Windows можна пачытаць **.
Пасля ўстаноўкі трэба запусціць непасрэдна аналіз. Аднак рабіць гэта рэкамендуецца толькі пасля таго, як прайшла кампіляцыя і выпрабаванні. Гэта злучана з тым, што для статычнага аналізу звычайна патрабуецца ў два разу больш часу, чым для кампіляцыі.
Бо спосаб запуску залежыць ад платформы і асаблівасцяў праекту, я пакажу варыянт для C++ (Linux) у якасці прыкладу:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wПершая каманда выканае аналіз, а другая е справаздачу ў тэкставы фармат, выведзе яго на экран і верне выдатны ад 0 код вяртання ў выпадку наяўнасці папярэджанняў. Падобны механізм зручна выкарыстоўваць для блакавання зборкі пры наяўнасці паведамленняў аб памылках. Аднак, вы заўсёды можаце прыбраць сцяг -w і не блакаваць зборку, якая змяшчае папярэджанні.
Заўвага. Тэкставы фармат - гэта няёмка. Ён прыводзіцца проста для прыкладу. Звярніце ўвагу на цікавейшы фармат справаздачы — FullHtml. Ён дазваляе ажыццяўляць навігацыю па кодзе.
Падрабязней пра настройку аналізу на CI можна прачытаць у артыкуле "" (Windows) або "" (Linux).
Добра, вы наладзілі працу аналізатара на зборачным сэрвэры. Цяпер, калі нехта заліў неправераны код, будзе падаць этап праверкі, і вы зможаце выявіць праблему, аднак гэта не зусім зручна, бо больш эфектыўна правяраць праект не пасля таго, як адбылося зліццё галінак, а да яго, на этапе pull request' а.
У цэлым налада аналізу pull request'а не моцна адрозніваецца ад звычайнага запуску аналізу на CI. За выключэннем неабходнасці атрымаць спіс змененых файлаў. Звычайна іх можна атрымаць, запытаўшы розніцу паміж галінкамі пры дапамозе git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listЦяпер трэба перадаць аналізатару на ўваход гэты спіс файлаў. Напрыклад, у PVS-Studio гэта рэалізавана пры дапамозе флага -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listПадрабязней пра аналіз pull request'аў можна даведацца **. Нават калі вашага CI няма ў спісе паказаных у артыкуле сэрвісаў, вам будзе карысны агульны падзел, прысвечаны тэорыі гэтага тыпу аналізу.
Наладзіўшы аналіз pull request'аў вы зможаце блакаваць якія змяшчаюць папярэджанні коміты, тым самым стварыўшы мяжу, якую неправераны код не зможа перасекчы.
Гэта ўсё безумоўна добра, аднак хацелася б мець магчымасць паглядзець усе папярэджанні ў адным месцы. Не толькі ад статычнага аналізатара, але і ад юніт-тэстаў ці ад дынамічнага аналізатара. Для гэтага існуюць розныя сэрвісы і плагіны. PVS-Studio, напрыклад, мае .
2. Інтэграцыя на машыны распрацоўшчыкаў
Цяпер прыйшоў час усталёўкі і налады аналізатара для паўсядзённага выкарыстання пры распрацоўцы. Да гэтага моманту вы ўжо пазнаёміліся з большай часткай спосабаў працы, таму гэта можна назваць самай лёгкай часткай.
Як самы просты варыянт - распрацоўшчыкі самі могуць усталяваць неабходны аналізатар. Аднак гэта зойме шмат часу і адцягне іх ад распрацоўкі, таму вы можаце аўтаматызаваць гэты працэс, выкарыстоўваючы ўсталёўшчык і патрэбныя сцягі. Для PVS-Studio ёсць розныя . Зрэшты, заўсёды ёсць пакетныя мэнэджары, напрыклад, Chocolatey (Windows), Homebrew (macOS) ці дзясяткі варыянтаў для Linux.
Затым трэба будзе ўсталяваць неабходныя плагіны, напрыклад, для , , і г.д.
3. Штодзённае выкарыстанне
На гэтым этапе пара сказаць пару слоў аб спосабах паскарэння працы аналізатара пры штодзённым выкарыстанні. Поўны аналіз усяго праекта займае вельмі шмат часу, аднак ці часта мы змяняем код зараз ва ўсім праекце? Ці ледзь існуе настолькі маштабны рэфактарынг, што адразу закране ўсю кодавую базу. Колькасць змяняных файлаў за раз рэдка перавышае дзясятак, таму іх і ёсць сэнс аналізаваць. Для падобнай сітуацыі існуе . Толькі не палохайцеся, гэта не яшчэ адна прылада. Гэта спецыяльны рэжым, які дазваляе аналізаваць толькі змененыя файлы і іх залежнасці, прычым гэта адбываецца аўтаматычна пасля зборкі, калі вы працуеце ў IDE c усталяваным убудовай.
У выпадку, калі аналізатар выявіць у нядаўна змененым кодзе праблемы, тое паведаміць пра гэта самастойна. Напрыклад, PVS-Studio скажа вам пра гэта пры дапамозе абвесткі:
Само сабой недастаткова сказаць распрацоўнікам выкарыстоўваць прыладу. Трэба неяк ім расказаць, што гэта ўвогуле і як гэта ёсць. Вось, напрыклад, артыкулы пра хуткі старт для PVS-Studio, аднак падобныя тутарыялы вы зможаце знайсці для любой упадабанай вамі прылады:
Падобныя артыкулы даюць усю неабходную для паўсядзённага выкарыстання інфармацыю і не адымаюць шмат часу. 🙂
Яшчэ на этапе знаёмства з інструментам мы здушылі вельмі шмат папярэджанняў падчас аднаго з першых запускаў. Нажаль, але статычныя аналізатары не ідэальныя, таму час ад часу выдаюць ілжывыя спрацоўванні. Здушыць іх звычайна лёгка, напрыклад у плагіне PVS-Studio для Visual Studio дастаткова націснуць на адну кнопку:
Аднак вы можаце не толькі душыць іх. Напрыклад, вы можаце паведаміць у падтрымку аб наяўнасці праблемы. Калі ілжывае спрацоўванне магчыма выправіць, то ў будучых абнаўленнях вы можаце звярнуць увагу на тое, што з кожным разам становіцца ўсё менш і менш спецыфічных для вашай кодавай базы ілжывых спрацоўванняў.
Пасля інтэграцыі
Вось мы і прайшлі ўсе этапы па інтэграцыі статычнага аналізу ў працэс распрацоўкі. Нягледзячы на важнасць налады падобных прылад на CI, самым галоўным месцам запуску з'яўляецца менавіта кампутар распрацоўніка. Бо статычны аналізатар - гэта не суддзя, які кажа дзесьці далёка ад вас, што код нікуды не падыходзіць. Наадварот, гэта памагаты, які падказвае, калі вы стаміліся і нагадвае, калі вы пра што-небудзь забыліся.
Праўда без рэгулярнага выкарыстання статычны аналіз ці наўрад значна спросціць распрацоўку. Бо самая яго галоўная карысць для распрацоўніка складаецца не гэтулькі ў пошуку складаных і спрэчных участкаў кода, колькі ў раннім іх выяўленні. Пагадзіцеся, што выявіць праблему, калі праўкі пайшлі на тэсціраванне, не толькі непрыемна, але і вельмі доўга. Статычны аналіз жа пры рэгулярным выкарыстанні праглядае кожную змену прама на вашым кампутары і паведамляе аб падазроных месцах падчас працы над кодам.
А калі вы ці вашыя калегі ўсё яшчэ не ўпэўненыя, ці варта ўкараняць аналізатар, то прапаную зараз перайсці да чытання артыкула.". У ёй разабраны тыпавыя асцярогі распрацоўшчыкаў аб тым, што статычны аналіз будзе адымаць іх час і гэтак далей.
Калі хочаце падзяліцца гэтым артыкулам з англамоўнай аўдыторыяй, то прашу выкарыстаць спасылку на пераклад: Maxim Zvyagintsev. .
Крыніца: habr.com