Հեշտ է փորձել ստատիկ կոդերի անալիզատորը: Բայց այն իրականացնելու համար, հատկապես մեծ հին նախագծի մշակման ժամանակ, հմտություն է պետք: Եթե սխալ է արվում, անալիզատորը կարող է ավելացնել աշխատանք, դանդաղեցնել զարգացումը և հեռացնել թիմին: Եկեք հակիրճ խոսենք այն մասին, թե ինչպես ճիշտ մոտենալ ստատիկ վերլուծության ինտեգրմանը զարգացման գործընթացին և սկսել օգտագործել այն որպես CI/CD-ի մաս:
Ներածություն
Վերջերս իմ ուշադրությունը գրավեց հրապարակումը «Սա մի կողմից լավ հոդված է, որի հետ արժե ծանոթանալ: Մյուս կողմից, ինձ թվում է, որ այն դեռևս ամբողջական պատասխան չի տալիս, թե ինչպես կարելի է անցավ իրականացնել ստատիկ վերլուծություն շատ բան ունեցող նախագծում: Հոդվածում ասվում է, որ դուք կարող եք ընդունել տեխնիկական պարտքը և աշխատել միայն նոր կոդի վրա, սակայն պատասխան չկա, թե ինչ անել այս տեխնիկական պարտքի հետ հետո:
Մեր PVS-Studio թիմն առաջարկում է իր տեսակետն այս թեմայի վերաբերյալ: Տեսնենք, թե ինչպես է առաջին հերթին առաջանում ստատիկ կոդերի անալիզատորի ներդրման խնդիրը, ինչպես հաղթահարել այս խնդիրը և ինչպես աստիճանաբար անվնաս վերացնել տեխնիկական պարտքը։
Հարցեր
Սովորաբար դժվար չէ գործարկել և տեսնել, թե ինչպես է աշխատում ստատիկ անալիզատորը []. Դուք կարող եք տեսնել հետաքրքիր սխալներ կամ նույնիսկ սարսափելի պոտենցիալ խոցելիություններ կոդի մեջ: Դուք նույնիսկ կարող եք ինչ-որ բան ուղղել, բայց հետո շատ ծրագրավորողներ հրաժարվում են:
Բոլոր ստատիկ անալիզատորներն արտադրում են կեղծ դրական արդյունքներ: Սա ստատիկ կոդի վերլուծության մեթոդոլոգիայի առանձնահատկությունն է, և դրա դեմ ոչինչ անել հնարավոր չէ: Ընդհանուր դեպքում սա անլուծելի խնդիր է, ինչպես հաստատվում է Ռայսի թեորեմով []. Մեքենայական ուսուցման ալգորիթմները նույնպես չեն օգնի []. Նույնիսկ եթե մարդը չի կարող միշտ ասել, թե արդյոք այս կամ այն ծածկագիրը սխալ է, ապա դա չպետք է սպասել ծրագրից :):
Կեղծ պոզիտիվները խնդիր չեն, եթե ստատիկ անալիզատորն արդեն կազմաձևված է.
- Անջատված կանոնների անհամապատասխան հավաքածուներ;
- Որոշ անհամապատասխան ախտորոշիչներ անջատված են.
- Եթե մենք խոսում ենք C կամ C++-ի մասին, ապա նշվում են մակրոներ, որոնք պարունակում են հատուկ կոնստրուկտներ, որոնք առաջացնում են անօգուտ նախազգուշացումներ ամեն տեղ, որտեղ օգտագործվում են նման մակրոներ.
- Նշվում են սեփական գործառույթները, որոնք կատարում են համակարգի գործառույթների նման գործողություններ (իր սեփական անալոգը անխնա կամ printf) [];
- Կեղծ պոզիտիվները հատուկ անջատված են մեկնաբանությունների միջոցով.
- Եվ այսպես շարունակ:
Այս դեպքում մենք կարող ենք ակնկալել ցածր կեղծ դրական ցուցանիշ՝ մոտ 10-15% []. Այլ կերպ ասած, անալիզատորի 9 նախազգուշացումներից 10-ը ցույց կտա կոդի իրական խնդիր կամ առնվազն «ուժեղ հոտով ծածկագիր»: Համաձայն եմ, այս սցենարը չափազանց հաճելի է, իսկ անալիզատորը ծրագրավորողի իսկական ընկերն է։
Իրականում մեծ նախագծում նախնական պատկերը լրիվ այլ կլինի։ Անալիզատորը թողարկում է հարյուրավոր կամ հազարավոր նախազգուշացումներ ժառանգական կոդի համար: Անհնար է արագ հասկանալ, թե այս նախազգուշացումներից որոնք են տեղին, որոնք՝ ոչ: Իռացիոնալ է նստել և սկսել զբաղվել այս բոլոր նախազգուշացումներով, քանի որ այս դեպքում հիմնական աշխատանքը կանգ է առնելու օրերով կամ շաբաթներով։ Որպես կանոն, թիմը չի կարող իրեն թույլ տալ նման սցենար: Կլինեն նաև մեծ թվով տարբերություններ, որոնք կփչացնեն փոփոխությունների պատմությունը: Իսկ կոդի մեջ այդքան շատ բեկորների արագ զանգվածային խմբագրումը անխուսափելիորեն կհանգեցնի նոր տառասխալների և սխալների:
Եվ ամենակարեւորը, զգուշացումների դեմ պայքարում նման սխրանքը քիչ իմաստ ունի: Համաձայնեք, որ քանի որ նախագիծը հաջողությամբ աշխատում է երկար տարիներ, դրանում առկա կրիտիկական սխալների մեծ մասն արդեն ուղղվել է: Այո, այս ուղղումները շատ թանկ էին, պետք է վրիպազերծվեին, ստացան օգտատերերի բացասական արձագանքներ սխալների մասին և այլն: Ստատիկ անալիզատորը կօգնի արագ և էժան շտկել այս սխալներից շատերը կոդավորման փուլում: Բայց այս պահին, այսպես թե այնպես, այս սխալները շտկվել են, և անալիզատորը հիմնականում հայտնաբերում է հին կոդի ոչ կրիտիկական սխալները։ Այս կոդը կարող է չօգտագործվել, այն կարող է օգտագործվել շատ հազվադեպ, և դրա սխալը չի կարող հանգեցնել նկատելի հետևանքների: Միգուցե ինչ-որ տեղ կոճակի ստվերը սխալ գույն ունի, բայց դա չի խանգարում որևէ մեկի կողմից արտադրանքի օգտագործմանը:
Իհարկե, նույնիսկ աննշան սխալները դեռ սխալներ են: Եվ երբեմն սխալը կարող է թաքցնել իրական խոցելիությունը: Այնուամենայնիվ, ամեն ինչից հրաժարվելը և օրեր/շաբաթներ ծախսելը արատների դեմ, որոնք հազիվ են դրսևորվում, կասկածելի գաղափար է թվում:
Ծրագրավորողները նայում են, նայում, նայում են այս բոլոր նախազգուշացումներին հին աշխատանքային օրենսգրքի մասին... Եվ նրանք մտածում են՝ մենք կարող ենք անել առանց ստատիկ վերլուծության: Եկեք գնանք գրենք մի քանի նոր օգտակար գործառույթ:
Իրենց ձևով նրանք իրավացի են։ Նրանք կարծում են, որ նախ պետք է ինչ-որ կերպ ազատվեն այս բոլոր նախազգուշացումներից: Միայն այդ դեպքում նրանք կկարողանան օգտվել կոդերի անալիզատորի կանոնավոր օգտագործումից: Հակառակ դեպքում նոր նախազգուշացումները պարզապես կխեղդվեն հների մեջ, և ոչ ոք ուշադրություն չի դարձնի դրանց:
Սա նույն անալոգիան է, ինչ կոմպիլյատորների նախազգուշացումների դեպքում: Առանց պատճառի չէ, որ խորհուրդ են տալիս կոմպիլյատորների զգուշացումների թիվը պահել 0-ի վրա: Եթե կա 1000 զգուշացում, ապա երբ կա 1001, ոչ ոք դրան ուշադրություն չի դարձնի, և պարզ չէ, թե որտեղ փնտրել այս նորագույն զգուշացումը:
Այս պատմության մեջ ամենավատ բանն այն է, որ այս պահին վերևից ինչ-որ մեկը ձեզ ստիպում է օգտագործել ստատիկ կոդի վերլուծություն։ Սա միայն կմոտիվացնի թիմին, քանի որ նրանց տեսանկյունից լրացուցիչ բյուրոկրատական բարդություն կլինի, որը միայն խանգարում է: Ոչ ոք չի դիտի անալիզատորի հաշվետվությունները, և ամբողջ օգտագործումը կլինի միայն «թղթի վրա»: Նրանք. Ֆորմալ կերպով, վերլուծությունը ներկառուցված է DevOps գործընթացում, բայց գործնականում դա ոչ մեկին օգուտ չի տալիս: Մենք մանրամասն պատմություններ լսեցինք տաղավարներում համաժողովի մասնակիցներից: Նման փորձը կարող է խրախուսել ծրագրավորողներին երկար ժամանակ, եթե ոչ ընդմիշտ օգտագործել ստատիկ վերլուծության գործիքները:
Տեխնիկական պարտքի իրականացում և վերացում
Իրականում, նույնիսկ մեծ հին նախագծի մեջ ստատիկ վերլուծություն ներդնելու մեջ դժվար կամ սարսափելի բան չկա:
CI / CD
Ավելին, անալիզատորը կարող է անմիջապես դառնալ շարունակական զարգացման գործընթացի մաս: Օրինակ, PVS-Studio բաշխումը պարունակում է կոմունալ ծրագրեր՝ հաշվետվությունը ձեզ անհրաժեշտ ձևաչափով հարմար դիտելու համար, և ծանուցումներ մշակողներին, ովքեր գրել են կոդի խնդրահարույց բաժինները: Նրանց համար, ովքեր ավելի շատ հետաքրքրված են CI/CD համակարգերից PVS-Studio-ի գործարկումով, խորհուրդ եմ տալիս ծանոթանալ համապատասխան փաստաթղթեր և մի շարք հոդվածներ.
Բայց եկեք վերադառնանք մեծ թվով կեղծ պոզիտիվների խնդրին կոդերի վերլուծության գործիքների ներդրման առաջին փուլերում:
Գոյություն ունեցող տեխնիկական պարտքի շտկում և նոր նախազգուշացումների լուծում
Ժամանակակից առևտրային ստատիկ անալիզատորները թույլ են տալիս ուսումնասիրել միայն նոր նախազգուշացումները, որոնք հայտնվում են նոր կամ փոփոխված կոդում: Այս մեխանիզմի իրականացումը տարբեր է, բայց էությունը նույնն է. PVS-Studio ստատիկ անալիզատորում այս գործառույթն իրականացվում է հետևյալ կերպ.
Ստատիկ վերլուծության օգտագործումը արագ սկսելու համար մենք առաջարկում ենք PVS-Studio-ի օգտատերերին օգտագործել զգուշացումների զանգվածային ճնշման մեխանիզմը []. Ընդհանուր գաղափարը հետևյալն է. Օգտագործողը գործարկել է անալիզատորը և ստացել բազմաթիվ նախազգուշացումներ: Քանի որ երկար տարիներ մշակվող նախագիծը կենդանի է, զարգանում և գումար է վաստակում, ապա, ամենայն հավանականությամբ, զեկույցում շատ նախազգուշացումներ չեն լինի, որոնք նշում են կարևոր թերությունները: Այլ կերպ ասած, կրիտիկական սխալներն այս կամ այն կերպ արդեն շտկվել են՝ օգտագործելով ավելի թանկ մեթոդներ կամ հաճախորդների արձագանքների շնորհիվ: Համապատասխանաբար, այն ամենը, ինչ ներկայումս գտնում է անալիզատորը, կարելի է համարել տեխնիկական պարտք, որն անհապաղ վերացնել փորձելն անիրագործելի է։
Դուք կարող եք PVS-Studio-ին ասել, որ այս նախազգուշացումներն առայժմ անտեղի համարեն (պահեք տեխնիկական պարտքը ավելի ուշ), և այն այլևս չի ցուցադրի դրանք: Անալիզատորը ստեղծում է հատուկ ֆայլ, որտեղ պահպանում է տեղեկատվությունը սխալների մասին, որոնք դեռ հետաքրքիր չեն: Իսկ այժմ PVS-Studio-ն նախազգուշացումներ կկատարի միայն նոր կամ փոփոխված կոդի համար։ Ընդ որում, այս ամենն իրականացվում է խելացիորեն։ Եթե, օրինակ, ելակետային կոդի ֆայլի սկզբում ավելացվի դատարկ տող, ապա անալիզատորը հասկանում է, որ իրականում ոչինչ չի փոխվել, և կշարունակի լռել։ Նշման այս ֆայլը կարող է տեղադրվել տարբերակի կառավարման համակարգում: Ֆայլը մեծ է, բայց դա խնդիր չէ, քանի որ իմաստ չունի այն հաճախ պահել:
Այժմ բոլոր ծրագրավորողները կտեսնեն նախազգուշացումներ՝ կապված միայն նոր կամ փոփոխված կոդի հետ։ Այսպիսով, դուք կարող եք սկսել օգտագործել անալիզատորը, ինչպես ասում են, հաջորդ օրվանից։ Եվ դուք կարող եք ավելի ուշ վերադառնալ տեխնիկական պարտքին, և աստիճանաբար շտկել սխալները և կարգավորել անալիզատորը:
Այսպիսով, լուծվել է մեծ հին նախագծում անալիզատորի ներդրման առաջին խնդիրը: Հիմա եկեք պարզենք, թե ինչ անել տեխնիկական պարտքի հետ:
Սխալների շտկում և վերամշակում
Ամենապարզ և բնական բանը որոշ ժամանակ հատկացնելն է վերլուծելու զանգվածաբար ճնշված անալիզատորի նախազգուշացումները և աստիճանաբար դրանք լուծելու համար: Ինչ-որ տեղ դուք պետք է ուղղեք կոդի սխալները, ինչ-որ տեղ պետք է վերամշակեք, որպեսզի անալիզատորին ասեք, որ կոդը խնդրահարույց չէ: Պարզ օրինակ.
if (a = b)C++ կոմպիլյատորների և անալիզատորների մեծ մասը դժգոհում է նման կոդից, քանի որ մեծ է հավանականությունը, որ նրանք իսկապես ցանկացել են գրել (ա == բ). Բայց կա չասված պայմանավորվածություն, և դա սովորաբար նշվում է փաստաթղթում, որ եթե լրացուցիչ փակագծեր կան, ապա համարվում է, որ ծրագրավորողը միտումնավոր է գրել այդպիսի կոդ, և հայհոյելու կարիք չկա։ Օրինակ, PVS-Studio-ի ախտորոշման փաստաթղթերում հստակ գրված է, որ հետևյալ տողը կհամարվի ճիշտ և անվտանգ.
if ((a = b))Մեկ այլ օրինակ. Այս C++ կոդում մոռացվա՞ծ է: կոտրել կամ ոչ?
case A:
foo();
case B:
bar();
break;PVS-Studio-ի անալիզատորն այստեղ նախազգուշացում կտա . Սա կարող է սխալ չլինել, որի դեպքում պետք է վերլուծողին հուշում տալ՝ ավելացնելով հատկանիշը կամ օրինակ __հատկանիշ__((անկում)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Կարելի է ասել, որ կոդի նման փոփոխությունները չեն շտկում սխալը։ Այո, դա ճիշտ է, բայց դա երկու օգտակար բան է անում. Նախ, անալիզատորի հաշվետվությունը ազատվում է կեղծ դրական արդյունքներից: Երկրորդ՝ օրենսգիրքն ավելի հասկանալի է դառնում դրա սպասարկման մեջ ներգրավված մարդկանց համար։ Եվ սա շատ կարևոր է: Միայն դրա համար արժե իրականացնել աննշան վերամշակումներ՝ ծածկագիրը ավելի պարզ և հեշտ պահպանելու համար: Քանի որ անալիզատորը չի հասկանում՝ անհրաժեշտ է «կոտրում», թե ոչ, դա անհասկանալի կլինի նաև գործընկեր ծրագրավորողների համար:
Ի լրումն սխալների շտկման և վերամշակման, դուք կարող եք հատուկ ճնշել անալիզատորի ակնհայտ կեղծ նախազգուշացումները: Որոշ անհամապատասխան ախտորոշումներ կարող են անջատվել: Օրինակ, ինչ-որ մեկը կարծում է, որ զգուշացումներն անիմաստ են լողացող/կրկնակի արժեքների համեմատության մասին: Եվ ոմանք դրանք դասակարգում են որպես կարևոր և ուսումնասիրության արժանի []. Որ նախազգուշացումներն են համարվում տեղին, իսկ որոնք՝ ոչ, դա պետք է որոշի մշակող թիմը:
Կեղծ ահազանգերը ճնշելու այլ եղանակներ կան: Օրինակ, ավելի վաղ նշվել էր մակրո նշումը: Այս ամենն ավելի մանրամասն նկարագրված է փաստաթղթերում: Ամենակարևորը հասկանալն է, որ եթե աստիճանաբար և համակարգված մոտենում ես կեղծ պոզիտիվների հետ աշխատելուն, ապա դրանցում ոչ մի վատ բան չկա։ Անհետաքրքիր նախազգուշացումների ճնշող մեծամասնությունը անհետանում է կազմաձևումից հետո, և մնում են միայն այն վայրերը, որոնք իսկապես պահանջում են մանրակրկիտ ուսումնասիրություն և կոդի որոշ փոփոխություններ:
Բացի այդ, մենք միշտ օգնում ենք մեր հաճախորդներին ստեղծել PVS-Studio, եթե որևէ դժվարություն առաջանա: Ավելին, եղել են դեպքեր, երբ մենք ինքներս վերացրել ենք կեղծ նախազգուշացումները և ուղղել սխալները []. Ամեն դեպքում, որոշեցի նշել, որ ընդլայնված համագործակցության այս տարբերակը նույնպես հնարավոր է :)։
Գլխավոր մեթոդ
Կա ևս մեկ հետաքրքիր մոտեցում՝ աստիճանաբար բարելավել կոդի որակը՝ վերացնելով ստատիկ անալիզատորի նախազգուշացումը: Եզրակացությունն այն է, որ նախազգուշացումների թիվը կարող է միայն նվազել:
Գրանցվում է ստատիկ անալիզատորի կողմից տրված նախազգուշացումների քանակը: Որակի դարպասը կազմաձևված է այնպես, որ այժմ կարող եք մուտքագրել միայն մի ծածկագիր, որը չի ավելացնում գործողությունների քանակը: Արդյունքում ահազանգերի քանակի աստիճանական կրճատման գործընթացը սկսվում է անալիզատորի կարգավորմամբ և սխալները շտկելով։
Նույնիսկ եթե մարդը ցանկանում է մի փոքր խաբել և որոշել է անցնել որակի դարպասը ոչ թե իր նոր կոդում զգուշացումները վերացնելով, այլ երրորդ կողմի հին ծածկագիրը բարելավելով, դա սարսափելի չէ: Միևնույն է, կապանքը պտտվում է մեկ ուղղությամբ, և աստիճանաբար թերությունների թիվը կնվազի։ Նույնիսկ եթե մարդը չի ցանկանում շտկել իր սեփական նոր թերությունները, նա դեռ պետք է ինչ-որ բան բարելավի հարեւան օրենսգրքում: Ինչ-որ պահի ավարտվում են զգուշացումների քանակը նվազեցնելու հեշտ ուղիները, և գալիս է մի պահ, երբ իրական սխալները կշտկվեն:
Այս մեթոդաբանությունը ավելի մանրամասն նկարագրված է Իվան Պոնոմարևի շատ հետաքրքիր հոդվածում »:«, որը խորհուրդ եմ տալիս կարդալ բոլորին, ովքեր հետաքրքրված են կոդի որակի բարելավմամբ։
Հոդվածի հեղինակն այս թեմայով նաև զեկույց ունի.".
Ամփոփում
Հուսով եմ, որ այս հոդվածից հետո ընթերցողները ավելի կընդունեն ստատիկ վերլուծության գործիքները և կցանկանան դրանք ներդնել զարգացման գործընթացում: Եթե ունեք հարցեր, մենք միշտ պատրաստ ենք մեր ստատիկ անալիզատոր PVS-Studio-ի օգտվողները և օգնում են դրա իրականացմանը:
Կան այլ բնորոշ կասկածներ, թե արդյոք ստատիկ վերլուծությունը կարող է իսկապես հարմար և օգտակար լինել: Ես փորձեցի փարատել այս կասկածների մեծ մասը «PVS-Studio ստատիկ կոդերի անալիզատորը մշակման գործընթացում ներմուծելու պատճառները» հրապարակման մեջ [].
Շնորհակալություն ուշադրության համար և եկեք և փորձեք PVS-Studio անալիզատորը:
Լրացուցիչ հղումներ
- Անդրեյ Կարպով.
- Վիքիպեդիա: .
- Անդրեյ Կարպով, Վիկտորյա Խանիևա. .
- PVS-Studio. Փաստաթղթեր. .
- Անդրեյ Կարպով. .
- PVS-Studio. Փաստաթղթեր. .
- Իվան Անդրյաշին. .
- Պավել Էրեմեև, Սվյատոսլավ Ռազմիսլով. .
- Անդրեյ Կարպով. .
Եթե ցանկանում եք կիսվել այս հոդվածով անգլիախոս լսարանի հետ, խնդրում ենք օգտագործել թարգմանության հղումը՝ Անդրեյ Կարպով: .
Source: www.habr.com