Toshkent axborot texnologiyalari universiteti dt sifatini ta'minlash

7.3.1 Tool-Driven Code Review

Avtomatlashtirilgan kodni ko'rib chiqish oxir-oqibat manba kodini tahlil qilish orqali amalga oshiriladi. Ushbu vositalar C [76] uchun Lint vositasiga qaytadi, u birinchi marta 1977 yilda paydo bo'lgan. O'shandan beri kod tekshirusgda keng qo'llanila boshlandi va ko'pincha Eclipse va IntelliJ kabi IDE-larga muntazam ravishda kiritiladi. Misol uchun, agar o'zgaruvchi e'lon qilingan bo'lsa-da, lekin hech qachon ishlatilmasa yoki ishga tushirilmasdan ishlatilsa, bu odatda ishlab chiquvchining asbobni aniq chaqirishiga hojat qoldirmasdan aniqlanadi.
Aniqlangan (yoki bo'lishi mumkin) kod muammolarining xususiyati bir vositadan boshqasiga o'zgarib turadi va ma'lum darajada asosiy tilning xususiyatiga bog'liq.
Misol uchun, Java kabi kuchli terilgan tillar dinamik ravishda terilgan tillarga qaraganda potentsial muammolarni aniqlash uchun ko'proq ma'lumot beradi. Avtomatlashtirilgan vositalar nisbatan mahalliylashtirilgan muammolarni aniqlashda ayniqsa yaxshi (masalan, bitta usul yoki sinfga lokalizatsiya qilingan). Kompas qiladigan vazifalar uchun tizimning katta qismlari.
Statik tahlil uchun nisbatan ko'proq mos bo'lgan Java ichida, ehtimol, eng mashhur vosita (u allaqachon IDE-ga o'rnatilmagan) Findbugs3 hisoblanadi. Ushbu vosita kompilyatsiya qilingan dasturning bayt kodini tahlil qiladi va yozilmagan ob'ekt maydonlaridan tortib, tugamaydigan tsikllargacha bo'lgan 400 dan ortiq muammolarni tekshiradi.
Findbugs kabi vositalarni paydo qiladgan muammolardan biri bu ishlab chiquvchini ogohlantirishlar bilan ortiqcha yuklashga moyilligidir. Asbob tekshiradigan har bir "xato" haqiqiy xato emas; ular ko'pincha noto'g'ri signal bo'lishi mumkin. Shunga qaramay, ko'p sonli nosozlik hisobotlari bilan duch kelganda, ishlab chiquvchi har doim haqiqiy muammolarni yolg'onlardan ajratish uchun ko'p vaqtini ularni o'qishga sarflashi kerak.

7.3.2 Developer-driven Code Reviews

Kod sifatining ba'zi xususiyatlarini avtomatik baholash juda qiyin, agar imkonsiz bo'lmasa. Yaxshi dizayn savollari, masalan, ko'pincha sub'ektivdir. Yaxshi dizaynning ba'zi jihatlari algoritmlar bilan o'lchanadi (8-bobda ko'rib chiqamiz), lekin boshqalar (masalan, fayllar va modullar muammo sohasiga intuitiv ravishda mos keladimi yoki yo'qmi) insoniy fikrlash darajasini talab qiladigan darajada tushunishni talab qiladi.
Dasturchi tomonidan boshqariladigan kodni tekshirish odatda ikki bosqichli jarayondir [124]. Dasturchi birinchi navbatda dasturni tushunishi kerak, shunda ular uni amalga oshirish va loyihalash haqida fikr bildira oladilar. Shundagina ular dasturni to'g'ri baholashlari mumkin.
Baholashning o'zi haqida gap ketganda, aniq maqsadlar bir necha omillarga bog'liq. Tizimni yozishda foydalanilgan tilning paradigmasi mavjud (Ob'ektga yo'naltirilgan tizimlar, masalan, funktsional yoki imperativ dasturlardan boshqa aqliy modelga ko'ra tushuniladi). Shuningdek, ustuvorliklar mavjud - masalan, xavfsizlikka e'tibor qaratadigan ishlab chiquvchilar barqarorlik kabi masalalarga e'tibor qaratadigan ishlab chiquvchilarga qaraganda turli xil potentsial muammolarni izlashlari mumkin.