Այս հոդվածը գրելու համար ինձ ոգեշնչեցին ստատիկ վերլուծության վերաբերյալ բազմաթիվ նյութեր, որոնք գնալով ավելի են հանդիպում: Նախ, սա , որն ակտիվորեն գովազդում է իրեն Habré-ում՝ բաց կոդով նախագծերում իրենց գործիքի կողմից հայտնաբերված սխալների ակնարկներով: PVS-ստուդիան վերջերս է ներդրվել և, իհարկե, IntelliJ IDEA-ի մշակողները, որոնց ներկառուցված անալիզատորն այսօր, հավանաբար, ամենաառաջադեմն է Java-ի համար, .
Նման ակնարկներ կարդալիս տպավորություն է ստեղծվում, որ խոսքը կախարդական էլիքսիրի մասին է՝ սեղմեք կոճակը, և ահա այն՝ ձեր աչքի առաջ առկա թերությունների ցանկը: Թվում է, թե անալիզատորների բարելավման հետ մեկտեղ ինքնաբերաբար ավելի ու ավելի շատ սխալներ կլինեն, և այդ ռոբոտների կողմից սկանավորված արտադրանքները կդառնան ավելի ու ավելի լավը, առանց մեր կողմից ջանքեր գործադրելու:
Բայց կախարդական էլիքսիրներ չկան։ Ես կցանկանայի խոսել այն մասին, ինչը սովորաբար չի քննարկվում այնպիսի գրառումներում, ինչպիսիք են «այստեղ մեր ռոբոտը կարող է գտնել». ինչ չեն կարող անել անալիզատորները, որն է նրանց իրական դերն ու տեղը ծրագրային ապահովման առաքման գործընթացում և ինչպես դրանք ճիշտ իրականացնել:
Ratchet (աղբյուր. ).
Ինչ Ստատիկ անալիզատորները երբեք չեն կարող անել
Ի՞նչ է գործնական տեսանկյունից աղբյուրի կոդի վերլուծությունը: Մենք սնվում ենք որոշ աղբյուրներում, և կարճ ժամանակում (շատ ավելի կարճ, քան թեստերը) մենք որոշակի տեղեկատվություն ենք ստանում մեր համակարգի մասին: Հիմնական և մաթեմատիկորեն անհաղթահարելի սահմանափակումն այն է, որ այսպիսով մենք կարող ենք ստանալ միայն բավականին նեղ դասի տեղեկատվության:
Ստատիկ վերլուծությամբ չլուծվող խնդրի ամենահայտնի օրինակն է Սա թեորեմ է, որն ապացուցում է, որ անհնար է մշակել ընդհանուր ալգորիթմ, որը կորոշի ծրագրի ելակետային կոդից՝ այն կվերջանա, թե վերջավոր ժամանակում: Այս թեորեմի ընդլայնումն է , որը նշում է, որ հաշվարկելի ֆունկցիաների ցանկացած ոչ տրիվիալ հատկության համար որոշելը, թե արդյոք կամայական ծրագիրը գնահատում է ֆունկցիան նման հատկությամբ, ալգորիթմորեն անլուծելի խնդիր է։ Օրինակ, անհնար է գրել անալիզատոր, որը կարող է ցանկացած աղբյուրի կոդից որոշել, թե արդյոք վերլուծված ծրագիրը մի ալգորիթմի իրականացում է, որը հաշվարկում է, ասենք, ամբողջ թիվը քառակուսի դնելը։
Այսպիսով, ստատիկ անալիզատորների ֆունկցիոնալությունը անհաղթահարելի սահմանափակումներ ունի: Ստատիկ անալիզատորը երբեք չի կարողանա բոլոր դեպքերում որոշել այնպիսի բաներ, ինչպիսիք են, օրինակ, «զրոյական ցուցիչի բացառության» առաջացումը չեղյալ համարվող լեզուներում, կամ բոլոր դեպքերում որոշել «հատկանիշը չի գտնվել» առկա լեզուներում: դինամիկ մուտքագրում. Այն ամենը, ինչ կարող է անել ամենաառաջադեմ ստատիկ անալիզատորը, առանձնացնում է հատուկ դեպքերը, որոնց թիվը, ձեր սկզբնական կոդի հետ կապված բոլոր հնարավոր խնդիրների թվում, առանց չափազանցության, մի կաթիլ է օվկիանոսում:
Ստատիկ վերլուծությունը սխալների որոնում չէ
Եզրակացությունը բխում է վերը նշվածից՝ ստատիկ վերլուծությունը ծրագրի թերությունների թիվը նվազեցնելու միջոց չէ։ Ես կհամարձակվեմ ասել, որ երբ առաջին անգամ դիմեք ձեր նախագծին, այն կոդում կգտնի «զվարճալի» տեղեր, բայց, ամենայն հավանականությամբ, չի գտնի որևէ թերություն, որը կազդի ձեր ծրագրի որակի վրա:
Անալիզատորների կողմից ինքնաբերաբար հայտնաբերված թերությունների օրինակները տպավորիչ են, բայց չպետք է մոռանալ, որ այս օրինակները հայտնաբերվել են խոշոր կոդերի բազաների մեծ հավաքածուի սկանավորմամբ: Նույն սկզբունքով կոտրիչները, ովքեր կարողանում են մի քանի պարզ գաղտնաբառեր փորձել մեծ թվով հաշիվների վրա, ի վերջո գտնում են այն հաշիվները, որոնք ունեն պարզ գաղտնաբառ։
Արդյո՞ք սա նշանակում է, որ ստատիկ վերլուծություն չպետք է կիրառվի: Իհարկե ոչ! Եվ հենց նույն պատճառով, թե ինչու է արժե ստուգել յուրաքանչյուր նոր գաղտնաբառ «պարզ» գաղտնաբառերի կանգառի ցուցակում հայտնվելու համար:
Ստատիկ վերլուծությունը ավելին է, քան սխալներ գտնելը
Փաստորեն, վերլուծությամբ գործնականում լուծվող խնդիրները շատ ավելի լայն են։ Ի վերջո, ընդհանուր առմամբ, ստատիկ վերլուծությունը սկզբնական կոդերի ցանկացած ստուգում է, որն իրականացվում է նախքան դրանց գործարկումը: Ահա մի քանի բան, որ դուք կարող եք անել.
- Կոդավորման ոճի ստուգում բառի ամենալայն իմաստով: Սա ներառում է ինչպես ֆորմատավորումը ստուգելը, այնպես էլ դատարկ/լրացուցիչ փակագծերի օգտագործումը, չափումների շեմերի սահմանումը, օրինակ՝ տողերի քանակը/ցիկլոմատիկ մեթոդի բարդությունը և այլն. այն ամենը, ինչը պոտենցիալ կոդն ավելի ընթեռնելի և պահպանելի է դարձնում: Java-ում այս գործիքը Checkstyle է, Python-ում՝ flake8։ Այս դասի ծրագրերը սովորաբար կոչվում են «linters»:
- Ոչ միայն գործարկվող կոդը կարելի է վերլուծել։ Ռեսուրսային ֆայլերը, ինչպիսիք են JSON, YAML, XML, .properties-ը, կարող են (և պետք է!) ավտոմատ կերպով ստուգվել վավերականության համար: Ավելի լավ չէ՞ պարզել, որ որոշ չզուգակցված մեջբերումների պատճառով JSON կառուցվածքը կոտրվել է Pull Request-ի ավտոմատ վավերացման վաղ փուլում, քան թեստերը կատարելիս կամ Run-ի ժամանակ: Առկա են համապատասխան գործիքներ. օրինակ. , .
- Կոմպիլյացիան (կամ վերլուծությունը դինամիկ ծրագրավորման լեզուների համար) նույնպես ստատիկ վերլուծության տեսակ է։ Որպես կանոն, կոմպիլյատորները կարող են նախազգուշացումներ տալ, որոնք ցույց են տալիս սկզբնական կոդի որակի հետ կապված խնդիրներ, և դրանք չպետք է անտեսվեն:
- Երբեմն կոմպիլյացիան միայն գործարկվող կոդ կազմելը չէ: Օրինակ, եթե ունեք փաստաթղթեր ձևաչափով , այնուհետև դրա վերափոխման պահին HTML/PDF մշակողի AsciiDoctor-ի () կարող է նախազգուշացումներ տալ, օրինակ, կոտրված ներքին հղումների մասին: Եվ սա լավ պատճառ է չընդունելու «Ձգման հարցումը» փաստաթղթերի փոփոխություններով:
- Ուղղագրությունը նույնպես ստատիկ վերլուծության տեսակ է: Կոմունալ ի վիճակի է ստուգել ուղղագրությունը ոչ միայն փաստաթղթերում, այլ նաև ծրագրերի սկզբնական կոդերում (մեկնաբանություններ և բառացի) տարբեր ծրագրավորման լեզուներով, այդ թվում՝ C/C++, Java և Python: Օգտագործողի միջերեսի կամ փաստաթղթերի ուղղագրական սխալը նույնպես թերություն է:
- Կազմաձևման թեստեր (թե ինչ է դա, տես и հաշվետվություններ), թեև դրանք կատարվում են pytest-ի պես միավորի թեստային ժամանակում, դրանք իրականում նաև ստատիկ վերլուծության մի տեսակ են, քանի որ դրանք կատարման ընթացքում չեն կատարում աղբյուրի կոդերը:
Ինչպես տեսնում եք, այս ցուցակում սխալներ գտնելը ամենաքիչ կարևոր դերն է զբաղեցնում, և մնացած ամեն ինչ հասանելի է անվճար բաց կոդով գործիքների օգտագործման միջոցով:
Ստատիկ վերլուծության այս տեսակներից ո՞րը պետք է օգտագործվի ձեր նախագծում: Իհարկե, ինչքան շատ, այնքան լավ։ Հիմնական բանը այն ճիշտ իրականացնելն է, ինչը կքննարկվի հետագա:
Առաքման խողովակաշարը որպես բազմաստիճան զտիչ և ստատիկ վերլուծություն որպես առաջին կասկադ
Շարունակական ինտեգրման դասական փոխաբերությունը խողովակաշարն է (խողովակաշարը), որով անցնում են փոփոխությունները` սկզբնական կոդը փոխելուց մինչև առաքում մինչև արտադրություն: Այս խողովակաշարի փուլերի ստանդարտ հաջորդականությունը հետևյալն է.
- ստատիկ վերլուծություն
- կազմում
- միավորի թեստեր
- ինտեգրման թեստեր
- UI թեստեր
- ձեռքով ստուգում
Խողովակաշարի N-րդ փուլում մերժված փոփոխությունները չեն տարածվում N+1 փուլի վրա:
Ինչո՞ւ հենց այս կերպ և ոչ այլ կերպ: Խողովակաշարի փորձնական հատվածում փորձարկողները կճանաչեն հայտնի փորձարկման բուրգը։
Փորձնական բուրգ. Աղբյուր. Մարտին Ֆաուլեր.
Այս բուրգի ներքևում կան թեստեր, որոնք ավելի հեշտ են գրել, ավելի արագ են աշխատում և չեն հակված կեղծ դրականին: Հետևաբար, դրանք պետք է ավելի շատ լինեն, դրանք պետք է ավելի շատ ծածկագրեն և առաջինը գործարկվեն: Բուրգի վերևում հակառակն է, ուստի ինտեգրման և UI թեստերի քանակը պետք է կրճատվի մինչև անհրաժեշտ նվազագույնը: Այս շղթայի մարդը ամենաթանկ, ամենադանդաղ և անվստահելի ռեսուրսն է, ուստի նա գտնվում է ամենավերջում և կատարում է աշխատանքը միայն այն դեպքում, եթե նախորդ փուլերը որևէ թերություն չեն գտել: Այնուամենայնիվ, նույն սկզբունքների համաձայն, խողովակաշարը կառուցված է մասերով, որոնք անմիջականորեն կապված չեն փորձարկման հետ:
Ես կցանկանայի անալոգիա առաջարկել ջրի ֆիլտրման բազմաստիճան համակարգի տեսքով: Մուտքի մեջ կեղտոտ ջուր է մատակարարվում (փոփոխություններ արատներով), ելքում մենք պետք է մաքուր ջուր ստանանք, որի մեջ վերացվում են բոլոր անցանկալի աղտոտիչները։
Բազմաստիճան ֆիլտր: Աղբյուր.
Ինչպես գիտեք, մաքրող ֆիլտրերը նախագծված են այնպես, որ յուրաքանչյուր հաջորդ կասկադը կարող է զտել աղտոտիչների ավելի փոքր մասը: Միևնույն ժամանակ, ավելի կոպիտ մաքրման կասկադներն ունեն ավելի բարձր թողունակություն և ավելի ցածր արժեք: Մեր անալոգիայի համաձայն, սա նշանակում է, որ մուտքագրման որակի դարպասներն ավելի արագ են, ավելի քիչ ջանք են պահանջում գործարկման համար և իրենք ավելի անպարկեշտ են շահագործման մեջ, և դա հենց այն հաջորդականությամբ է, որով դրանք կառուցված են: Ստատիկ վերլուծության դերը, որը, ինչպես մենք հիմա հասկանում ենք, ի վիճակի է վերացնելու միայն ամենակոպիտ թերությունները, ֆիլտրի կասկադի հենց սկզբում վանդակաճաղի դերն է:
Ստատիկ անալիզն ինքնին չի բարելավում վերջնական արտադրանքի որակը, ինչպես որ «ցեխի թակարդը» ջուրը խմելու չի դարձնում: Եվ այնուամենայնիվ, ի տարբերություն փոխակրիչի այլ տարրերի, դրա կարևորությունն ակնհայտ է։ Թեև բազմաստիճան ֆիլտրում ելքային փուլերը պոտենցիալ ի վիճակի են ֆիքսելու այն ամենը, ինչ անում են մուտքային փուլերը, պարզ է, թե ինչ հետևանքների կհանգեցնի միայն նուրբ զտման փուլերով, առանց մուտքային փուլերի:
«Ցեխահավաքի» նպատակն է բեռնաթափել հետագա կասկադները շատ կոպիտ թերություններից: Օրինակ՝ նվազագույնը, կոդը վերանայողին չպետք է շեղել սխալ ձևաչափված ծածկագիրը և սահմանված կոդավորման նորմերի խախտումները (օրինակ՝ լրացուցիչ փակագծերը կամ չափազանց խորը ներկառուցված ճյուղերը): NPE-ի նման սխալները պետք է հայտնաբերվեն միավորի թեստերի միջոցով, բայց եթե նույնիսկ փորձարկումից առաջ անալիզատորը մեզ ցույց տա, որ սխալն անխուսափելիորեն պետք է տեղի ունենա, դա զգալիորեն կարագացնի դրա շտկումը:
Կարծում եմ, այժմ պարզ է, թե ինչու ստատիկ վերլուծությունը չի բարելավում արտադրանքի որակը, եթե այն երբեմն օգտագործվում է, և այն պետք է անընդհատ օգտագործվի կոպիտ թերություններով փոփոխությունները զտելու համար: Հարցնելը, թե արդյոք ստատիկ անալիզատոր օգտագործելը կբարելավի ձեր արտադրանքի որակը, մոտավորապես համարժեք է «Կեղտոտ լճակից վերցված ջրի խմելու որակը կբարելավվի՞, եթե այն անցկացվի քամոցով»:
Իրականացում ժառանգական նախագծում
Կարևոր գործնական հարց. ինչպե՞ս ստատիկ վերլուծությունը ներմուծել շարունակական ինտեգրման գործընթացում՝ որպես «որակի դարպաս»: Ավտոմատ թեստերի դեպքում ամեն ինչ ակնհայտ է՝ կա թեստերի մի շարք, որոնցից որևէ մեկի ձախողումը բավարար հիմք է ենթադրելու, որ հավաքը չի անցել որակի դարպասը։ Ստատիկ վերլուծության արդյունքների հիման վրա դարպասը նույն կերպ տեղադրելու փորձը ձախողվում է. ժառանգական ծածկագրում չափազանց շատ վերլուծության նախազգուշացումներ կան, դուք չեք ցանկանում դրանք ամբողջությամբ անտեսել, բայց նաև անհնար է դադարեցնել առաքումը: արտադրանքը միայն այն պատճառով, որ այն պարունակում է անալիզատորի նախազգուշացումներ:
Երբ առաջին անգամ օգտագործվում է, անալիզատորը առաջացնում է հսկայական թվով նախազգուշացումներ ցանկացած նախագծի վերաբերյալ, որոնց ճնշող մեծամասնությունը կապված չէ արտադրանքի ճիշտ աշխատանքի հետ: Այս բոլոր մեկնաբանությունները միանգամից ուղղել հնարավոր չէ, և դրանցից շատերն անհրաժեշտ չեն։ Ի վերջո, մենք գիտենք, որ մեր արտադրանքը, որպես ամբողջություն, աշխատում է, նույնիսկ նախքան ստատիկ վերլուծության ներդրումը:
Արդյունքում, շատ մարդիկ սահմանափակվում են ստատիկ վերլուծության էպիզոդիկ կիրառմամբ կամ օգտագործում են միայն տեղեկատվական ռեժիմում, երբ անալիզատորի հաշվետվությունը պարզապես տրվում է հավաքման ժամանակ: Սա հավասարազոր է որևէ վերլուծության բացակայությանը, քանի որ եթե մենք արդեն ունենք բազմաթիվ զգուշացումներ, ապա կոդի փոփոխության ժամանակ մյուսի առաջացումը (անկախ նրանից, թե որքան լուրջ է) աննկատ է մնում։
Հայտնի են որակյալ դարպասների ներդրման հետևյալ ուղիները.
- Սահմանում է նախազգուշացումների ընդհանուր թվի սահմանափակում կամ նախազգուշացումների քանակը բաժանված կոդի տողերի քանակի վրա: Սա լավ չի աշխատում, քանի որ նման դարպասը ազատորեն բաց է թողնում փոփոխությունները նոր թերություններով, մինչև դրանց սահմանը գերազանցվի:
- Ինչ-որ պահի կոդում բոլոր հին նախազգուշացումների շտկում, քանի որ անտեսվում են, և կառուցումը ձախողվում է, երբ նոր նախազգուշացումներ են լինում: Այս ֆունկցիոնալությունը տրամադրվում է PVS-ստուդիայի և որոշ առցանց ռեսուրսների կողմից, ինչպիսիք են Codacy-ն: Ես հնարավորություն չեմ ունեցել աշխատելու PVS-studio-ում, ինչ վերաբերում է Codacy-ի հետ իմ փորձին, ապա նրանց հիմնական խնդիրն այն է, որ «հին» և «նոր» սխալի սահմանումը բավականին բարդ ալգորիթմ է, որը չի նշանակում. միշտ ճիշտ է աշխատում, հատկապես, եթե ֆայլերը խիստ փոփոխված կամ վերանվանված են: Իմ հիշողության մեջ, Codacy-ն կարող էր բաց թողնել նոր նախազգուշացումները ձգման հարցում, և միևնույն ժամանակ չբաց թողնել ձգման հարցումը նախազգուշացումների պատճառով, որոնք կապված չէին այս PR-ի կոդի փոփոխությունների հետ:
- Իմ կարծիքով ամենաարդյունավետ լուծումը նկարագրված է գրքում «կտրուկ» մեթոդ. Հիմնական գաղափարն այն է, որ յուրաքանչյուր թողարկման հատկությունը ստատիկ վերլուծության նախազգուշացումների քանակն է, և թույլատրվում են միայն փոփոխությունները, որոնք չեն ավելացնում նախազգուշացումների ընդհանուր թիվը:
Արգելանիվ
Այն աշխատում է այսպես.
- Սկզբնական փուլում իրականացվում է անալիզատորների կողմից հայտնաբերված կոդի նախազգուշացումների քանակի թողարկման մետատվյալների գրառումը: Այսպիսով, երբ դուք կառուցում եք վերին հոսանքով, ձեր պահեստի կառավարիչը գրվում է ոչ միայն «արձակում 7.0.2», այլ «թողարկում 7.0.2, որը պարունակում է 100500 Checkstyle զգուշացումներ»։ Եթե դուք օգտագործում եք պահեստի առաջադեմ կառավարիչ (օրինակ՝ Artifactory), հեշտ է ձեր թողարկման մասին նման մետատվյալներ պահել:
- Այժմ կառուցման վրա ձգվող յուրաքանչյուր հարցում համեմատում է ստացված նախազգուշացումների քանակը ընթացիկ թողարկման թվի հետ: Եթե PR-ը հանգեցնում է այս թվի ավելացմանը, ապա կոդը ստատիկ վերլուծության մեջ չի անցնում որակի դարպասը։ Եթե զգուշացումների թիվը նվազում է կամ չի փոխվում, ուրեմն այն անցնում է։
- Հաջորդ թողարկման ժամանակ նախազգուշացումների վերահաշվարկված թիվը հետ կգրվի թողարկման մետատվյալներին:
Այսպիսով, կամաց-կամաց, բայց անշեղորեն (ինչպես կապանքների դեպքում), նախազգուշացումների թիվը կձգտի զրոյի: Իհարկե, համակարգին կարելի է խաբել՝ նոր նախազգուշացում մտցնելով, բայց ուղղելով ուրիշին։ Սա նորմալ է, քանի որ երկարաժամկետ հեռանկարում տալիս է արդյունք՝ զգուշացումները, որպես կանոն, ամրագրվում են ոչ թե մեկ առ մեկ, այլ անմիջապես որոշակի տեսակի խմբի կողմից, և բոլոր հեշտությամբ վերացված զգուշացումները արագորեն վերացվում են։
Այս գծապատկերը ցույց է տալիս Checkstyle-ի նախազգուշացումների ընդհանուր թիվը վեց ամիսների ընթացքում նման «չարչազանի» վրա . Զգուշացումների թիվը նվազել է մեծության կարգով, և դա տեղի է ունեցել բնականաբար՝ արտադրանքի զարգացմանը զուգահեռ։
Ես օգտագործում եմ այս մեթոդի փոփոխված տարբերակը՝ առանձին հաշվելով նախազգուշացումներն ըստ նախագծի մոդուլի և վերլուծության գործիքի, ինչի արդյունքում ստացվում է YAML ֆայլ՝ հավաքման մետատվյալներով, որն ունի հետևյալ տեսքը.
celesta-sql:
checkstyle: 434
spotbugs: 45
celesta-core:
checkstyle: 206
spotbugs: 13
celesta-maven-plugin:
checkstyle: 19
spotbugs: 0
celesta-unit:
checkstyle: 0
spotbugs: 0
Ցանկացած առաջադեմ CI համակարգում արգելանիվը կարող է իրականացվել ցանկացած ստատիկ վերլուծության գործիքի համար՝ առանց հենվելու պլագինների և երրորդ կողմի գործիքների: Անալիզատորներից յուրաքանչյուրը պատրաստում է իր զեկույցը պարզ տեքստով կամ XML ձևաչափով, որը հեշտ է վերլուծել: Մնում է CI սկրիպտում գրանցել միայն անհրաժեշտ տրամաբանությունը։ Դուք կարող եք տեսնել, թե ինչպես է դա իրականացվում մեր բաց կոդով նախագծերում, որոնք հիմնված են Jenkins-ի և Artifactory-ի վրա, կարող եք կամ . Երկու օրինակներն էլ կախված են գրադարանից : մեթոդ countWarnings() հաշվում է xml թեգերը Checkstyle-ի և Spotbugs-ի կողմից ստեղծված ֆայլերում սովորական ձևով և compareWarningMaps() իրականացնում է նույն արգելանիվը՝ սխալ թույլ տալով, երբ կատեգորիաներից որևէ մեկում նախազգուշացումների թիվը մեծանում է:
Մեկնաբանությունների, տեքստի բառացիության և փաստաթղթերի ուղղագրական վերլուծության համար հնարավոր է հետաքրքիր կիրառություն aspell-ի միջոցով: Ինչպես գիտեք, ուղղագրությունը ստուգելիս ստանդարտ բառարանին անհայտ ոչ բոլոր բառերն են սխալ, դրանք կարող են ավելացվել օգտվողի բառարանում: Եթե օգտագործողի բառարանը դարձնում եք նախագծի սկզբնական կոդի մաս, ապա ուղղագրական որակի դարպասը կարող է ձևակերպվել հետևյալ կերպ. չգտնել ուղղագրական սխալներ:
Անալիզատորի տարբերակի ամրագրման կարևորության մասին
Եզրափակելով, պետք է նշել հետևյալը. անկախ նրանից, թե ինչպես եք վերլուծությունը իրականացնում ձեր առաքման խողովակաշարում, անալիզատորի տարբերակը պետք է ամրագրվի: Եթե թույլ եք տալիս անալիզատորին ինքնաբերաբար թարմացնել, ապա հաջորդ ձգման հարցումը կառուցելիս կարող են «առաջանալ» նոր թերություններ, որոնք կապված չեն կոդի փոփոխությունների հետ, բայց կապված են այն փաստի հետ, որ նոր անալիզատորը պարզապես ի վիճակի է գտնել ավելի շատ թերություններ, և սա կխախտի ձգման հարցումների ընդունման գործընթացը: Անալիզատորի արդիականացումը պետք է լինի գիտակցված գործողություն: Այնուամենայնիվ, հավաքման յուրաքանչյուր բաղադրիչի տարբերակի կոշտ ամրագրումը ընդհանուր առմամբ անհրաժեշտ պահանջ է և առանձին քննարկման թեմա:
Արդյունքները
- Ստատիկ վերլուծությունը ձեզ համար սխալներ չի գտնի և չի բարելավի ձեր արտադրանքի որակը մեկ կիրառման արդյունքում: Որակի վրա միակ դրական ազդեցությունը դրա շարունակական օգտագործումն է առաքման գործընթացում:
- Սխալներ գտնելն ամենևին էլ վերլուծության հիմնական խնդիր չէ, օգտակար գործառույթների ճնշող մեծամասնությունը հասանելի է բաց աղբյուրների գործիքներում:
- Իրականացնել որակյալ դարպասներ՝ հիմնվելով ստատիկ վերլուծության արդյունքների վրա, առաքման խողովակաշարի հենց առաջին փուլում՝ օգտագործելով արգելանիվ՝ ժառանգական ծածկագրի համար:
Սայլակ
- հաշվետվություն կոդի վերլուծության տարբեր մեթոդների մասին (ոչ միայն ստատիկ):
Source: www.habr.com