Amaliy ish 1 Mavzu: Loyixaviy takliflar va jamoalar. Biznes ilovalarni ulashish buyicha misollar. Ishdan maqsad: topshiriq

xulosalar

Bularning barchasini boshdan kechirib, ko'p narsalarni o'rgandim. Mening ba'zi xulosalarim qisqa vaqt ichida yuzlab xato hisobotlarini shaxsan ko'rib chiqishga majbur bo'lmagan va har safar tahrirlashni boshlaganlarida kasal bo'lib qolgan odamlar uchun qiyin bo'lishidan qo'rqaman va mening so'zlarimga standart munosabat " yaxshi, bizda - hammasi joyida" yoki "bu unchalik yomon emas".
Yo'lda birinchi qadam - bu sizning kodingiz xatolarga to'la ekanligini o'zingizga halol tan olishdir. Aksariyat dasturchilar uchun bu yutish uchun achchiq tabletkadir, lekin uni yutib yubormasdan, siz muqarrar ravishda kodni o'zgartirish va yaxshilash bo'yicha har qanday taklifni g'azab bilan qabul qilasiz, agar yashirin dushmanlik bo'lmasa. Sen ... kerak istayman kodingizni tanqid qiling.
Avtomatlashtirish kerak. Dahshatli muvaffaqiyatsizliklar haqida xabarlarni ko'rganingizda avtomatik tizimlar, bunday g'ururni boshdan kechirmaslik mumkin emas, lekin avtomatlashtirishdagi har bir xato uchun inson xatolarining legioni mavjud. “Yaxshiroq kod” chaqiruvlari, ko‘proq kodni ko‘rib chiqish seanslari uchun yaxshi niyatlar, juft dasturlash va hokazolar ishlamaydi, ayniqsa loyihada o‘nlab odamlar ishtirok etsa va ish shoshqaloq bo‘lsa. Statik tahlilning katta qiymati bu imkoniyatdadir har safar boshlaganingizda Ushbu texnikada mavjud bo'lgan xatolarning kamida kichik qismlarini toping.
Men har bir yangilanish bilan PVS-Studio yangi diagnostika tufayli bizning kodimizda tobora ko'proq xatolar topayotganini payqadim. Bundan xulosa qilishimiz mumkinki, kodlar bazasi ma'lum hajmga yetganda, sintaksis nuqtai nazaridan ruxsat etilgan barcha xatolar boshlanadi. Katta loyihalarda kod sifati materiyaning fizik xossalari kabi bir xil statistik naqshlarga amal qiladi - undagi nuqsonlar hamma joyda mavjud va siz faqat ularning foydalanuvchilarga ta'sirini minimallashtirishga harakat qilishingiz mumkin.
Statik tahlil vositalari "bir qo'l orqasiga bog'langan holda" ishlashi kerak: ular bunday xulosalar uchun ma'lumot bermaydigan tillarni tahlil qilish asosida xulosalar chiqarishlari va umuman, juda ehtiyotkorlik bilan taxminlar qilishlari kerak. Shuning uchun siz tahlilchiga imkon qadar yordam berishingiz kerak - ko'rsatkich arifmetikasidan ko'ra indekslashni afzal ko'ring, qo'ng'iroqlar grafigini bitta manba faylida saqlang, aniq izohlardan foydalaning va hokazo. Statik analizator uchun tushunarsiz bo'lib tuyulishi mumkin bo'lgan hamma narsa, albatta, boshqa dasturchilarni ham chalkashtirib yuborishi mumkin. Qattiq statik terish ("qullik va intizom tillari") bo'lgan tillarga xos "xaker" nafratlanishi aslida uzoqni ko'ra olmaydi: dasturchilarning katta guruhlari ishtirokidagi yirik, uzoq muddatli loyihalar ehtiyojlari tubdan farq qiladi. o'zi uchun bajariladigan kichik va tezkor vazifalar.
Null ko'rsatkichlar C/C++ dagi eng katta muammodir, hech bo'lmaganda bu erda. Bitta qiymatdan bayroq va manzil sifatida ikki tomonlama foydalanish imkoniyati aql bovar qilmaydigan miqdordagi tanqidiy xatolarga olib keladi. Shuning uchun, iloji bo'lsa, C++ ko'rsatgichlardan ko'ra havolalarni afzal ko'rishi kerak. Ma'lumotnoma "haqiqatan" bir xil ko'rsatgichdan boshqa narsa bo'lmasa-da, u nol bo'lishi mumkin emasligi haqidagi yashirin majburiyat bilan bog'langan. Ko'rsatkichlar havolaga aylanganda null qiymatini tekshiring - bu keyinchalik bu muammoni unutish imkonini beradi. O'yinni yaratishda juda ko'p chuqur singib ketgan va potentsial xavfli dasturlash naqshlari mavjud, ammo men null tekshiruvlardan havolalarga to'liq va og'riqsiz o'tish yo'lini bilmayman.
Bizning kodlar bazamizdagi ikkinchi eng muhim muammo bu printf xatolari edi. idStr::c_str() o‘rniga idStr ni o‘tkazish deyarli har safar dasturning ishdan chiqishi bilan yakunlangani vaziyatni yanada og‘irlashtirdi. Biroq, biz turni tekshirishni to'g'ri ishlashi uchun variadik funktsiyalarda /analyze izohlaridan foydalanishni boshlaganimizda, muammo bir marta va butunlay hal qilindi. Analizatorning foydali ogohlantirishlarida biz tegishli kod tarmog'ini ishga tushirishda biron bir noto'g'ri holat yuzaga kelsa, avariyaga olib kelishi mumkin bo'lgan o'nlab bunday nuqsonlarga duch keldik - bu, aytmoqchi, testlar bilan bizning kod qamrab olish foizi qanchalik kichik ekanligini ko'rsatadi.
Analizator tomonidan bildirilgan ko'plab jiddiy xatolar, u yozilganidan keyin ko'p o'tmay amalga oshirilgan kod o'zgarishlari bilan bog'liq edi. Ajablanarli darajada keng tarqalgan misol, operatsiyani bajarishdan oldin ko'rsatkichlar nolga tekshirilgan ideal kod keyinchalik shunday o'zgartirilganki, ko'rsatkichlar birdan tekshirilmasdan ishlatila boshlagan. Agar biz ushbu muammoni alohida ko'rib chiqsak, unda kodning yuqori siklomatik murakkabligi haqida shikoyat qilish mumkin, ammo agar biz loyiha tarixiga nazar tashlasak, buning sababi kod muallifi buni qila olmaganligi ma'lum bo'ladi. binolarni keyinchalik refaktoring uchun mas'ul bo'lgan dasturchiga aniq etkazing.
Odamlar, ta'rifiga ko'ra, bir vaqtning o'zida hamma narsaga e'tibor qarata olmaydi, shuning uchun birinchi navbatda mijozlarga etkazib beradigan kodga e'tibor qarating va ichki ehtiyojlar uchun kodga kamroq e'tibor bering. Savdo bazasidan ichki loyihalarga proaktiv port kodini kiriting. Yaqinda maqola e'lon qilindi, unda barcha xilma-xillikdagi kod sifati ko'rsatkichlari kodning o'lchami bilan xato darajasi kabi deyarli mukammal bog'liqligi aytilgan, bu esa xatolar sonini yuqori aniqlik bilan bashorat qilish imkonini beradi. faqat kod hajmi. Shunday qilib, kodingizning sifat jihatidan muhim bo'lgan qismini kesib oling.
Agar siz parallel dasturlash olib keladigan barcha qo'shimcha qiyinchiliklardan qo'rqmagan bo'lsangiz, siz bu masalani to'g'ri o'rganmaganga o'xshaysiz.
Dasturiy ta'minotni ishlab chiqishda ishonchli benchmark testlarini o'tkazishning iloji yo'q, ammo kod tahlilidagi muvaffaqiyatimiz shunchalik aniqki, men oddiygina aytishim mumkin: kod tahlilidan foydalanmaslik mas'uliyatsizlikdir! Avtomatik konsol ishdan chiqish jurnallarida ob'ektiv ma'lumotlar mavjud bo'lib, ular Rage, garchi u ko'p jihatdan etakchi bo'lsa ham, bugungi o'yinlarning aksariyatiga qaraganda ancha barqaror va sog'lomroq ekanligini isbotladi. Afsuski, Rage-ni kompyuterda ishga tushirish muvaffaqiyatsiz tugadi - men AMD o'z grafik drayverlarini ishlab chiqishda statik tahlildan foydalanmasligiga ishonch hosil qilishga tayyorman.
Mana siz uchun retsept: agar sizning Visual Studio versiyangizda o'rnatilgan /tahlil bo'lsa, uni yoqing va shunday ishlashga harakat qiling. Agar menga ko'plab vositalardan birini tanlash so'ralsa, men ushbu yechimni Microsoft-dan tanlagan bo'lardim. Visual Studio'da ishlaydigan har bir kishi uchun men sizga hech bo'lmaganda demo rejimida PVS-Studio-ni sinab ko'rishingizni maslahat beraman. Agar siz tijorat dasturiy ta'minotini ishlab chiqsangiz, statik tahlil vositalarini sotib olish sarmoya kiritishning eng yaxshi usullaridan biri bo'ladi.
Va nihoyat, Twitter-dan sharh.
][ jamoasining har biri dasturiy ta'minot va yordamchi dasturlar bo'yicha o'z afzalliklariga ega
pentest. Maslahatlashtirgandan so'ng, biz aniqladik: tanlov shunchalik farq qiladiki, buni qilish mumkin
haqiqiy janoblar to'plami tasdiqlangan dasturlardan. Bu haqda ular qaror qilishdi. Kimga
hodgepodge qilmang, butun ro'yxat mavzularga bo'lingan. Bugun biz tahlil qilamiz
statik kod analizatorlari qachon ilovalardagi zaifliklarni qidirish
qo'llar - ularning manbalari.
Dastur manba kodlarining mavjudligi zaifliklarni qidirishni sezilarli darajada osonlashtiradi.
Turli parametrlarni ko'r-ko'rona manipulyatsiya qilish o'rniga
ilovaga o'tkazilsa, uni qanday qilib ko'rish juda oson
jarayonlar. Aytaylik, agar foydalanuvchi ma'lumotlari tekshiruvlarsiz uzatilsa va
transformatsiyalar, SQL so'roviga kiring - bizda SQL in'ektsiyasi zaifligi mavjud.
Agar ular HTML kodida chiqsa, biz klassik XSS ni olamiz. Kimdan
Bunday vaziyatlarni aniq aniqlash uchun statik skaner talab qilinadi, lekin, to
Afsuski, bu har doim ham ko'rinadigan darajada oson emas.