Code Review — mahiyyəti, qaydaları və komandada icmalın aparılması

Code Review nədir?

Code Review — mənbə kodunun bir və ya bir neçə tərtibatçı tərəfindən layihənin əsas budağına inteqrasiya edilməzdən əvvəl yoxlanılması prosesidir. İcmalın məqsədi təkcə səhvləri aşkar etmək deyil, həm də arxitekturanı yaxşılaşdırmaq, komanda standartlarına uyğunluğu təmin etmək və bilik yaymaqdır. Avtomatik analizdən (linterlərdən) fərqli olaraq, kod icmalı insan tərəfindən aparılır və oxunaqlılığı, məntiqi və arxitektura qərarlarını qiymətləndirir.

Google Engineering Practices, 2024 məlumatlarına görə, Code Review iki bərabər əhəmiyyətli məqsədə bölünür: kod bazasını qüsurlardan qorumaq və tərtibatçıları əks əlaqə vasitəsilə öyrətmək. Mobil layihələrdə icmal mütləq freymvorkların (UIKit, SwiftUI, Jetpack Compose), yaddaş idarəçiliyinin və şəbəkə sorğuları ilə işin yoxlanılmasını əhatə edir.

Code Review GitLab və GitHub-da Merge Request və Pull Request vasitəsilə təşkil olunur. Hər MR/PR diff, sətirlərə şərhlər, müzakirələr və yoxlama statuslarını ehtiva edir. Microsoft Research (2023) tədqiqatına görə, müntəzəm icmal tətbiq edən komandalar istehsalata 40% daha az kritik buraxır.

Code Review tarixi: formal inspeksiyalardan asinxron PR-lərə

İlk formal Code Review 1970-ci illərdə IBM-də addım-addım yoxlama siyahıları və protokolu olan „strukturlaşdırılmış inspeksiyalar" kimi ortaya çıxdı. 2000-ci illərdə Git və paylanmış komandaların yayılması ilə icmal Pull Request vasitəsilə asinxron formata çevrildi. GitHub (2008) PR-i kütləvi hadisəyə çevirdi. Müasir Code Review qeyri-formal, asinxron prosesdir və sürət və öyrənməyə vurğu edir, bürokratiyaya deyil.

Code Review növləri: formal və qeyri-formal yanaşmalar

Code Review proses və iştirakçıların cəlb olunmasından asılı olaraq dörd əsas növə bölünür. Formal (Asynchronous Review) — sinxron ünsiyyət olmadan MR/PR vasitəsilə yoxlama, paylanmış komandalarda ən çox yayılmışdır. Qeyri-formal — quick CR, bir tərtibatçı digərinə yaxınlaşaraq 5 dəqiqə ərzində koda baxmağı xahiş etdikdə.

Microsoft Research, 2023 məlumatlarına görə, qoşa proqramlaşdırma (Pair Programming) — iki tərtibatçı bir ekran arxasında işləyir, hər kod real vaxtda „ani" icmallarla yazılır. Over-the-shoulder — bir tərtibatçı digərinin ekranına baxır və formal proses olmadan kodu şərh edir. Walkthrough — kod müəllifi bir qrup tərtibatçını dəyişikliklər üzrə aparır, hər qərarı izah edir.

Code Review yoxlama siyahısı: kodda nəyi yoxlamaq

Code Review yoxlama siyahısı icmalçıya kritik vacib aspektləri qaçırmamağa kömək edir. Birinci kateqoriya — düzgünlük və arxitektura: həll qoyulmuş tapşırığa uyğundurmu, həddindən artıq mürəkkəblik varmı, nümunələr (MVP, MVVM, Clean Architecture) düzgün seçilibmi. İkinci kateqoriya — stil və formatlaşdırma: komandanın kod stilinə (Kotlin Code Style, Swift Style Guide) əməl olunurmu.

Thoughtbot Code Review Guide, 2024 məlumatlarına görə, üçüncü blok — test: vahid testlər yazılıbmı, onlar sərhəd halları əhatə edirmi, mövcud testləri pozmayıbmı. Dördüncü — təhlükəsizlik: sərt kodlaşdırılmış tokenlər, API açarları, SQL inyeksiyaları, yaddaş sızmaları varmı. Beşinci — performans: korutinlər/RxJava düzgün istifadə olunurmu, UI axınının bloklanması, həddindən artıq ayırmalar varmı.

• Məntiq — alqoritmin düzgünlüyü, sərhəd halların və səhvlərin işlənməsi
• Arxitektura — Clean Architecture, MVVM-ə riayət, məsuliyyətlərin bölünməsi
• Kod stili — adlandırma, formatlaşdırma, layihə ilə uyğunluq
• Testlər — vahid testlərin mövcudluğu, onların tamlığı və yaşıl status

Code Review necə aparılmalı: icmalçı üçün qaydalar

Code Review icmalçıdan diqqətlilik və sürət arasında balans tələb edir. Əsas qayda — kodu kiçik hissələrlə yoxlamaq. Optimal həcm — bir seansda 200–400 sətir dəyişiklik. Google Research (2022) məlumatlarına görə, 500 sətirdən çox icmal effektivliyini itirir: buraxılmış qüsurların sayı dəyişiklik həcmi ilə xətti olaraq artır. İkinci qayda — arxitekturadan başlamaq, sonra məntiq, sonra detallar.

SmartBear, 2025 məlumatlarına görə, şərhlər konkret olmalıdır: „bu pisdir" yox, „bu metod SRP-ni pozur — validasiya məntiqini ayrı sinfə çıxarın". Hər şərh təkmilləşdirmə təklifidir, tənqid deyil. Əgər kod düzgündürsə, lakin stil icmalçının üstünlükləri ilə üst-üstə düşmürsə — şərhsiz buraxın. İcmalçı düzgün həlli təsdiqləməlidir, özü başqa cür yazsa belə.

Code Review necə qəbul edilməli: müəllif üçün məsləhətlər

Code Review-in qəbul edilməsi — kod yoxlama bacarığından az əhəmiyyətli olmayan bir bacarıqdır. Müəllif qeydlərə açıq yanaşmalı və onları həlli təkmilləşdirmək fürsəti kimi görməlidir. Birinci qayda — şərhləri şəxsi tənqid kimi qəbul etməmək. Code Review kodu yoxlayır, tərtibatçını yox. İkinci — şərh anlaşılmazdırsa, dərhal düzəltmək əvəzinə aydınlıq istəyin.

LeadDev, 2024 məlumatlarına görə, icmala göndərməzdən əvvəl müəllif öz kodunu yoxlamalıdır: testləri işə salmalı, yoxlama siyahısından keçməli, debug jurnallarının və şərh edilmiş kodun olmadığına əmin olmalıdır. MR/PR dəyişiklik konteksti ilə başa düşülən təsvir ehtiva etməlidir. Təsvir nə qədər keyfiyyətli olsa, icmal bir o qədər sürətli və məhsuldar olar.

Code Review-də psixoloji təhlükəsizlik

Code Review-in əsas aspekti — komandada psixoloji təhlükəsizlikdir. Əgər tərtibatçı sərt tənqid və ya lağ edilməkdən qorxursa, problemləri müzakirə etmək əvəzinə gizlədəcək. Google Project Aristotle (2017) göstərdi: yüksək psixoloji təhlükəsizliyi olan komandalar 25% daha məhsuldardır. Qaydalar: kodu tənqid et, müəllifi yox; ittiham əvəzinə suallar ver; yaxşı həllərə görə təşəkkür et.

Əsas qayda müəllif üçün — şərhləri bağlamağa tələsməyin. Əgər icmalçı dəyişiklik tələb edibsə, onları etməli, „tamam" deyib düzəlişsiz buraxmamalısınız. Düzəlişlərdən sonra — yenidən icmal tələb edin. GitLab və GitHub icmalçını xəbərdar etmək üçün Re-request Review-i dəstəkləyir.

Code Review-in avtomatlaşdırılması: linterlər və statik analiz

Code Review-in avtomatlaşdırılması formal qaydaların yoxlanılmasını aradan qaldıraraq tərtibatçıların yükünü azaldır. Linterlər (ktlint, SwiftLint, ESLint) kod stilini, formatlaşdırmanı və əsas səhvləri yoxlayır. Statik analizatorlar (Detekt, SonarQube, Infer) potensial səhvləri, yaddaş sızmalarını və təhlükəsizlik problemlərini kod insan icmalına düşməzdən əvvəl tapır.

detekt Documentation, 2024 məlumatlarına görə, CI/CD boru xəttində linterlər və analizatorlar MR/PR yaradılarkən avtomatik işə salınır. Yoxlama keçməzsə — MR Merge düyməsi ilə bloklanır. Bu, insan icmalına əsas yoxlamadan keçmiş kodun düşməsini təmin edir. İcmalçı arxitektura, məntiq və oxunaqlılığa diqqət yetirir, boşluqlara və girintilərə yox.

// detekt konfiqurasiya nümunəsi Android layihəsi üçün
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 layihələrdə Code Review üçün alətlər

Code Review alətləri mobil inkişafda platforma (GitLab, GitHub, Bitbucket) və ixtisaslaşmış (Gerrit, Reviewable, Crucible) olaraq bölünür. GitLab və GitHub daxili funksionallıq təmin edir: diff müqayisəsi, sətirlərə şərhlər, Threads, Approve/Changes Requested statusları, CI/CD ilə inteqrasiya. Alət seçimi komandanın ölçüsündən və icmal siyasətindən asılıdır.

GitLab Docs, 2025 məlumatlarına görə, böyük komandalar (50+ tərtibatçı) üçün Gerrit daha ciddi nəzarət təmin edir: birləşmədən əvvəl CI vasitəsilə məcburi yoxlama, çəkili təsdiqlər (Verified + Code-Review) və ətraflı giriş hüquqları. Kiçik və orta komandalar üçün GitLab və GitHub optimal seçimdir: Required Approvals, Code Owners və Merge Checks konfiqurasiyası dəqiqələr çəkir.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, daxili CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Mercurial/Git üçün Pull Requests, Diff şərhləri ilə Approvals
• Gerrit — ciddi yoxlama prosesi, çəkili qiymətlər, Jenkins inteqrasiyası

Code Review-də tipik səhvlər

Code Review-də səhvlər onun effektivliyini azaldır və komandanı motivasiyadan salır. Birinci — bir dəfədə çox böyük həcmdə dəyişikliyin yoxlanılması. MR 2000+ sətir olduqda, icmalçı qüsurların 70%-ə qədərini qaçırır. İkinci — kod stilinə və ya arxitekturaya əsaslanmayan subyektiv qeydlər. „Başqa cür yazardım" kimi əsaslandırılmamış şərhlər fayda gətirmir.

Google Engineering Practices, 2024 məlumatlarına görə, üçüncü səhv — testlərə məhəl qoymamaq. Əgər MR yeni funksionallıq üçün testlər ehtiva etmirsə — icmalçı onları tələb etməli, „sonra" təsdiqləməməlidir. Dördüncü — günün və ya sprintin sonunda, diqqət dağınıq olduqda yoxlama. İcmal üçün ən yaxşı vaxt — günün birinci yarısı, tapşırıqlar arasında keçid etmədən ayrılmış 30–60 dəqiqə.

İcmal təhlükəsizliyi — beşinci ümumi səhv: icmalçılar kodda sərt kodlaşdırılmış sirlərin, JavaScript ilə bağlanmamış WebView-lərin, kitabxanalardakı zəifliklərin olub-olmadığını yoxlamır. Mobil layihələrdə bu kritikdir: API açarının sızması bütün backend-in kompromatına səbəb ola bilər.

Paylanmış komandalarda Code Review

Uzaqdan işləyən komandalar üçün Code Review əsas bilik ötürmə kanalıdır. Dəqiq son tarixlərlə MR vasitəsilə asinxron format tövsiyə olunur: icmal üçün maksimum 24 saat. Mürəkkəb arxitektura müzakirələri üçün ekran yazılarından (Loom) istifadə edin. Paylanmış komandalarda qərarların MR şərhlərində yazılı şəkildə qeyd edilməsi xüsusilə vacibdir ki, saat qurşaqları dəyişdikdə kontekst itməsin.