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

Лако је испробати статички анализатор кода. Али за његову имплементацију, посебно у развоју великог старог пројекта, потребна је вештина. Ако се уради погрешно, анализатор може додати посао, успорити развој и демотивисати тим. Хајде да укратко поразговарамо о томе како правилно приступити интеграцији статичке анализе у процес развоја и почети да је користимо као део ЦИ/ЦД.

Увод

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

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

Проблеми

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

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

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

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

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

У стварности, у великом пројекту, почетна слика ће бити потпуно другачија. Анализатор издаје стотине или хиљаде упозорења за стари код. Немогуће је брзо схватити која од ових упозорења су релевантна, а која нису. Нерационално је сести и почети да се бавите свим овим упозорењима, јер ће главни посао у овом случају престати данима или недељама. Типично, тим не може себи приуштити такав сценарио. Такође ће постојати велики број разлика које кваре историју промена. А брзо масовно уређивање толиког броја фрагмената у коду ће неизбежно довести до нових грешака у куцању и грешака.

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

Наравно, чак и мање грешке су и даље грешке. А понекад грешка може сакрити праву рањивост. Међутим, одустајање од свега и провођење дана/недеља бавећи се недостацима који се једва испољавају изгледа као сумњива идеја.

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

На свој начин су у праву. Сматрају да прво морају некако да се отарасе свих ових упозорења. Тек тада ће моћи да имају користи од редовне употребе анализатора кода. У супротном, нова упозорења ће се једноставно утопити у старима и нико неће обраћати пажњу на њих.

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

Најгоре у овој причи је ако вас неко одозго у овом тренутку натера да користите статичку анализу кода. Ово ће само демотивисати тим, јер ће, са њихове тачке гледишта, бити додатне бирократске сложености која само стаје на пут. Нико неће гледати извештаје анализатора, а сва употреба ће бити само „на папиру“. Оне. Формално, анализа је уграђена у ДевОпс процес, али у пракси то никоме не користи. Чули смо детаљне приче на штандовима од учесника конференције. Такво искуство може обесхрабрити програмере да користе алате за статичку анализу на дуже време, ако не и заувек.

Имплементација и елиминисање техничког дуга

У ствари, нема ништа тешко или застрашујуће у увођењу статичке анализе чак и у велики стари пројекат.

ЦИ / ЦД

Штавише, анализатор се може одмах учинити делом континуираног процеса развоја. На пример, дистрибуција ПВС-Студио садржи услужне програме за згодан преглед извештаја у формату који вам је потребан и обавештења програмерима који су написали проблематичне делове кода. За оне који су више заинтересовани за покретање ПВС-Студио са ЦИ/ЦД система, препоручујем да се упознате са одговарајућим одељак документацију и низ чланака:

• ПВС-Студио иде у облаке: Азуре Девопс
• ПВС-Студио иде у облаке: Травис ЦИ
• ПВС-Студио иде у облаке: ГитЛаб ЦИ/ЦД
• ПВС-Студио иде у облаке: ЦирцлеЦИ

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

Поправљање постојећег техничког дуга и поступање са новим упозорењима

Савремени комерцијални статички анализатори омогућавају вам да проучавате само нова упозорења која се појављују у новом или измењеном коду. Примена овог механизма је различита, али суштина је иста. У ПВС-Студио статичком анализатору ова функционалност је имплементирана на следећи начин.

Да би брзо почели да користе статичку анализу, предлажемо корисницима ПВС-Студио да користе механизам за масовно сузбијање упозорења [6]. Општа идеја је следећа. Корисник је покренуо анализатор и добио многа упозорења. Пошто пројекат који се развија дуги низ година живи, развија се и зарађује, онда највероватније у извештају неће бити много упозорења која указују на критичне недостатке. Другим речима, критичне грешке су већ исправљене на овај или онај начин коришћењем скупљих метода или захваљујући повратним информацијама купаца. Сходно томе, све што анализатор тренутно пронађе може се сматрати техничким дугом, који је непрактично покушати одмах елиминисати.

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

Сада ће сви програмери видети упозорења која се односе само на нови или промењени код. Дакле, можете почети да користите анализатор, како кажу, од следећег дана. А касније се можете вратити техничком дугу и постепено исправљати грешке и конфигурисати анализатор.

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

Исправке грешака и рефакторинг

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

if (a = b)

Већина Ц++ компајлера и анализатора жале се на такав код, јер постоји велика вероватноћа да су заиста желели да напишу (а == б). Али постоји неизговорени договор, и то се обично наводи у документацији, да ако постоје додатне заграде, онда се сматра да је програмер намерно написао такав код, и нема потребе да се псујете. На пример, у документацији ПВС-Студио за дијагностику В559 (ЦВЕ-481) јасно је написано да ће се следећи ред сматрати исправним и сигурним:

if ((a = b))

Други пример. Да ли је то заборављено у овом Ц++ коду? разбити или не?

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

ПВС-Студио анализатор ће овде издати упозорење В796 (ЦВЕ-484). Ово можда није грешка, у ком случају би требало да дате парсеру наговештај додавањем атрибута [[пропасти]] или на пример __атрибут__((прескок)):

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

Може се рећи да такве промене кода не поправљају грешку. Да, то је тачно, али чини две корисне ствари. Прво, извештај анализатора се ослобађа лажних позитивних резултата. Друго, код постаје разумљивији за људе који су укључени у његово одржавање. А ово је веома важно! Само за ово, вреди извршити мања преправљања да би код био јаснији и лакши за одржавање. Пошто анализатор не разуме да ли је „прекид“ потребан или не, колегама програмерима такође неће бити јасно.

Поред исправки грешака и рефакторисања, можете посебно потиснути очигледно лажна упозорења анализатора. Неке небитне дијагностике могу бити онемогућене. На пример, неко мисли да су упозорења бесмислена ВКСНУМКС о поређењу флоат/доубле вредности. А неки их класификују као важне и вредне проучавања [7]. Која упозорења се сматрају релевантним, а која нису, одлучује развојни тим.

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

Такође, увек помажемо нашим клијентима да подесе ПВС-Студио ако се појаве било какви проблеми. Штавише, било је случајева када смо сами елиминисали лажна упозорења и исправљали грешке [8]. За сваки случај одлучио сам да напоменем да је могућа и ова опција за проширену сарадњу :).

Ратцхет метода

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

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

Чак и ако особа жели да мало превари и одлучи да прође капију квалитета не уклањањем упозорења у свом новом коду, већ побољшањем старог кода треће стране, то није страшно. Свеједно, чегртаљка се окреће у једном правцу, а постепено ће се смањити број недостатака. Чак и ако особа не жели да поправи своје нове недостатке, ипак ће морати нешто да побољша у суседном коду. У неком тренутку се завршавају лаки начини за смањење броја упозорења и долази тренутак када ће праве грешке бити поправљене.

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

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

Закључак

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

Постоје и друге типичне сумње о томе да ли статичка анализа заиста може бити згодна и корисна. Већину ових недоумица покушао сам да отклоним у публикацији „Разлози за увођење ПВС-Студио статичког анализатора кода у процес развоја“ [9].

Хвала вам на пажњи и дођите преузети и испробајте ПВС-Студио анализатор.

Додатне везе

1. Андреј Карпов. Како могу брзо да видим занимљива упозорења која ПВС-Студио анализатор производи за Ц и Ц++ код?
2. Википедиа. Рајсова теорема.
3. Андреј Карпов, Викторија Кханиева. Коришћење машинског учења у статичкој анализи изворног кода програма.
4. ПВС-Студио. Документација. Додатне дијагностичке поставке.
5. Андреј Карпов. Карактеристике ПВС-Студио анализатора на примеру ЕФЛ Цоре Либрариес, 10-15% лажних позитивних резултата.
6. ПВС-Студио. Документација. Масовно потискивање порука анализатора.
7. Иван Андриасхин. О томе како смо тестирали статичку анализу на нашем пројекту образовног симулатора рендгенске ендоваскуларне хирургије.
8. Павел Еремеев, Свиатослав Размислов. Како је ПВС-Студио тим побољшао Унреал Енгине код.
9. Андреј Карпов. Разлози за увођење статичког анализатора кода ПВС-Студио у процес развоја.

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

Извор: ввв.хабр.цом