🥇Статичен анализ – от запознаване до интеграция

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

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

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

Но това е очевидна грешка. А ако разработчикът е написал неоптимален код, защото е забравил някаква особеност на езика? Или дори е допуснал в кода неопределено поведение? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

За интеграция на анализа в CI трябва да се направят три неща:

Да инсталирате анализатора;
Да стартирате анализа;
Доставете резултати.

Например, за инсталиране на PVS-Studio на Linux (базирано на Debian) трябва да изпълните следните команди:

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).

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

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

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

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

След това ще трябва да инсталирате необходимите плъгини, например, за Visual Studio, IDEA, Rider и т.н.

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

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

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

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

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

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

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

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

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

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

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

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

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