Հոգնել եք կոդի անվերջ վերանայումից կամ վրիպազերծումից, երբեմն մտածում եք, թե ինչպես պարզեցնել ձեր կյանքը: Եվ մի փոքր փնտրելուց կամ պատահաբար վրան ընկնելուց հետո կարող եք տեսնել «Ստատիկ վերլուծություն» կախարդական արտահայտությունը։ Եկեք տեսնենք, թե ինչ է դա և ինչպես կարող է այն փոխազդել ձեր նախագծի հետ:
Իրականում, եթե դուք գրում եք ցանկացած ժամանակակից լեզվով, ապա, նույնիսկ չգիտակցելով դա, այն անցկացնում եք ստատիկ անալիզատորի միջոցով: Փաստն այն է, որ ցանկացած ժամանակակից կոմպիլյատոր տրամադրում է, թեև փոքր, նախազգուշացումների հավաքածու կոդի մեջ հնարավոր խնդիրների մասին: Օրինակ, Visual Studio-ում C++ կոդը կազմելիս կարող եք տեսնել հետևյալը.
Այս ելքում մենք տեսնում ենք, որ փոփոխականը էր երբեք չի օգտագործվել ֆունկցիայի որևէ տեղ: Այսպիսով, իրականում դուք գրեթե միշտ օգտագործել եք պարզ ստատիկ կոդերի անալիզատոր: Այնուամենայնիվ, ի տարբերություն պրոֆեսիոնալ անալիզատորների, ինչպիսիք են 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-ն տալիս է հետևյալ նախազգուշացումը.
Մտածեք վերանայելու «y» կետի օգտագործման ճիշտությունը:
Եթե ցանկանում եք ձեր ձեռքերը խոթել այս սխալի մեջ, փորձեք պատրաստի օրինակ Compiler Explorer-ում.*.
Եվ ինչպես հասկանում եք, միշտ չէ, որ հնարավոր է անմիջապես ուշադրություն դարձնել կոդի նման բաժիններին, և դրա պատճառով դուք կարող եք մի լավ ժամ նստել վրիպազերծման վայրում՝ մտածելով, թե ինչու է ամեն ինչ այդքան տարօրինակ աշխատում:
Այնուամենայնիվ, սա ակնհայտորեն սխալ է: Իսկ եթե մշակողը գրել է ոչ օպտիմալ կոդ, քանի որ մոռացել է լեզվի որոշ նրբությունները: Կամ նույնիսկ թույլ է տվել դա կոդում ? Ցավոք, նման դեպքերը բոլորովին սովորական են, և ժամանակի առյուծի բաժինը ծախսվում է հատուկ աշխատանքային կոդի վրիպազերծման վրա, որը պարունակում է տառասխալներ, բնորոշ սխալներ կամ չսահմանված վարքագիծ:
Հենց այս իրավիճակների համար էլ ի հայտ եկավ ստատիկ վերլուծությունը։ Սա ծրագրավորողի օգնական է, ով կմատնանշի տարբեր խնդիրներ կոդում և կբացատրի փաստաթղթերում, թե ինչու պետք չէ գրել այսպես, ինչի կարող է հանգեցնել և ինչպես շտկել այն: Ահա մի օրինակ, թե ինչ կարող է նման լինել.*.
Դուք կարող եք գտնել ավելի հետաքրքիր սխալներ, որոնք անալիզատորը կարող է հայտնաբերել հոդվածներում.
Այժմ, երբ դուք կարդացել եք այս նյութը և համոզվել եք ստատիկ վերլուծության առավելությունների մեջ, գուցե ցանկանաք փորձել այն: Բայց որտեղի՞ց սկսել: Ինչպե՞ս ինտեգրել նոր գործիք ձեր ընթացիկ նախագծին: Իսկ ինչպե՞ս ներկայացնել թիմին նրան։ Այս հարցերի պատասխանները կգտնեք ստորև:
Նշում. Ստատիկ վերլուծությունը չի փոխարինում կամ չեղարկում այնպիսի օգտակար բան, ինչպիսին է կոդերի վերանայումները: Այն լրացնում է այս գործընթացը՝ օգնելով նախապես նկատել և ուղղել տառասխալները, անճշտությունները և վտանգավոր ձևավորումները: Շատ ավելի արդյունավետ է կենտրոնանալ կոդերի վերանայումների վրա ալգորիթմների և կոդի հստակության վրա, այլ ոչ թե անտեղի փակագծեր փնտրելը կամ .
0. Ծանոթանալ գործիքին
Ամեն ինչ սկսվում է փորձնական տարբերակից: Իրոք, դժվար է որոշել ինչ-որ բան ներմուծել զարգացման գործընթացում, եթե նախկինում երբեք չեք տեսել գործիքը ուղիղ եթերում: Հետևաբար, առաջին բանը, որ դուք պետք է անեք, ներբեռնումն է .
Այն, ինչ դուք կսովորեք այս փուլում.
- Որո՞նք են անալիզատորի հետ փոխազդելու ուղիները.
- Արդյո՞ք անալիզատորը համատեղելի է ձեր զարգացման միջավայրի հետ:
- Ի՞նչ խնդիրներ կան ներկայումս ձեր նախագծերում:
Ձեզ անհրաժեշտ ամեն ինչ տեղադրելուց հետո առաջին բանը, որ դուք պետք է անեք, ամբողջ նախագծի վերլուծությունն է (, , ) Visual Studio-ում PVS-Studio-ի դեպքում դուք կտեսնեք նմանատիպ նկար (սեղմեք).
Փաստն այն է, որ ստատիկ անալիզատորները սովորաբար մեծ թվով նախազգուշացումներ են տալիս մեծ կոդի բազա ունեցող նախագծերի համար: Բոլորը շտկելու կարիք չկա, քանի որ ձեր նախագիծն արդեն աշխատում է, ինչը նշանակում է, որ այս խնդիրները կարևոր չեն: Այնուամենայնիվ, դուք և անհրաժեշտության դեպքում ուղղել դրանք: Դա անելու համար հարկավոր է զտել ելքը և թողնել միայն ամենահուսալի հաղորդագրությունները: Visual Studio-ի PVS-Studio հավելվածում դա արվում է զտելով ըստ սխալի մակարդակների և կատեգորիաների: Առավել ճշգրիտ արդյունքի համար թողեք միայն Բարձր и ընդհանուր (նաև սեղմելի):
Իսկապես, 178 նախազգուշացումները շատ ավելի հեշտ են դիտել, քան մի քանի հազար...
Ներդիրներում Միջին и Ցածր Հաճախ կան լավ նախազգուշացումներ, բայց այս կատեգորիաները ներառում են այն ախտորոշիչները, որոնք ունեն ավելի քիչ ճշգրտություն (հուսալիություն): Լրացուցիչ տեղեկություններ նախազգուշացման մակարդակների և Windows-ի տակ աշխատելու տարբերակների մասին կարող եք գտնել այստեղ՝ **.
Արժե ամենահետաքրքիր սխալները հաջողությամբ վերանայել (և հաջողությամբ ուղղել դրանք): . Դա անհրաժեշտ է, որպեսզի նոր զգուշացումները չկորչեն հների մեջ։ Բացի այդ, ստատիկ անալիզատորը ծրագրավորողի օգնականն է, և ոչ թե սխալների ցանկը: 🙂
1. Ավտոմատացում
Ծանոթանալուց հետո ժամանակն է կարգավորել փլագինները և ինտեգրվել CI-ին։ Դա պետք է արվի նախքան ծրագրավորողները կսկսեն օգտագործել ստատիկ անալիզատորը: Փաստն այն է, որ ծրագրավորողը կարող է մոռանալ միացնել վերլուծությունը կամ ընդհանրապես չցանկանալ դա անել: Դա անելու համար դուք պետք է ամեն ինչի վերջնական ստուգում կատարեք, որպեսզի չստուգված կոդը չկարողանա մտնել ընդհանուր զարգացման ճյուղ:
Ինչ դուք կսովորեք այս փուլում.
- Ինչ ավտոմատացման տարբերակներ է ապահովում գործիքը.
- Արդյո՞ք անալիզատորը համատեղելի է ձեր հավաքման համակարգի հետ:
Քանի որ կատարյալ փաստաթղթեր գոյություն չունեն, երբեմն պետք է գրել . Սա նորմալ է, և մենք ուրախ ենք օգնել ձեզ: 🙂
Այժմ եկեք անցնենք շարունակական ինտեգրման (CI) ծառայություններին: Ցանկացած անալիզատոր կարող է ներդրվել դրանց մեջ առանց լուրջ խնդիրների: Դա անելու համար հարկավոր է խողովակաշարում ստեղծել առանձին փուլ, որը սովորաբար գտնվում է կառուցման և միավորի փորձարկումներից հետո: Դա արվում է տարբեր կոնսոլային կոմունալ ծառայությունների միջոցով: Օրինակ, PVS-Studio-ն տրամադրում է հետևյալ կոմունալ ծառայությունները.
- (լուծումների վերլուծություն, C#, C++ նախագծեր Windows-ում)
- (կազմման մոնիտորինգ)
- (C++ նախագծերի վերլուծություն Linux/macOS-ում)
- (լուծումների վերլուծություն, C# նախագծեր Linux / macOS-ում)
- (Java նախագծերի վերլուծություն)
- (զեկուցել ֆայլի փոխարկիչ)
Վերլուծությունը CI-ում ինտեգրելու համար դուք պետք է կատարեք երեք բան.
- Տեղադրեք անալիզատորը;
- Գործարկման վերլուծություն;
- Արդյունքների մատուցում:
Օրինակ, PVS-Studio-ն Linux-ում (Debian-base) տեղադրելու համար անհրաժեշտ է գործարկել հետևյալ հրամանները.
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-studioWindows-ով աշխատող համակարգերում անալիզատորը փաթեթի կառավարիչից տեղադրելու միջոց չկա, բայց անալիզատորը հնարավոր է տեղակայել հրամանի տողից.
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-ի վրա վերլուծություն տեղադրելու մասին հոդվածում ««(Windows) կամ»«(Linux):
Լավ, դուք կարգավորել եք անալիզատորը կառուցման սերվերի վրա: Այժմ, եթե ինչ-որ մեկը վերբեռնել է չստուգված կոդը, ստուգման փուլը չի հաջողվի, և դուք կկարողանաք հայտնաբերել խնդիրը, սակայն դա այնքան էլ հարմար չէ, քանի որ ավելի արդյունավետ է նախագիծը ստուգել ոչ թե մասնաճյուղերի միաձուլումից հետո, այլ դրանից առաջ՝ ձգման պահանջի փուլում։
Ընդհանրապես, ձգման հարցումների վերլուծության ստեղծումը շատ չի տարբերվում 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Դուք կարող եք ավելին իմանալ ձգման հարցումների վերլուծության մասին **. Նույնիսկ եթե ձեր CI-ն չկա հոդվածում նշված ծառայությունների ցանկում, ձեզ օգտակար կլինի այս տեսակի վերլուծության տեսությանը նվիրված ընդհանուր բաժինը:
Կարգավորելով ձգման հարցումների վերլուծություն՝ դուք կարող եք արգելափակել նախազգուշացումներ պարունակող պարտավորությունները՝ դրանով իսկ ստեղծելով սահման, որը չի կարող անցնել չստուգված կոդը:
Այս ամենը, իհարկե, լավ է, բայց ես կցանկանայի, որ բոլոր նախազգուշացումները կարողանայի տեսնել մեկ տեղում: Ոչ միայն ստատիկ անալիզատորից, այլ նաև միավորային թեստերից կամ դինամիկ անալիզատորից: Դրա համար կան տարբեր ծառայություններ և պլագիններ: PVS-Studio-ն, օրինակ, ունի .
2. Ինտեգրում մշակող մեքենաների վրա
Այժմ ժամանակն է տեղադրել և կարգավորել անալիզատորը ամենօրյա զարգացման համար: Այս պահին դուք արդեն ծանոթացել եք աշխատանքի եղանակների մեծ մասին, ուստի սա կարելի է անվանել ամենահեշտ մասը:
Որպես ամենապարզ տարբերակ, մշակողները կարող են ինքնուրույն տեղադրել անհրաժեշտ անալիզատորը: Այնուամենայնիվ, դա շատ ժամանակ կխլի և նրանց ուշադրությունը կշեղի զարգացումից, այնպես որ կարող եք ավտոմատացնել այս գործընթացը՝ օգտագործելով տեղադրիչն ու անհրաժեշտ դրոշները: PVS-Studio-ի համար կան տարբեր . Այնուամենայնիվ, միշտ կան փաթեթների կառավարիչներ, օրինակ՝ Chocolatey (Windows), Homebrew (macOS) կամ տասնյակ տարբերակներ Linux-ի համար։
Այնուհետև ձեզ հարկավոր է տեղադրել անհրաժեշտ պլագինները, օրինակ՝ համար , , եւ այլն:
3. Ամենօրյա օգտագործում
Այս փուլում ժամանակն է մի քանի խոսք ասել ամենօրյա օգտագործման ընթացքում անալիզատորն արագացնելու եղանակների մասին: Ամբողջ նախագծի ամբողջական վերլուծությունը շատ ժամանակ է պահանջում, բայց որքա՞ն հաճախ ենք մենք միանգամից փոխում կոդը ողջ նախագծի ընթացքում: Դժվար թե լինի այնքան մեծ վերամշակում, որ անմիջապես կազդի կոդի ամբողջ բազայի վրա: Միանգամից փոփոխվող ֆայլերի թիվը հազվադեպ է գերազանցում մեկ տասնյակը, ուստի իմաստ ունի վերլուծել դրանք: Նման իրավիճակի համար կա . Պարզապես մի անհանգստացեք, սա ևս մեկ գործիք չէ: Սա հատուկ ռեժիմ է, որը թույլ է տալիս վերլուծել միայն փոփոխված ֆայլերը և դրանց կախվածությունը, և դա տեղի է ունենում ավտոմատ կերպով կառուցելուց հետո, եթե դուք աշխատում եք IDE-ում՝ տեղադրված plugin-ով:
Եթե անալիզատորը խնդիրներ հայտնաբերի վերջերս փոխված կոդի մեջ, նա ինքնուրույն կհաղորդի այդ մասին: Օրինակ, PVS-Studio-ն ձեզ կասի այս մասին՝ օգտագործելով ահազանգ.
Իհարկե, ծրագրավորողներին ասելը, որ օգտագործեն գործիքը, բավարար չէ: Մենք պետք է ինչ-որ կերպ նրանց ասենք, թե դա ինչ է և ինչպես է դա: Ահա, օրինակ, PVS-Studio-ի արագ մեկնարկի մասին հոդվածներ, բայց դուք կարող եք գտնել նմանատիպ ձեռնարկներ ձեր նախընտրած ցանկացած գործիքի համար.
Նման հոդվածները տրամադրում են ամենօրյա օգտագործման համար անհրաժեշտ ողջ տեղեկատվությունը և շատ ժամանակ չեն խլում։ 🙂
Նույնիսկ գործիքին ծանոթանալու փուլում մենք ճնշեցինք բազմաթիվ նախազգուշացումներ առաջին գործարկումներից մեկի ժամանակ: Ցավոք, ստատիկ անալիզատորները կատարյալ չեն, ուստի ժամանակ առ ժամանակ նրանք կեղծ պոզիտիվներ են տալիս: Սովորաբար դրանք ճնշելը հեշտ է, օրինակ՝ Visual Studio-ի PVS-Studio հավելվածում պարզապես անհրաժեշտ է սեղմել մեկ կոճակ.
Այնուամենայնիվ, դուք կարող եք ավելին անել, քան պարզապես ճնշել դրանք: Օրինակ, դուք կարող եք հայտնել խնդրի մասին աջակցության համար: Եթե կեղծ դրականը հնարավոր է շտկել, ապա ապագա թարմացումներում դուք կարող եք նկատել, որ ամեն անգամ ավելի ու ավելի քիչ են լինում ձեր կոդերի բազայի համար հատուկ կեղծ պոզիտիվներ:
ինտեգրումից հետո
Այսպիսով, մենք անցել ենք ստատիկ վերլուծության ինտեգրման բոլոր փուլերը զարգացման գործընթացում: Չնայած CI-ում նման գործիքների տեղադրման կարևորությանը, դրանք գործարկելու ամենակարևոր տեղը ծրագրավորողի համակարգիչն է: Ի վերջո, ստատիկ անալիզատորը դատավոր չէ, ով ձեզանից հեռու ինչ-որ տեղ ասում է, որ կոդը լավ չէ: Ընդհակառակը, դա օգնական է, որը ձեզ ասում է, թե արդյոք հոգնե՞լ եք, և հիշեցնում է, թե արդյոք ինչ-որ բան մոռացել եք։
Ճիշտ է, առանց կանոնավոր օգտագործման, ստատիկ վերլուծությունը դժվար թե զգալիորեն պարզեցնի զարգացումը: Ի վերջո, ծրագրավորողի համար դրա հիմնական առավելությունը ոչ այնքան կոդի բարդ և վիճելի հատվածների որոնումն է, որքան դրանց վաղ հայտնաբերումը: Համաձայնեք, որ խմբագրումները փորձարկման ուղարկելուց հետո խնդրի հայտնաբերումը ոչ միայն տհաճ է, այլև շատ ժամանակատար։ Ստատիկ վերլուծությունը, երբ պարբերաբար օգտագործվում է, դիտում է յուրաքանչյուր փոփոխություն անմիջապես ձեր համակարգչում և հաղորդում է կասկածելի վայրեր կոդի վրա աշխատելիս:
Եվ եթե դուք կամ ձեր գործընկերները դեռ համոզված չեք, թե արժե արդյոք անալիզատորն իրականացնել, ապա ես առաջարկում եմ ձեզ հիմա սկսել հոդվածը կարդալ»:Այն անդրադառնում է մշակողների բնորոշ մտահոգություններին, որ ստատիկ վերլուծությունը կխլի նրանց ժամանակը և այլն:
Եթե ցանկանում եք կիսվել այս հոդվածով անգլիախոս լսարանի հետ, խնդրում ենք օգտագործել թարգմանության հղումը՝ Մաքսիմ Զվյագինցև։ .
Source: www.habr.com