Statik kod analizatorini sinab ko'rish oson. Lekin uni amalga oshirish uchun, ayniqsa, katta eski loyihani ishlab chiqishda, mahorat talab etiladi. Agar noto'g'ri bajarilgan bo'lsa, analizator ish qo'shishi, rivojlanishni sekinlashtirishi va jamoani demotivatsiya qilishi mumkin. Keling, statik tahlilni ishlab chiqish jarayoniga integratsiyalashuviga qanday to'g'ri yondashish haqida qisqacha gaplashamiz va uni CI/CD qismi sifatida ishlatishni boshlaymiz.
kirish
Yaqinda mening e'tiborim nashrga qaratildi "". Bir tomondan, bu tanishishga arziydigan yaxshi maqola. Boshqa tomondan, menimcha, u hali ham ko'p narsaga ega bo'lgan loyihada statik tahlilni og'riqsiz amalga oshirish haqida to'liq javob bermaydi. Maqolada aytilishicha, siz texnik qarzni qabul qilishingiz va faqat yangi kod ustida ishlashingiz mumkin, ammo keyinchalik bu texnik qarz bilan nima qilish kerakligi haqida hech qanday javob yo'q.
Bizning PVS-Studio jamoasi ushbu mavzu bo'yicha o'z nuqtai nazarini taqdim etadi. Keling, birinchi navbatda statik kod analizatorini amalga oshirish muammosi qanday paydo bo'lishini, bu muammoni qanday engish va texnik qarzni asta-sekin og'riqsiz bartaraf etishni ko'rib chiqaylik.
Muammolar
Odatda statik analizatorni ishga tushirish va qanday ishlashini ko'rish qiyin emas []. Kodda qiziqarli xatolar yoki hatto qo'rqinchli potentsial zaifliklarni ko'rishingiz mumkin. Siz hatto biror narsani tuzatishingiz mumkin, lekin keyin ko'plab dasturchilar taslim bo'lishadi.
Barcha statik analizatorlar noto'g'ri ijobiy natijalar beradi. Bu statik kod tahlili metodologiyasining o'ziga xos xususiyati bo'lib, bu haqda hech narsa qilib bo'lmaydi. Umumiy holda, bu Rays teoremasi tomonidan tasdiqlanganidek, hal qilib bo'lmaydigan muammodir []. Mashinani o'rganish algoritmlari ham yordam bermaydi []. Agar biror kishi u yoki bu kod noto'g'ri ekanligini har doim ham ayta olmasa ham, dasturdan buni kutmasligingiz kerak :).
Agar statik analizator allaqachon sozlangan bo'lsa, noto'g'ri pozitivlar muammo emas:
- Tegishli bo'lmagan qoidalar to'plamini o'chirib qo'yish;
- Ba'zi ahamiyatsiz diagnostika o'chirilgan;
- Agar biz C yoki C++ haqida gapiradigan bo'lsak, unda bunday makrolar qo'llaniladigan har bir joyda foydasiz ogohlantirishlar paydo bo'lishiga olib keladigan maxsus konstruktsiyalarni o'z ichiga olgan makroslar belgilanadi;
- Tizim funktsiyalariga o'xshash harakatlarni bajaradigan o'z funktsiyalari belgilanadi (o'z analogi memcpy yoki printf) [];
- Noto'g'ri pozitivlar sharhlar yordamida maxsus o'chirib qo'yiladi;
- Va shunga o'xshash.
Bunday holda, biz taxminan 10-15% past noto'g'ri ijobiy nisbatni kutishimiz mumkin.]. Boshqacha qilib aytganda, analizatorning 9 ta ogohlantirishidan 10 tasi koddagi haqiqiy muammoni yoki hech bo'lmaganda "kuchli hidli kodni" ko'rsatadi. Qabul qiling, bu stsenariy juda yoqimli va analizator dasturchining haqiqiy do'stidir.
Aslida, katta loyihada dastlabki rasm butunlay boshqacha bo'ladi. Analizator eski kod uchun yuzlab yoki minglab ogohlantirishlarni chiqaradi. Ushbu ogohlantirishlarning qaysi biri tegishli va qaysi biri tegishli emasligini tezda tushunish mumkin emas. Bu barcha ogohlantirishlar bilan o'tirish va shug'ullanish mantiqiy emas, chunki bu holda asosiy ish kunlar yoki haftalar davomida to'xtaydi. Odatda, jamoa bunday stsenariyni ko'tara olmaydi. O'zgarishlar tarixini buzadigan juda ko'p sonli farqlar ham bo'ladi. Koddagi juda ko'p bo'laklarni tezda ommaviy tahrirlash muqarrar ravishda yangi imlo xatolari va xatolarga olib keladi.
Va eng muhimi, ogohlantirishlarga qarshi kurashda bunday jasorat kam ma'noga ega. Loyiha ko'p yillar davomida muvaffaqiyatli ishlayotganligi sababli, undagi muhim xatolarning aksariyati allaqachon tuzatilganligiga rozi bo'ling. Ha, bu tuzatishlar juda qimmatga tushdi, disk raskadrovka qilinishi kerak edi, xatolar haqida foydalanuvchilarning salbiy fikr-mulohazalarini oldi va hokazo. Statik analizator ushbu xatolarning ko'pini kodlash bosqichida tez va arzon tarzda tuzatishga yordam beradi. Ammo hozirgi vaqtda u yoki bu yo'l bilan bu xatolar tuzatildi va analizator asosan eski koddagi muhim bo'lmagan xatolarni aniqlaydi. Bu kod ishlatilmasligi mumkin, u juda kamdan-kam hollarda qo'llanilishi mumkin va undagi xato sezilarli oqibatlarga olib kelmasligi mumkin. Ehtimol, biron bir joyda tugmachaning soyasi noto'g'ri rangdir, ammo bu hech kimning mahsulotdan foydalanishiga xalaqit bermaydi.
Albatta, kichik xatolar ham xato bo'lib qoladi. Va ba'zida xato haqiqiy zaiflikni yashirishi mumkin. Biroq, hamma narsadan voz kechish va o'zini zo'rg'a namoyon qiladigan nuqsonlar bilan shug'ullanish uchun kunlar / haftalar shubhali fikrga o'xshaydi.
Dasturchilar qarashadi, qaranglar, eski ish kodi haqidagi barcha bu ogohlantirishlarni ko'rishadi ... Va ular o'ylashadi: biz statik tahlilsiz qila olamiz. Keling, yangi foydali funksiyalarni yozaylik.
O'z yo'lida ular haq. Ular birinchi navbatda bu ogohlantirishlardan qandaydir tarzda xalos bo'lishlari kerak, deb hisoblashadi. Shundagina ular kod analizatoridan muntazam foydalanishdan foyda olishlari mumkin boβladi. Aks holda, yangi ogohlantirishlar shunchaki eskilariga g'arq bo'ladi va hech kim ularga e'tibor bermaydi.
Bu kompilyator ogohlantirishlari bilan bir xil o'xshashlikdir. Bejiz ular kompilyator ogohlantirishlari sonini 0 da saqlashni tavsiya qilishmagan. Agar 1000 ta ogohlantirish bo'lsa, 1001 ta bo'lsa, hech kim bunga e'tibor bermaydi va bu eng yangi ogohlantirishni qayerdan qidirish kerakligi aniq emas.
Bu hikoyadagi eng yomon narsa, agar yuqoridan kimdir sizni statik kod tahlilidan foydalanishga majbur qilsa. Bu faqat jamoani demotivatsiya qiladi, chunki ularning nuqtai nazaridan qo'shimcha byurokratik murakkablik paydo bo'ladi, bu faqat to'sqinlik qiladi. Hech kim analizatorning hisobotlarini ko'rib chiqmaydi va barcha foydalanish faqat "qog'ozda" bo'ladi. Bular. Rasmiy ravishda tahlil DevOps jarayoniga kiritilgan, ammo amalda bu hech kimga foyda keltirmaydi. Biz konferentsiya ishtirokchilaridan stendlarda batafsil hikoyalarni eshitdik. Bunday tajriba dasturchilarni statik tahlil vositalaridan uzoq vaqt davomida, agar abadiy bo'lmasa, foydalanishdan qaytaradi.
Texnik qarzni amalga oshirish va bartaraf etish
Aslida, statik tahlilni hatto katta eski loyihaga ham kiritishda qiyin yoki qo'rqinchli narsa yo'q.
CI / CD
Bundan tashqari, analizator darhol uzluksiz rivojlanish jarayonining bir qismiga aylanishi mumkin. Masalan, PVS-Studio distributivida hisobotni kerakli formatda qulay ko'rish uchun yordamchi dasturlar va kodning muammoli bo'limlarini yozgan ishlab chiquvchilarga bildirishnomalar mavjud. PVS-Studio-ni CI/CD tizimlaridan ishga tushirishga ko'proq qiziqqanlar uchun men sizga mos keladiganlar bilan tanishishingizni tavsiya qilaman. hujjatlar va bir qator maqolalar:
Ammo kodni tahlil qilish vositalarini joriy etishning birinchi bosqichlarida ko'p sonli noto'g'ri pozitivlar masalasiga qaytaylik.
Mavjud texnik qarzlarni tuzatish va yangi ogohlantirishlar bilan ishlash
Zamonaviy tijorat statik analizatorlari faqat yangi yoki o'zgartirilgan kodda paydo bo'ladigan yangi ogohlantirishlarni o'rganishga imkon beradi. Ushbu mexanizmning amalga oshirilishi turlicha, ammo mohiyati bir xil. PVS-Studio statik analizatorida bu funksiya quyidagicha amalga oshiriladi.
Statik tahlildan tezda foydalanishni boshlash uchun PVS-Studio foydalanuvchilariga ogohlantirishlarni ommaviy bostirish mexanizmidan foydalanishni tavsiya qilamiz []. Umumiy fikr quyidagicha. Foydalanuvchi analizatorni ishga tushirdi va ko'plab ogohlantirishlarni oldi. Ko'p yillar davomida ishlab chiqilayotgan loyiha tirik, rivojlanayotgan va pul ishlayotganligi sababli, hisobotda jiddiy kamchiliklarni ko'rsatadigan ogohlantirishlar ko'p bo'lmaydi. Boshqacha qilib aytganda, muhim xatolar qimmatroq usullardan foydalangan holda yoki mijozlarning fikr-mulohazalari tufayli allaqachon tuzatilgan. Shunga ko'ra, analizator hozirda topadigan hamma narsa texnik qarz deb hisoblanishi mumkin, uni darhol yo'q qilishga harakat qilish mumkin emas.
Siz PVS-Studio-ga ushbu ogohlantirishlarni hozircha ahamiyatsiz deb hisoblashingizni aytishingiz mumkin (texnik qarzni keyinroq saqlang) va u endi ularni ko'rsatmaydi. Analizator maxsus fayl yaratadi, u erda hali qiziq bo'lmagan xatolar haqidagi ma'lumotlarni saqlaydi. Va endi PVS-Studio faqat yangi yoki o'zgartirilgan kod uchun ogohlantirishlar chiqaradi. Bundan tashqari, bularning barchasi aql bilan amalga oshiriladi. Agar, masalan, dastlabki kod faylining boshiga bo'sh qator qo'shilsa, u holda analizator aslida hech narsa o'zgarmaganligini tushunadi va jim turishda davom etadi. Ushbu belgilash fayli versiyani boshqarish tizimiga kiritilishi mumkin. Fayl katta, lekin bu muammo emas, chunki uni tez-tez saqlashning ma'nosi yo'q.
Endi barcha dasturchilar faqat yangi yoki o'zgartirilgan kod bilan bog'liq ogohlantirishlarni ko'radi. Shunday qilib, siz keyingi kundan boshlab, ular aytganidek, analizatordan foydalanishni boshlashingiz mumkin. Va keyinroq texnik qarzga qaytishingiz va xatolarni asta-sekin tuzatishingiz va analizatorni sozlashingiz mumkin.
Shunday qilib, katta eski loyihada analizatorni amalga oshirish bilan bog'liq birinchi muammo hal qilindi. Endi texnik qarz bilan nima qilish kerakligini aniqlaylik.
Xatolarni tuzatish va qayta ishlash
Eng oddiy va eng tabiiy narsa, analizatorning ommaviy ravishda bostirilgan ogohlantirishlarini tahlil qilish va ular bilan asta-sekin shug'ullanish uchun biroz vaqt ajratishdir. Qaerdadir koddagi xatolarni tuzatish kerak, qayerdadir analizatorga kod muammoli emasligini aytish uchun qayta tiklash kerak. Oddiy misol:
if (a = b)Aksariyat C++ kompilyatorlari va analizatorlari bunday koddan shikoyat qiladilar, chunki ular haqiqatan ham yozishni xohlash ehtimoli katta. (a == b). Ammo aytilmagan kelishuv mavjud va bu odatda hujjatlarda qayd etilgan, agar qo'shimcha qavslar bo'lsa, dasturchi ataylab shunday kod yozgan deb hisoblanadi va qasam ichishning hojati yo'q. Masalan, diagnostika uchun PVS-Studio hujjatlarida quyidagi satr to'g'ri va xavfsiz deb hisoblanishi aniq yozilgan:
if ((a = b))Yana bir misol. Bu C++ kodida unutilganmi? tanaffus yoki yo'q?
case A:
foo();
case B:
bar();
break;PVS-Studio analizatori bu erda ogohlantirish beradi . Bu xato bo'lmasligi mumkin, bu holda siz atributni qo'shish orqali tahlilchiga maslahat berishingiz kerak yoki masalan __atribut__((tushirish)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Aytish mumkinki, bunday kod o'zgarishlari xatoni tuzatmaydi. Ha, bu to'g'ri, lekin u ikkita foydali ish qiladi. Birinchidan, analizator hisoboti noto'g'ri musbatlardan xalos bo'ladi. Ikkinchidan, kod uni saqlash bilan shug'ullanadigan odamlar uchun tushunarli bo'ladi. Va bu juda muhim! Faqat buning uchun kodni aniqroq va saqlashni osonlashtirish uchun kichik refaktoringlarni amalga oshirishga arziydi. Analizator "tanaffus" kerak yoki yo'qligini tushunmaganligi sababli, boshqa dasturchilar uchun ham tushunarsiz bo'ladi.
Xatolarni tuzatish va qayta ishlashga qo'shimcha ravishda, siz aniq noto'g'ri analizator ogohlantirishlarini bostirishingiz mumkin. Ba'zi ahamiyatsiz diagnostika o'chirib qo'yilishi mumkin. Misol uchun, kimdir ogohlantirishlarni ma'nosiz deb hisoblaydi float/juft qiymatlarni solishtirish haqida. Va ba'zilari ularni muhim va o'rganishga loyiq deb tasniflaydi []. Qaysi ogohlantirishlar tegishli deb hisoblanadi va qaysi biri noto'g'ri ekanligini ishlab chiqish guruhi hal qiladi.
Noto'g'ri ogohlantirishlarni bostirishning boshqa usullari mavjud. Misol uchun, so'l belgilash haqida avval aytib o'tilgan edi. Bularning barchasi hujjatlarda batafsilroq tavsiflangan. Eng muhimi, agar siz noto'g'ri pozitivlar bilan ishlashga asta-sekin va tizimli ravishda yondashsangiz, ularda hech qanday yomon narsa yo'qligini tushunishdir. Qiziqarsiz ogohlantirishlarning aksariyati konfiguratsiyadan so'ng yo'qoladi va faqat sinchkovlik bilan o'rganishni talab qiladigan joylar va koddagi ba'zi o'zgarishlar qoladi.
Bundan tashqari, har qanday qiyinchiliklar yuzaga kelsa, biz doimo mijozlarimizga PVS-Studio-ni o'rnatishda yordam beramiz. Bundan tashqari, noto'g'ri ogohlantirishlarni o'zimiz yo'q qilgan va xatolarni tuzatgan holatlar ham bo'lgan.]. Har holda, kengaytirilgan hamkorlik uchun ushbu variant ham mumkinligini eslatib o'tishga qaror qildim :).
Ratchet usuli
Statik analizator ogohlantirishini yo'q qilish orqali kod sifatini bosqichma-bosqich yaxshilash uchun yana bir qiziqarli yondashuv mavjud. Xulosa shuki, ogohlantirishlar soni faqat kamayishi mumkin.
Statik analizator tomonidan berilgan ogohlantirishlar soni qayd etiladi. Sifat darvozasi shunday tuzilganki, endi siz faqat operatsiyalar sonini ko'paytirmaydigan kodni kiritishingiz mumkin. Natijada, signallar sonini bosqichma-bosqich kamaytirish jarayoni analizatorni sozlash va xatolarni tuzatishdan boshlanadi.
Agar biror kishi biroz aldamoqchi bo'lsa ham va uning yangi kodidagi ogohlantirishlarni yo'q qilish orqali emas, balki eski uchinchi tomon kodini yaxshilash orqali sifat darvozasidan o'tishga qaror qilsa ham, bu qo'rqinchli emas. Shunga qaramay, ratchet bir yo'nalishda aylanadi va asta-sekin nuqsonlar soni kamayadi. Agar biror kishi o'zining yangi kamchiliklarini tuzatishni istamasa ham, u qo'shni kodda biror narsani yaxshilashi kerak bo'ladi. Bir nuqtada, ogohlantirishlar sonini kamaytirishning oson usullari tugaydi va haqiqiy xatolar tuzatiladigan vaqt keladi.
Ushbu metodologiya Ivan Ponomarevning juda qiziqarli maqolasida batafsil tavsiflangan "", uni kod sifatini yaxshilashga qiziqqan har bir kishiga o'qishni tavsiya qilaman.
Maqola muallifining ushbu mavzu bo'yicha hisoboti ham bor: "".
xulosa
Umid qilamanki, ushbu maqoladan so'ng, o'quvchilar statik tahlil vositalarini ko'proq qabul qilishadi va ularni ishlab chiqish jarayoniga qo'llashni xohlashadi. Agar sizda biron bir savol bo'lsa, biz doimo tayyormiz PVS-Studio statik analizatorimiz foydalanuvchilari va uni amalga oshirishda yordam berish.
Statik tahlil haqiqatan ham qulay va foydali bo'lishi mumkinligi haqida boshqa odatiy shubhalar mavjud. Men ushbu shubhalarning aksariyatini "PVS-Studio statik kod analizatorini ishlab chiqish jarayoniga kiritish sabablari" nashrida yo'q qilishga harakat qildim.].
E'tiboringiz uchun rahmat va keling va PVS-Studio analizatorini sinab ko'ring.
Qo'shimcha havolalar
- Andrey Karpov.
- Vikipediya. .
- Andrey Karpov, Viktoriya Xanieva. .
- PVS-studio. Hujjatlar. .
- Andrey Karpov. .
- PVS-studio. Hujjatlar. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Andrey Karpov. .
Agar siz ushbu maqolani ingliz tilida so'zlashuvchi auditoriya bilan baham ko'rmoqchi bo'lsangiz, tarjima havolasidan foydalaning: Andrey Karpov. .
Manba: www.habr.com