Как да внедрите анализатор на статичен код в наследен проект, без да демотивирате екипа

Лесно е да опитате анализатор на статичен код. Но прилагането му, особено при разработването на голям стар проект, изисква умения. Ако се направи неправилно, анализаторът може да добави работа, да забави развитието и да демотивира екипа. Нека поговорим накратко за това как правилно да подходим към интегрирането на статичен анализ в процеса на разработка и да започнем да го използваме като част от CI/CD.

въведение

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

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

Проблеми

Обикновено не е трудно да стартирате и да видите как работи статичен анализатор [1]. Може да видите интересни грешки или дори страшни потенциални уязвимости в кода. Можете дори да поправите нещо, но след това много програмисти се отказват.

Всички статични анализатори дават фалшиви положителни резултати. Това е характеристика на методологията за анализ на статичен код и нищо не може да се направи по въпроса. В общия случай това е неразрешим проблем, както се потвърждава от теоремата на Райс [2]. Алгоритмите за машинно обучение също няма да помогнат [3]. Дори ако човек не винаги може да каже дали този или онзи код е грешен, тогава не трябва да очаквате това от програмата :).

Фалшивите положителни резултати не са проблем, ако статичният анализатор вече е конфигуриран:

• Дезактивирани неподходящи набори от правила;
• Някои неуместни диагностики са деактивирани;
• Ако говорим за C или C++, тогава се маркират макроси, които съдържат специфични конструкции, които причиняват безполезни предупреждения да се появяват на всяко място, където се използват такива макроси;
• Маркирани са собствени функции, които изпълняват действия, подобни на системните функции (негов собствен аналог memcpy или ФОРМАТ) [4];
• Фалшивите положителни резултати са специално деактивирани чрез коментари;
• И така нататък.

В този случай можем да очакваме нисък фалшив положителен процент от около 10-15% [5]. С други думи, 9 от 10 предупреждения на анализатора ще показват реален проблем в кода или поне „силно миришещ код“. Съгласете се, този сценарий е изключително приятен, а анализаторът е истински приятел на програмиста.

Реално при голям проект първоначалната картина ще бъде съвсем различна. Анализаторът издава стотици или хиляди предупреждения за наследен код. Невъзможно е бързо да се разбере кои от тези предупреждения са уместни и кои не. Ирационално е да седнете и да започнете да се справяте с всички тези предупреждения, тъй като основната работа в този случай ще спре за дни или седмици. Обикновено един отбор не може да си позволи такъв сценарий. Ще има и огромен брой разлики, които развалят историята на промените. И бързото масово редактиране на толкова много фрагменти в кода неизбежно ще доведе до нови правописни и грешки.

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

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

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

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

Това е същата аналогия като с предупрежденията на компилатора. Не напразно препоръчват броят на предупрежденията на компилатора да остане 0. Ако има 1000 предупреждения, тогава когато има 1001, никой няма да му обърне внимание и не е ясно къде да търсим това най-ново предупреждение.

Най-лошото в тази история е, ако някой отгоре в този момент ви принуди да използвате статичен анализ на кода. Това само ще демотивира екипа, тъй като от тяхна гледна точка ще има допълнителна бюрократична сложност, която само ще пречи. Никой няма да гледа отчетите на анализатора и цялата употреба ще бъде само „на хартия“. Тези. Формално анализът е вграден в процеса DevOps, но на практика това не е от полза за никого. Чухме подробни истории на щандове от участници в конференцията. Такова преживяване може да обезсърчи програмистите да използват инструменти за статичен анализ за дълго време, ако не и завинаги.

Внедряване и премахване на технически дълг

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

CI / CD

Освен това анализаторът може незабавно да стане част от непрекъснатия процес на разработка. Например, дистрибуцията на PVS-Studio съдържа помощни програми за удобно разглеждане на отчета във формата, от който се нуждаете, и известия за разработчици, които са написали проблемни секции от кода. За тези, които се интересуват повече от стартирането на PVS-Studio от CI/CD системи, препоръчвам да се запознаете със съответните раздел документация и поредица от статии:

• PVS-Studio отива в облаците: Azure Devops
• PVS-Studio отива в облаците: Travis CI
• PVS-Studio отива в облаците: GitLab CI/CD
• PVS-Studio отива в облаците: CircleCI

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

Коригиране на съществуващ технически дълг и справяне с нови предупреждения

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

За да започнете бързо да използвате статичен анализ, предлагаме на потребителите на PVS-Studio да използват механизма за масово потискане на предупреждения [6]. Общата идея е следната. Потребителят стартира анализатора и получи много предупреждения. Тъй като проект, който се разработва от много години, е жив, развива се и печели пари, тогава най-вероятно няма да има много предупреждения в доклада, показващи критични дефекти. С други думи, критичните грешки вече са коригирани по един или друг начин с помощта на по-скъпи методи или благодарение на обратна връзка от клиенти. Съответно всичко, което анализаторът намира в момента, може да се счита за технически дълг, което е непрактично да се опитвате да елиминирате незабавно.

Можете да кажете на PVS-Studio да счита тези предупреждения за неуместни засега (запазете технически дълг за по-късно) и то повече няма да ги показва. Анализаторът създава специален файл, където записва информация за грешки, които все още не са интересни. И сега PVS-Studio ще издава предупреждения само за нов или променен код. Освен това всичко това е изпълнено хитро. Ако например се добави празен ред в началото на файла с изходния код, тогава анализаторът разбира, че всъщност нищо не се е променило и ще продължи да мълчи. Този маркиращ файл може да бъде поставен в система за контрол на версиите. Файлът е голям, но това не е проблем, тъй като няма смисъл да го съхранявате често.

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

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

Поправки на грешки и преработки

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

if (a = b)

Повечето C++ компилатори и анализатори се оплакват от такъв код, тъй като има голяма вероятност те наистина да искат да пишат (a == b). Но има негласно споразумение и това обикновено се отбелязва в документацията, че ако има допълнителни скоби, тогава се счита, че програмистът умишлено е написал такъв код и няма нужда да се кълнете. Например в документацията на PVS-Studio за диагностика V559 (CWE-481) ясно е написано, че следният ред ще се счита за правилен и безопасен:

if ((a = b))

Друг пример. Забравено ли е в този C++ код? почивка или не?

case A:
  foo();
case B:
  bar();
  break;

Анализаторът на PVS-Studio ще издаде предупреждение тук V796 (CWE-484). Това може да не е грешка, в който случай трябва да дадете подсказка на анализатора, като добавите атрибута [[пропадам]] или например __атрибут__((пропадане)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

Може да се каже, че подобни промени в кода не коригират грешката. Да, това е вярно, но прави две полезни неща. Първо, отчетът на анализатора премахва фалшивите положителни резултати. Второ, кодът става по-разбираем за хората, участващи в поддръжката му. И това е много важно! Само за това си струва да извършите малки преработки, за да направите кода по-ясен и лесен за поддръжка. Тъй като анализаторът не разбира дали е необходим „прекъсване“ или не, това също ще бъде неясно за колегите програмисти.

В допълнение към корекциите на грешки и преработването, можете конкретно да потискате очевидно фалшивите предупреждения на анализатора. Някои неуместни диагностики могат да бъдат деактивирани. Например някой смята, че предупрежденията са безсмислени V550 относно сравняването на float/double стойности. И някои ги класифицират като важни и заслужаващи изучаване [7]. Кои предупреждения се считат за уместни и кои не, зависи от екипа за разработка.

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

Освен това винаги помагаме на нашите клиенти да настроят PVS-Studio, ако възникнат затруднения. Освен това имаше случаи, когато ние сами елиминирахме фалшиви предупреждения и коригирахме грешки [8]. За всеки случай реших да спомена, че е възможен и този вариант за разширено сътрудничество :).

Метод на тресчотка

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

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

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

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

Авторът на статията също има доклад по тази тема: "Непрекъснат статичен анализ".

Заключение

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

Има и други типични съмнения относно това дали статичният анализ наистина може да бъде удобен и полезен. Опитах се да разсея повечето от тези съмнения в публикацията „Причини за въвеждане на анализатора на статичен код PVS-Studio в процеса на разработка“ [9].

Благодаря ви за вниманието и заповядайте изтеглите и опитайте анализатора PVS-Studio.

Допълнителни връзки

1. Андрей Карпов. Как мога бързо да видя интересни предупреждения, които PVS-Studio анализаторът произвежда за C и C++ код?
2. Wikipedia. Теорема на Райс.
3. Андрей Карпов, Виктория Ханиева. Използване на машинно обучение при статичен анализ на изходния код на програмата.
4. PVS-студио. Документация. Допълнителни диагностични настройки.
5. Андрей Карпов. Характеристики на анализатора PVS-Studio, използвайки примера на EFL Core Libraries, 10-15% фалшиви положителни резултати.
6. PVS-студио. Документация. Масово потискане на съобщенията на анализатора.
7. Иван Андряшин. За това как тествахме статичен анализ на нашия проект за образователен симулатор на рентгенова ендоваскуларна хирургия.
8. Павел Еремеев, Святослав Размислов. Как екипът на PVS-Studio подобри кода на Unreal Engine.
9. Андрей Карпов. Причини за въвеждане на статичен анализатор на код PVS-Studio в процеса на разработка.

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

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