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

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

Вовед

Неодамна моето внимание го привлече публикацијата "Започнете со статичка анализа без да го надминете тимот". Од една страна, ова е добра статија со која вреди да се запознаеме. Од друга страна, ми се чини дека сè уште не дава целосен одговор за тоа како безболно да се спроведе статичка анализа во проект со многу Написот вели дека можете да прифатите технички долг и да работите само на нов код, но нема одговор што да правите со овој технички долг подоцна.

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

Прашања

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

Сите статички анализатори произведуваат лажни позитиви. Ова е карактеристика на методологијата за анализа на статички код и ништо не може да се направи за тоа. Во општ случај, ова е нерешлив проблем, како што е потврдено со теоремата на Рајс [2]. Нема да помогнат ниту алгоритмите за машинско учење [3]. Дури и ако некое лице не може секогаш да каже дали овој или оној код е погрешен, тогаш не треба да го очекувате ова од програмата :).

Лажните позитиви не се проблем ако статичкиот анализатор е веќе конфигуриран:

Оневозможени ирелевантни множества правила;
Некои ирелевантни дијагностика се оневозможени;
Ако зборуваме за C или C++, тогаш се означени макроата кои содржат специфични конструкции кои предизвикуваат бескорисни предупредувања да се појавуваат на секое место каде што се користат такви макроа;
Означени се сопствени функции кои вршат дејства слични на функциите на системот (свој аналог спомен или печати) [4];
Лажните позитиви се конкретно оневозможени со користење на коментари;
И така натаму.

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

Во реалноста, во голем проект, првичната слика ќе биде сосема поинаква. Анализаторот издава стотици или илјадници предупредувања за наследниот код. Невозможно е брзо да се разбере кои од овие предупредувања се релевантни, а кои не се. Нерационално е да се седне и да почне да се занимава со сите овие предупредувања, бидејќи главната работа во овој случај ќе престане со денови или недели. Типично, тимот не може да си дозволи такво сценарио. Исто така, ќе има огромен број на разлики што ќе ја нарушат историјата на промени. И брзото масовно уредување на толку многу фрагменти во кодот неизбежно ќе резултира со нови печатни грешки и грешки.

И што е најважно, таков подвиг во борбата против предупредувањата има малку смисла. Согласете се дека бидејќи проектот успешно работи долги години, повеќето критични грешки во него се веќе поправени. Да, овие поправки беа многу скапи, мораа да се дебагираат, добија негативни повратни информации од корисниците за грешките итн. Статичкиот анализатор ќе помогне да се поправат многу од овие грешки во фазата на кодирање, брзо и ефтино. Но, во моментов, на еден или друг начин, овие грешки се поправени, а анализаторот главно открива некритични грешки во стариот код. Овој код може да не се користи, може да се користи многу ретко, а грешка во него може да не доведе до забележителни последици. Можеби некаде сенката од копчето е со погрешна боја, но тоа не се меша со ничија употреба на производот.

Се разбира, и малите грешки се сепак грешки. И понекогаш грешката може да скрие вистинска ранливост. Сепак, откажувањето од сè и поминувањето денови/недели за справување со дефекти кои едвај се манифестираат изгледа како сомнителна идеја.

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

На свој начин, тие се во право. Тие сметаат дека прво треба некако да се ослободат од сите овие предупредувања. Само тогаш тие ќе можат да имаат корист од редовната употреба на анализаторот на кодови. Во спротивно, новите предупредувања едноставно ќе се удават во старите, и никој нема да обрнува внимание на нив.

Ова е иста аналогија како и со предупредувањата на компајлерот. Не е без причина што препорачуваат да се задржи бројот на предупредувања од компајлерот на 0. Ако има 1000 предупредувања, тогаш кога ги има 1001, никој нема да обрнува внимание на тоа, а не е јасно каде да се бара ова најново предупредување.

Најлошото нешто во оваа приказна е ако некој одозгора во овој момент ве принуди да користите статичка анализа на кодови. Ова само ќе го демотивира тимот, бидејќи од нивна гледна точка ќе има дополнителна бирократска сложеност што само ќе му пречи. Никој нема да ги гледа извештаите на анализаторот и целата употреба ќе биде само „на хартија“. Оние. Формално, анализата е вградена во процесот DevOps, но во пракса тоа никому не му користи. Слушнавме детални приказни на штандовите од присутните на конференцијата. Таквото искуство може да ги обесхрабри програмерите да користат алатки за статичка анализа долго време, ако не и засекогаш.

Спроведување и отстранување на технички долг

Всушност, нема ништо тешко или страшно во воведувањето статичка анализа дури и во голем стар проект.

CI / CD

Покрај тоа, анализаторот може веднаш да се направи дел од процесот на континуиран развој. На пример, дистрибуцијата PVS-Studio содржи алатки за практично гледање на извештајот во формат што ви треба и известувања до програмерите кои напишале проблематични делови од кодот. За оние кои се повеќе заинтересирани за лансирање на PVS-Studio од CI/CD системи, препорачувам да се запознаете со соодветните дел документација и серија написи:

Но, да се вратиме на прашањето за голем број лажни позитиви во првите фази на имплементација на алатките за анализа на кодови.

Поправање на постоечки технички долг и справување со нови предупредувања

Современите комерцијални статички анализатори ви дозволуваат да проучувате само нови предупредувања што се појавуваат во нов или променет код. Имплементацијата на овој механизам варира, но суштината е иста. Во статичкиот анализатор PVS-Studio, оваа функционалност е имплементирана на следниов начин.

За брзо започнување со користење на статичка анализа, им предлагаме на корисниците на PVS-Studio да го користат механизмот за масовно сузбивање на предупредувањата [6]. Општата идеја е следна. Корисникот го стартуваше анализаторот и доби многу предупредувања. Бидејќи проект кој се развива долги години е жив, се развива и заработува пари, тогаш најверојатно нема да има многу предупредувања во извештајот што укажуваат на критични дефекти. Со други зборови, критичните грешки веќе се поправени на еден или друг начин користејќи поскапи методи или благодарение на повратните информации од клиентите. Соодветно на тоа, сè што моментално наоѓа анализаторот може да се смета за технички долг, што е непрактично да се обиде веднаш да се елиминира.

Можете да му кажете на PVS-Studio да ги смета овие предупредувања за ирелевантни засега (зачувајте технички долг за подоцна) и веќе нема да ги прикажува. Анализаторот создава посебна датотека каде што зачувува информации за грешки кои сè уште не се интересни. И сега PVS-Studio ќе издава предупредувања само за нов или променет код. Покрај тоа, сето ова се спроведува паметно. Ако, на пример, се додаде празна линија на почетокот на датотеката со изворниот код, тогаш анализаторот разбира дека, всушност, ништо не се променило и ќе продолжи да молчи. Оваа датотека за обележување може да се стави во систем за контрола на верзијата. Датотеката е голема, но тоа не е проблем, бидејќи нема смисла често да се складира.

Сега сите програмери ќе гледаат предупредувања поврзани само со нов или променет код. Така, можете да започнете со користење на анализаторот, како што велат, од следниот ден. И можете да се вратите на технички долг подоцна, и постепено да ги коригирате грешките и да го конфигурирате анализаторот.

Значи, првиот проблем со имплементацијата на анализаторот во голем стар проект е решен. Сега да откриеме што да правиме со техничкиот долг.

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

Наједноставната и најприродната работа е да одвоите малку време за да ги анализирате масовно потиснатите предупредувања од анализаторот и постепено да се справите со нив. Некаде треба да ги поправите грешките во кодот, некаде да рефакторирате за да му кажете на анализаторот дека кодот не е проблематичен. Едноставен пример:

if (a = b)

Повеќето компајлери и анализатори на C++ се жалат на таков код, бидејќи постои голема веројатност дека тие навистина сакале да напишат (а == б). Но, постои неизговорен договор, а тоа обично се забележува во документацијата, дека ако има дополнителни загради, тогаш се смета дека програмерот намерно напишал таков код и нема потреба да се пцуе. На пример, во документацијата 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/двојни вредности. А некои ги класифицираат како важни и достојни за проучување [7]. Кои предупредувања се сметаат за релевантни, а кои не, зависи од развојот на тимот.

Постојат и други начини да се потиснат лажните предупредувања. На пример, макро обележувањето беше споменато претходно. Сето ова е подетално опишано во документацијата. Најважно е да разберете дека ако постепено и систематски пристапувате кон работата со лажни позитиви, нема ништо лошо во нив. Огромното мнозинство на неинтересни предупредувања исчезнуваат по конфигурацијата, а остануваат само местата кои навистина бараат внимателно проучување и некои промени во кодот.

Исто така, секогаш им помагаме на нашите клиенти да го постават PVS-Studio доколку се појават какви било тешкотии. Покрај тоа, имаше случаи кога ние самите елиминиравме лажни предупредувања и коригиравме грешки [8]. За секој случај решив да напоменам дека е можна и оваа опција за продолжена соработка :).

Метод на преплет

Постои уште еден интересен пристап за постепено подобрување на квалитетот на кодот со елиминирање на предупредувањето од статичкиот анализатор. Во крајна линија е дека бројот на предупредувања може само да се намали.

Се евидентира бројот на предупредувања издадени од статичкиот анализатор. Портата за квалитет е конфигурирана на таков начин што сега можете да внесете само код што не го зголемува бројот на операции. Како резултат на тоа, процесот на постепено намалување на бројот на аларми започнува со прилагодување на анализаторот и коригирање на грешките.

Дури и ако некое лице сака малку да измами и одлучи да ја помине портата за квалитет не со елиминирање на предупредувањата во неговиот нов код, туку со подобрување на стариот код од трета страна, ова не е страшно. Сеедно, крцкалката се ротира во една насока и постепено бројот на дефекти ќе се намалува. Дури и ако некое лице не сака да ги поправи сопствените нови дефекти, сепак ќе мора да подобри нешто во соседниот код. Во одреден момент, лесните начини за намалување на бројот на предупредувања завршуваат, и доаѓа момент кога вистинските грешки ќе бидат поправени.

Оваа методологија е подетално опишана во многу интересна статија на Иван Пономарев “Спроведување на статичка анализа во процесот, наместо да барате грешки со неа“, што им препорачувам да го прочитаат на сите заинтересирани за подобрување на квалитетот на кодот.

Извештај на оваа тема има и авторот на статијата: „Континуирана статичка анализа".

Заклучок

Се надевам дека по овој напис, читателите повеќе ќе ги прифаќаат алатките за статичка анализа и ќе сакаат да ги имплементираат во процесот на развој. Ако имате какви било прашања, ние сме секогаш подготвени советува корисници на нашиот статичен анализатор PVS-Studio и помагаат во неговата имплементација.

Постојат и други типични сомнежи за тоа дали статичката анализа навистина може да биде удобна и корисна. Се обидов да ги отфрлам повеќето од овие сомнежи во публикацијата „Причини за воведување на статичниот анализатор на код PVS-Studio во процесот на развој“ [9].

Ви благодариме за вниманието и дојдете преземете и пробајте го PVS-Studio анализаторот.

Дополнителни врски

Андреј Карпов. Како можам брзо да видам интересни предупредувања што ги произведува PVS-Studio анализаторот за C и C++ кодот?
Википедија. Теорема на Рајс.
Андреј Карпов, Викторија Ханиева. Користење на машинско учење во статичка анализа на изворниот код на програмата.
ПВС-Студио. Документација. Дополнителни дијагностички поставки.
Андреј Карпов. Карактеристики на анализаторот PVS-Studio користејќи го примерот на EFL Core Libraries, 10-15% лажни позитиви.
ПВС-Студио. Документација. Масовно сузбивање на пораките на анализаторот.
Иван Андриашин. За тоа како тестиравме статичка анализа на нашиот проект за едукативен симулатор за ендоваскуларна хирургија на Х-зраци.
Павел Еремеев, Свјатослав Размислов. Како тимот на PVS-Studio го подобри кодот на Unreal Engine.
Андреј Карпов. Причини за воведување на статичниот анализатор на код PVS-Studio во процесот на развој.

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

Извор: www.habr.com

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