Code Review — mohiyati, qoidalari va jamoada ko'rib chiqishni qanday o'tkazish

Code Review nima?

Code Review — manba kodining bir yoki bir nechta dasturchi tomonidan loyihaning asosiy tarmog'iga integratsiya qilinishidan oldin tekshirish jarayonidir. Ko'rib chiqishning maqsadi nafaqat xatolarni topish, balki arxitekturani yaxshilash, jamoa standartlariga muvofiqlik va bilimlarni tarqatishdir. Avtomatik tahlildan (linterlardan) farqli o'laroq, kod ko'rib chiqish inson tomonidan amalga oshiriladi va o'qiluvchanlik, mantiq va arxitektura qarorlarini baholaydi.

Google Engineering Practices, 2024 ma'lumotlariga ko'ra, Code Review ikkita teng ahamiyatli maqsadga bo'linadi: kod bazasini nuqsonlardan himoya qilish va dasturchilarni fikr-mulohaza orqali o'qitish. Mobil loyihalarda ko'rib chiqish majburiy ravishda freymvorklar (UIKit, SwiftUI, Jetpack Compose), xotira boshqaruvi va tarmoq so'rovlari bilan ishlashni tekshirishni o'z ichiga oladi.

Code Review GitLab va GitHubda Merge Request va Pull Request orqali tashkil etiladi. Har bir MR/PR diff, qatorlarga sharhlar, munozaralar va tekshirish holatlarini o'z ichiga oladi. Microsoft Research (2023) tadqiqotiga ko'ra, muntazam ko'rib chiqishni qo'llaydigan jamoalar ishlab chiqarishga 40% kamroq kritik buglarni chiqaradi.

Code Review tarixi: rasmiy inspeksiyalardan asinxron PRlarga

Birinchi rasmiy Code Review 1970-yillarda IBMda bosqichma-bosqich tekshirish ro'yxatlari va protokol bilan „tuzilgan inspeksiyalar" sifatida paydo bo'ldi. 2000-yillarda Git va taqsimlangan jamoalarning tarqalishi bilan ko'rib chiqish Pull Request orqali asinxron formatga aylandi. GitHub (2008) PRni ommaviy hodisaga aylantirdi. Zamonaviy Code Review norasmiy, asinxron jarayon bo'lib, tezlik va o'rganishga urg'u beradi, byurokratiyaga emas.

Code Review turlari: rasmiy va norasmiy yondashuvlar

Code Review jarayon va ishtirokchilarning jalb qilinishiga qarab to'rtta asosiy turga bo'linadi. Rasmiy (Asynchronous Review) — sinxron aloqasiz MR/PR orqali tekshirish, taqsimlangan jamoalarda eng keng tarqalgan. Norasmiy — quick CR, bir dasturchi boshqasiga yaqinlashib, 5 daqiqa ichida kodni ko'rib chiqishni so'raganda.

Microsoft Research, 2023 ma'lumotlariga ko'ra, juft dasturlash (Pair Programming) — ikki dasturchi bir ekran ortida ishlaydi, har bir kod real vaqtda „jonli" ko'rib chiqish bilan yoziladi. Over-the-shoulder — bir dasturchi boshqasining ekraniga qarab, rasmiy jarayonsiz kodni sharhlaydi. Walkthrough — kod muallifi bir guruh dasturchilarni o'zgartirishlar bo'ylab olib boradi, har bir qarorni tushuntiradi.

Code Review tekshirish ro'yxati: kodda nimani tekshirish

Code Review tekshirish ro'yxati ko'rib chiqaruvchiga muhim jihatlarni o'tkazib yubormaslikka yordam beradi. Birinchi toifa — to'g'rilik va arxitektura: yechim qo'yilgan vazifaga mos keladimi, haddan tashqari murakkablik bormi, naqshlar (MVP, MVVM, Clean Architecture) to'g'ri tanlanganmi. Ikkinchi toifa — uslub va formatlash: jamoaning kod uslubiga (Kotlin Code Style, Swift Style Guide) rioya qilinadimi.

Thoughtbot Code Review Guide, 2024 ma'lumotlariga ko'ra, uchinchi blok — test: birlik testlari yozilganmi, ular chegaraviy holatlarni qamrab oladimi, mavjud testlarni buzmadimi. To'rtinchi — xavfsizlik: qattiq kodlangan tokenlar, API kalitlari, SQL in'ektsiyalari, xotira oqishlari bormi. Beshinchi — ishlash: korutinlar/RxJava to'g'ri ishlatilganmi, UI oqimini bloklash, ortiqcha ajratmalar bormi.

• Mantiq — algoritmning to'g'riligi, chegaraviy holatlar va xatolarni qayta ishlash
• Arxitektura — Clean Architecture, MVVMga rioya qilish, mas'uliyatlarni ajratish
• Kod uslubi — nomlash, formatlash, loyiha bilan moslik
• Testlar — birlik testlarining mavjudligi, ularning to'liqligi va yashil holati

Code Reviewni qanday o'tkazish: ko'rib chiqaruvchi uchun qoidalar

Code Review ko'rib chiqaruvchidan puxtalik va tezlik o'rtasida muvozanatni talab qiladi. Asosiy qoida — kodni kichik qismlarda tekshirish. Optimal hajm — bir seansda 200–400 qator o'zgarish. Google Research (2022) ma'lumotlariga ko'ra, 500 qatordan ortiq ko'rib chiqish samaradorligini yo'qotadi: o'tkazib yuborilgan nuqsonlar soni o'zgarish hajmi bilan chiziqli ravishda oshadi. Ikkinchi qoida — arxitekturadan boshlang, keyin mantiq, keyin tafsilotlar.

SmartBear, 2025 ma'lumotlariga ko'ra, sharhlar aniq bo'lishi kerak: „bu yomon" emas, balki „bu metod SRPni buzadi — validatsiya mantiqini alohida sinfga chiqaring". Har bir sharh yaxshilash taklifidir, tanqid emas. Agar kod to'g'ri bo'lsa, lekin uslub ko'rib chiqaruvchining afzalliklariga mos kelmasa — sharhsiz qoldiring. Ko'rib chiqaruvchi to'g'ri yechimni ma'qullashi kerak, hatto o'zi boshqacha yozgan bo'lsa ham.

Code Reviewni qanday qabul qilish: muallif uchun maslahatlar

Code Reviewni qabul qilish — kodni tekshirish qobiliyatidan kam bo'lmagan muhim mahoratdir. Muallif izohlarga ochiq yondashishi va ularni yechimni yaxshilash imkoniyati deb bilishi kerak. Birinchi qoida — sharhlarni shaxsiy tanqid sifatida qabul qilmaslik. Code Review kodni tekshiradi, dasturchini emas. Ikkinchi — agar sharh tushunarsiz bo'lsa, darhol tuzatish o'rniga tushuntirish so'rang.

LeadDev, 2024 ma'lumotlariga ko'ra, ko'rib chiqishga yuborishdan oldin muallif o'z kodini tekshirishi kerak: testlarni ishga tushirish, tekshirish ro'yxatidan o'tish, debug jurnallari va sharhlangan kod yo'qligiga ishonch hosil qilish. MR/PR o'zgarishlar konteksti bilan tushunarli tavsifni o'z ichiga olishi kerak. Tavsif qanchalik sifatli bo'lsa, ko'rib chiqish shunchalik tez va samarali bo'ladi.

Code Reviewda psixologik xavfsizlik

Code Review ning asosiy jihati — jamoada psixologik xavfsizlik. Agar dasturchi keskin tanqid yoki masxara qilinishdan qo'rqsa, muammolarni muhokama qilish o'rniga yashiradi. Google Project Aristotle (2017) ko'rsatdi: yuqori psixologik xavfsizlikka ega jamoalar 25% samaraliroq. Qoidalar: kodni tanqid qiling, muallifni emas; ayblov o'rniga savollar bering; yaxshi yechimlar uchun rahmat ayting.

Asosiy qoida muallif uchun — sharhlarni yopishga shoshilmang. Agar ko'rib chiqaruvchi o'zgartirishlar talab qilgan bo'lsa, ularni kiritish kerak, „yaxshi" deb javob berib tuzatishsiz qoldirmaslik kerak. Tuzatishlar kiritilgandan so'ng — qaytadan ko'rib chiqishni so'rang. GitLab va GitHub ko'rib chiqaruvchini xabardor qilish uchun Re-request Reviewni qo'llab-quvvatlaydi.

Code Reviewni avtomatlashtirish: linterlar va statik tahlil

Code Reviewni avtomatlashtirish rasmiy qoidalarni tekshirishni bartaraf etib, dasturchilar yukini kamaytiradi. Linterlar (ktlint, SwiftLint, ESLint) kod uslubi, formatlash va asosiy xatolarni tekshiradi. Statik analizatorlar (Detekt, SonarQube, Infer) potentsial buglarni, xotira oqishlarini va xavfsizlik muammolarini kod inson ko'rib chiqishiga tushishdan oldin topadi.

detekt Documentation, 2024 ma'lumotlariga ko'ra, CI/CD quvurida linterlar va analizatorlar MR/PR yaratilganda avtomatik ishga tushiriladi. Agar tekshirish o'tmasa — MR Merge tugmasi bilan bloklanadi. Bu inson ko'rib chiqishiga asosiy tekshiruvdan o'tgan kod tushishini kafolatlaydi. Ko'rib chiqaruvchi arxitektura, mantiq va o'qiluvchanlikka e'tibor qaratadi, bo'shliqlar va chekinishlarga emas.

// detekt konfiguratsiyasi namunasi Android loyihasi uchun
build.gradle.kts (app):

detekt {
    config = files("detekt-config.yml")
    buildUponDefaultConfig = true
    allRules = false
    autoCorrect = true
    debug = false
    parallel = true
}

tasks.named("preMerge") {
    dependsOn("detekt")
    dependsOn("ktlintCheck")
}

Mobil loyihalarda Code Review uchun vositalar

Code Review vositalari mobil ishlab chiqishda platforma (GitLab, GitHub, Bitbucket) va ixtisoslashgan (Gerrit, Reviewable, Crucible) turlarga bo'linadi. GitLab va GitHub o'rnatilgan funksionallikni ta'minlaydi: diff taqqoslash, qatorlarga sharhlar, Threads, Approve/Changes Requested holatlari, CI/CD bilan integratsiya. Vositani tanlash jamoa hajmi va ko'rib chiqish siyosatiga bog'liq.

GitLab Docs, 2025 ma'lumotlariga ko'ra, katta jamoalar (50+ dasturchi) uchun Gerrit qattiqroq nazoratni ta'minlaydi: birlashtirishdan oldin CI orqali majburiy tekshirish, vaznli tasdiqlashlar (Verified + Code-Review) va batafsil kirish huquqlari. Kichik va o'rta jamoalar uchun GitLab va GitHub optimal tanlovdir: Required Approvals, Code Owners va Merge Checks sozlamalari daqiqalar oladi.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, o'rnatilgan CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Mercurial/Git uchun Pull Requests, Diff sharhlari bilan Approvals
• Gerrit — qattiq tekshirish jarayoni, vaznli baholar, Jenkins integratsiyasi

Code Reviewda odatiy xatolar

Code Reviewdagi xatolar uning samaradorligini pasaytiradi va jamoani demotivatsiya qiladi. Birinchi — bir vaqtning o'zida juda katta hajmdagi o'zgarishlarni tekshirish. MR 2000+ qatorni o'z ichiga olganida, ko'rib chiqaruvchi nuqsonlarning 70% gacha o'tkazib yuboradi. Ikkinchi — kod uslubi yoki arxitekturaga asoslanmagan sub'ektiv izohlar. „Men boshqacha yozgan bo'lardim" kabi asossiz sharhlar foyda keltirmaydi.

Google Engineering Practices, 2024 ma'lumotlariga ko'ra, uchinchi xato — testlarni e'tiborsiz qoldirish. Agar MR yangi funksionallik uchun testlarni o'z ichiga olmasa — ko'rib chiqaruvchi ularni talab qilishi kerak, „keyinroq" deb ma'qullamasligi kerak. To'rtinchi — kun oxirida yoki sprint oxirida, diqqat chalg'igan paytda tekshirish. Ko'rib chiqish uchun eng yaxshi vaqt — kunning birinchi yarmi, vazifalar o'rtasida o'tishsiz ajratilgan 30–60 daqiqa.

Ko'rib chiqish xavfsizligi — beshinchi keng tarqalgan xato: ko'rib chiqaruvchilar kodda qattiq kodlangan sirlar, JavaScript bilan ochiq WebViewlar, kutubxonalardagi zaifliklar bor-yo'qligini tekshirmaydi. Mobil loyihalarda bu muhim: API kalitining sizib chiqishi butun backendni xavf ostiga qo'yishi mumkin.

Taqsimlangan jamoalarda Code Review

Masofaviy jamoalar uchun Code Review bilim uzatishning asosiy kanalidir. Aniq muddatlar bilan MR orqali asinxron format tavsiya etiladi: ko'rib chiqish uchun maksimal 24 soat. Murakkab arxitektura muhokamalari uchun ekran yozuvlaridan (Loom) foydalaning. Taqsimlangan jamoalarda qarorlarni MR sharhlarida yozma ravishda qayd etish ayniqsa muhim, vaqt mintaqalari o'zgarganda kontekst yo'qolmasligi uchun.