Статичен анализ – от въведение към интегриране

Уморен от безкраен преглед на код или отстраняване на грешки, понякога мислите как да опростите живота си. И след като потърсите малко или случайно се натъкнете на него, можете да видите вълшебната фраза: „Статичен анализ“. Нека да видим какво представлява и как може да взаимодейства с вашия проект.

Всъщност, ако пишете на който и да е съвременен език, тогава, без дори да го осъзнавате, сте го пуснали през статичен анализатор. Факт е, че всеки съвременен компилатор предоставя, макар и малък, набор от предупреждения за потенциални проблеми в кода. Например, когато компилирате C++ код във Visual Studio, може да видите следното:

В този изход виждаме, че променливата Var никога не е бил използван никъде във функцията. Така че в действителност почти винаги сте използвали прост анализатор на статичен код. Въпреки това, за разлика от професионалните анализатори като 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 издава следното предупреждение:

V537 Помислете за преглед на коректността на използването на елемента „y“.

Ако искате да бръкнете в тази грешка, опитайте готов пример в Compiler Explorer: *кликване*.

И както разбирате, не винаги е възможно да се обърне внимание на такива части от кода веднага и поради това можете да седнете да отстранявате грешки за добър час, чудейки се защо всичко работи толкова странно.

Това обаче очевидно е грешка. Какво ще стане, ако разработчикът е написал неоптимален код, защото е забравил някои тънкости на езика? Или дори го допуска в кода неопределено поведение? За съжаление, такива случаи са напълно обичайни и лъвският дял от времето се изразходва за отстраняване на грешки в конкретно работещ код, който съдържа печатни грешки, типични грешки или недефинирано поведение.

Именно за тези ситуации се появи статичният анализ. Това е помощник за разработчика, който ще посочи различни проблеми в кода и ще обясни в документацията защо не е необходимо да се пише по този начин, до какво може да доведе и как да го коригирате. Ето пример за това как може да изглежда: *кликване*.

Можете да намерите още интересни грешки, които анализаторът може да открие в статиите:

• Топ 10 на грешките в C++ проекти за 2019 г
• Топ 10 на грешките в C# проекти за 2019 г
• Топ 10 на грешки в Java проекти за 2019 г

Сега, след като сте прочели този материал и сте се убедили в предимствата на статичния анализ, може да искате да го изпробвате. Но откъде да започнем? Как да интегрирате нов инструмент в текущия си проект? И как да запознаете екипа с него? Ще намерите отговори на тези въпроси по-долу.

Забележка. Статичният анализ не замества или отменя такова полезно нещо като прегледите на кода. Той допълва този процес, като помага да забележите и коригирате предварително печатни грешки, неточности и опасни дизайни. Много по-продуктивно е да се съсредоточите върху прегледите на кода на алгоритмите и яснотата на кода, вместо да търсите неправилно поставени скоби или прочетете скучните функции за сравнение.

0. Запознаване с инструмента

Всичко започва с пробна версия. Наистина е трудно да решите да внедрите нещо в процеса на разработка, ако никога преди не сте виждали инструмента на живо. Следователно първото нещо, което трябва да направите, е да изтеглите пробна версия.

Какво ще научите на този етап:

• Какви са начините за взаимодействие с анализатора;
• Съвместим ли е анализаторът с вашата среда за разработка?
• Какви проблеми има в момента във вашите проекти?

След като инсталирате всичко необходимо, първото нещо, което трябва да направите, е да направите анализ на целия проект (Windows, Linux, macOS). В случай на PVS-Studio във Visual Studio ще видите подобна картина (може да се кликне):

Факт е, че статичните анализатори обикновено издават огромен брой предупреждения за проекти с голяма кодова база. Няма нужда да ги коригирате всички, тъй като вашият проект вече работи, което означава, че тези проблеми не са критични. Въпреки това вие можете да разгледате най-интересните предупреждения и ги коригирайте, ако е необходимо. За да направите това, трябва да филтрирате изхода и да оставите само най-надеждните съобщения. В приставката PVS-Studio за Visual Studio това става чрез филтриране по нива и категории на грешки. За най-точен резултат оставете само Високо и общ (също може да се кликне):

Наистина, 178 предупреждения са много по-лесни за разглеждане от няколко хиляди...

В раздели Среден и ниско Често има добри предупреждения, но тези категории включват тези диагностики, които имат по-малка точност (надеждност). Повече информация за нивата на предупреждение и опциите за работа под Windows можете да намерите тук: *кликване*.

Успешният преглед на най-интересните грешки (и успешното им коригиране) си струва потискане на останалите предупреждения. Това е необходимо, за да не се изгубят новите предупреждения сред старите. В допълнение, статичният анализатор е помощник за програмиста, а не списък с грешки. 🙂

1. Автоматизация

След като се запознаете, е време да конфигурирате плъгини и да се интегрирате в CI. Това трябва да се направи преди програмистите да започнат да използват статичния анализатор. Факт е, че програмистът може да забрави да активира анализа или изобщо да не иска да го направи. За да направите това, трябва да направите окончателна проверка на всичко, така че нетестваният код да не може да влезе в общия клон за разработка.

Какво ще научите на този етап:

• Какви възможности за автоматизация предоставя инструментът;
• Съвместим ли е анализаторът с вашата система за сглобяване?

Тъй като перфектна документация не съществува, понякога трябва да пишете поддържа. Това е нормално и ние се радваме да ви помогнем. 🙂

Сега нека да преминем към услугите за непрекъсната интеграция (CI). Всеки анализатор може да бъде внедрен в тях без сериозни проблеми. За да направите това, трябва да създадете отделен етап в тръбопровода, който обикновено се намира след изграждането и тестовете на модула. Това се прави с помощта на различни конзолни помощни програми. Например PVS-Studio предоставя следните помощни програми:

• PVS-Studio_Cmd.exe (анализ на решения, C#, C++ проекти на Windows)
• CLMonitor.exe (мониторинг на компилация)
• pvs-studio-анализатор (анализ на C++ проекти на Linux / macOS)
• pvs-studio-dotnet (анализ на решение, C# проекти на Linux / macOS)
• pvs-studio.jar (анализ на Java проекти)
• PlogConverter (конвертор на отчетни файлове)

За да интегрирате анализа в 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 в статията "PVS-Studio и непрекъсната интеграция" (Windows) или "Как да настроите PVS-Studio в Travis CI“ (Linux).

Добре, конфигурирахте анализатора на сървъра за изграждане. Сега, ако някой качи нетестван код, етапът на проверка ще се провали и вие ще можете да откриете проблема, но това не е съвсем удобно, тъй като е по-ефективно да проверите проекта не след като клоновете са обединени, а преди него, на етапа на заявка за изтегляне.

Като цяло, настройването на анализ на заявка за изтегляне не се различава много от обичайното стартиране на анализ на 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

Можете да научите повече за анализирането на заявки за изтегляне *тук*. Дори ако вашият CI не е в списъка с услуги, споменати в статията, общият раздел, посветен на теорията на този тип анализ, ще ви бъде полезен.

Чрез настройване на анализ на заявки за изтегляне можете да блокирате ангажименти, съдържащи предупреждения, като по този начин създавате граница, която нетестваният код не може да премине.

Всичко това със сигурност е добре, но бих искал да мога да видя всички предупреждения на едно място. Не само от статичния анализатор, но и от модулни тестове или от динамичния анализатор. Има различни услуги и добавки за това. PVS-Studio, например, има плъгин за интегриране в SonarQube.

2. Интеграция на машини за разработчици

Сега е време да инсталирате и конфигурирате анализатора за ежедневна употреба при разработка. До този момент вече сте се запознали с повечето от начините на работа, така че това може да се нарече най-лесната част.

Като най-простият вариант разработчиците могат сами да инсталират необходимия анализатор. Това обаче ще отнеме много време и ще ги отвлече от разработката, така че можете да автоматизирате този процес с помощта на инсталатор и необходимите флагове. За PVS-Studio има различни флагове за автоматизирана инсталация. Винаги обаче има мениджъри на пакети, например Chocolatey (Windows), Homebrew (macOS) или десетки опции за Linux.

След това ще трябва да инсталирате необходимите добавки, например за Visual Studio, ИДЕЯ, Ездач и т.н.

3. Ежедневна употреба

На този етап е време да кажем няколко думи за начините за ускоряване на анализатора по време на ежедневна употреба. Пълният анализ на целия проект отнема много време, но колко често променяме кода в целия проект наведнъж? Едва ли има рефакторинг, който да е толкова голям, че веднага да засегне цялата кодова база. Броят на файловете, които се променят наведнъж, рядко надвишава дузина, така че има смисъл да ги анализирате. За такава ситуация има режим на инкрементален анализ. Просто не се тревожете, това не е друг инструмент. Това е специален режим, който ви позволява да анализирате само променени файлове и техните зависимости и това се случва автоматично след изграждането, ако работите в IDE с инсталиран плъгин.

Ако анализаторът открие проблеми в наскоро променения код, той ще докладва това независимо. Например PVS-Studio ще ви каже за това, като използва предупреждение:

Разбира се, да кажете на разработчиците да използват инструмента не е достатъчно. Трябва по някакъв начин да им кажем какво е и как е. Ето, например, статии за бърз старт на PVS-Studio, но можете да намерите подобни уроци за всеки инструмент, който предпочитате:

• Как да стартирате PVS-Studio на Windows (C, C++, C#)
• Как да стартирате PVS-Studio на Linux и macOS (C, C++)
• Как да стартирате PVS-Studio Java

Такива статии предоставят цялата необходима информация за ежедневна употреба и не отнемат много време. 🙂

Дори на етапа на запознаване с инструмента, ние потиснахме много предупреждения по време на едно от първите стартирания. За съжаление, статичните анализатори не са перфектни, така че от време на време дават фалшиви положителни резултати. Обикновено е лесно да ги потиснете; например в приставката PVS-Studio за Visual Studio трябва само да щракнете върху един бутон:

Можете обаче да направите повече от това просто да ги потискате. Например, можете да съобщите за проблем на поддръжката. Ако фалшивият положителен резултат може да бъде коригиран, тогава в бъдещи актуализации можете да забележите, че всеки път има все по-малко и по-малко фалшиви положителни резултати, специфични за вашата кодова база.

След интеграция

Така че ние преминахме през всички етапи на интегриране на статичен анализ в процеса на разработка. Въпреки важността на настройването на такива инструменти в CI, най-важното място за тяхното стартиране е компютърът на разработчика. В крайна сметка статичният анализатор не е съдник, който казва някъде далеч от вас, че кодът не е добър. Напротив, това е асистент, който ви казва дали сте уморени и ви напомня, ако сте забравили нещо.

Вярно е, че без редовна употреба статичният анализ едва ли ще опрости значително разработката. В края на краищата основната му полза за разработчика се крие не толкова в търсенето на сложни и противоречиви части от кода, а в ранното им откриване. Съгласете се, че откриването на проблем, след като редакциите са изпратени за тестване, е не само неприятно, но и много времеемко. Статичният анализ, когато се използва редовно, разглежда всяка промяна директно на вашия компютър и отчита подозрителни места, докато работите върху кода.

И ако вие или вашите колеги все още не сте сигурни дали си струва да внедрите анализатора, предлагам ви сега да започнете да четете статията "Причини за въвеждане на статичен анализатор на код PVS-Studio в процеса на разработка". Той адресира типичните опасения на разработчиците, че статичният анализ ще им отнеме време и т.н.

Ако искате да споделите тази статия с англоговоряща аудитория, моля, използвайте връзката за превод: Максим Звягинцев. Статичен анализ: от първите стъпки до интегрирането.

Източник: www.habr.com